Migrate a Standalone to a One-Member Replica Set

Create a ConfigMap for a new project.

A Ops Manager project holds one deployment, so you can't reuse the project that the standalone deployment uses. Copy the ConfigMap that the standalone deployment references, keep the baseUrl and orgId values, and set a new, unique projectName. Apply the ConfigMap to the same Kubernetes namespace as the standalone deployment.

To learn more, see Create One Project Per MongoDB Deployment Using a ConfigMap.

Deploy a one-member replica set.

Create a MongoDB resource with spec.type set to ReplicaSet and spec.members set to 1. Set spec.version to the same MongoDB version that the standalone deployment runs, and reference the ConfigMap that you created in the preceding step. You can reuse the credentials secret that the standalone deployment uses. Copy any additional spec settings from the standalone resource.

---apiVersion: mongodb.com/v1kind: MongoDBmetadata:  name: <my-replica-set>  namespace: <my-namespace>spec:  members: 1  # Must match the MongoDB version of the standalone deployment  version: "<mongodb-version>"  opsManager:    configMapRef:      # Must match metadata.name in the new project ConfigMap file      name: <configMap.metadata.name>  # Can match the credentials Secret that the standalone deployment uses  credentials: <mycredentials>  type: ReplicaSet  persistent: true...

Apply the resource:

kubectl apply -f <replica-set-yaml> --namespace <my-namespace>

To check the status of your MongoDB resource, use the following command:

kubectl get mdb <resource-name> -o yaml -w

With the -w (watch) flag set, when the configuration changes, the output refreshes immediately until the status phase achieves the Running state. To learn more about resource deployment statuses, see Troubleshoot the Kubernetes Operator.

Deploy a tools pod.

The container images that run the database pods don't include the MongoDB Database Tools. To run mongodump and mongorestore, deploy a dedicated tools pod based on the mongodb-enterprise-server image. Set the image tag to the same MongoDB version that the standalone deployment runs.

---apiVersion: v1kind: Podmetadata:  name: mongodb-tools  namespace: <my-namespace>spec:  containers:  - name: mongodb-tools    # Use the standalone's MongoDB version without the -ent    # suffix, for example 8.0.4    image: quay.io/mongodb/mongodb-enterprise-server:<mongodb-version>-ubi9    command: ["sleep", "infinity"]...

Apply the pod:

kubectl apply -f <tools-pod-yaml> --namespace <my-namespace>

Stop writes to the standalone deployment.

Stop all application writes to the standalone deployment, and keep writes stopped until your applications connect to the new replica set. The dump doesn't capture writes that occur after the dump starts.

Record document counts and a database hash.

Record the document count of each collection and the dbHash of each database on the standalone deployment, except the admin, config, and local databases. The restore excludes the admin and config databases, and replication writes to the local database, so these values never match. After the restore, you repeat these measurements against the replica set to verify the migration.

Dump the standalone data.

Run mongodump from the tools pod against the standalone deployment's service:

kubectl exec mongodb-tools --namespace <my-namespace> -- \  mongodump \  --host "<my-standalone>-svc.<my-namespace>.svc.cluster.local:27017" \  --out /tmp/dump

If the standalone deployment requires authentication, connect as a user that has the backup and readAnyDatabase roles. If the deployment requires TLS, add the corresponding mongodump connection options. To learn more, see mongodump.

Restore the data to the replica set.

Run mongorestore from the tools pod against the replica set's service:

kubectl exec mongodb-tools --namespace <my-namespace> -- \  mongorestore \  --host "<my-replica-set>-svc.<my-namespace>.svc.cluster.local:27017" \  --nsExclude="admin.*" \  --nsExclude="config.*" \  /tmp/dump

The --nsExclude options exclude the admin and config databases from the restore. A full mongodump output includes admin.system.users and admin.system.version. Restoring them would write database users and the authentication schema into the replica set outside of the automation configuration, so the project's user list in Ops Manager would no longer match the database.

If the replica set requires authentication, the replica set has no users yet because you recreate your database users in a later step. Create a temporary MongoDBUser resource in the new project with the restore, readWriteAnyDatabase, and dbAdminAnyDatabase roles, and connect as that user. To learn more about creating users, see Manage Database Users.

If the replica set requires TLS, add the corresponding mongorestore connection options. To learn more, see mongorestore.

Verify the restored data.

Repeat the document counts and dbHash measurements from the earlier step against the replica set and confirm that the values match the values that you recorded on the standalone deployment.

Recreate the database users.

The dump doesn't carry database users. Recreate each user as a MongoDBUser resource in the new project. If you created a temporary user for the restore, delete it after you recreate your users. To learn more, see Manage Database Users and MongoDB User Resource Specification.

Direct your applications to the replica set.

Update your applications' connection strings to reference the one-member replica set.

Delete the standalone deployment.

After you verify the migration, delete the standalone MongoDB resource. The Kubernetes Operator doesn't delete the persistent volume claim that the standalone deployment used, so delete the claim manually. To learn more, see Remove a MongoDB resource.