Configuring cross-site replication on Replica instances¶
When the Operator creates a new cluster, a lot of things are happening, such as
electing the Primary, generating certificates, and picking specific names. This
should not happen if we want the Operator to run the Replica site, so first
of all the cluster should be put into unmanaged state by setting the
unmanaged key in the deploy/cr.yaml configuration file to true. Also you
should set updateStrategy key to OnDelete, because Smart Updates are not allowed on unmanaged clusters. Also, the Operator versions prior to 1.19.0 did not support backups on unmanaged clusters, so set backup.enabled to false for the Operator 1.18.0 and older.
Note
Setting unmanaged to true will not only prevent the Operator from
controlling the Replica Set configuration, but it will also result in not
generating certificates and users credentials for new clusters.
Here is an example:
spec:
unmanaged: true
updateStrategy: OnDelete
replsets:
- name: rs0
size: 3
...
The Main and Replica sites should have the same Secrets objects, so don’t forget
to apply Secrets from your Main site. Names of the corresponding objects
are set in the secrets.ssl, secrets.sslInternal, secrets.users, and
secrets.keyfile Custom Resource options (my-cluster-name-ssl,
my-cluster-name-ssl-internal, my-cluster-name-secrets, and
my-cluster-name-mongodb-keyfile by default).
Note
Replica will not start if the TLS secrets and the encryption key are not copied. If users are not copied, the replica will join the replica set, but it will be restarting due to failed liveness checks.
Copy your secrets from an existing cluster and apply each of them on your Replica site as follows:
$ kubectl apply -f my-cluster-secrets.yaml
The Replica site will be ready for replication when you apply changes as usual:
$ kubectl apply -f deploy/cr.yaml
Note
Don’t forget that you need to expose instances of the Replica cluster!