You can convert an Ops Manager resource that uses an internally managed Application Database to one that uses an external Application Database: a MongoDB custom resource with spec.role set to AppDB. This lets Ops Manager back up and restore the Application Database. To learn more, see Back Up the Ops Manager Application Database.
The migration re-points ownership of the existing Application Database StatefulSet and its Persistent Volumes from the Ops Manager resource to the MongoDB resource. The Kubernetes Operator doesn't move or recreate your data, and it doesn't restart the Ops Manager pods.
How the Migration Works
The Ops Manager resource starts with an internally managed Application Database, and the Kubernetes Operator owns a StatefulSet named <primary-om-name>-db. The migration proceeds as follows:
You create a MongoDB resource with
spec.roleset toAppDBand the same name as the StatefulSet, in a project that a management Ops Manager instance manages. The MongoDB resource can't take ownership of the StatefulSet yet, so it stays in thePendingphase with a message that it can't take ownership of the Application Database StatefulSet.You add
spec.externalApplicationDatabaseRefto the Ops Manager resource. The Kubernetes Operator detaches the StatefulSet by removing the Ops Manager resource's owner reference and marking the StatefulSet as ready for migration. The MongoDB resource then takes ownership of it.
Because the Kubernetes Operator computes the same connection string as before, which uses the same hostnames, the Ops Manager pods don't restart.
Prerequisites
Before you begin, complete the following tasks:
Install the Kubernetes Operator and
kubectl. To learn more, see Install with Kubernetes.Deploy a primary Ops Manager resource that uses an internally managed Application Database. This resource sets
spec.applicationDatabase, and the Kubernetes Operator owns a StatefulSet named<primary-om-name>-db. To learn more, see Deploy an Ops Manager Resource.Deploy a management Ops Manager resource that is in the
Runningphase and that owns the project for the external Application Database. To learn more, see Deploy Ops Manager with an External Application Database.Confirm that the Kubernetes Operator created the programmatic API key secret for the management Ops Manager resource. The Kubernetes Operator names this secret
<namespace>-<management-om-name>-admin-key.
Considerations
Review the following considerations before you migrate:
The Application Database version that you set on the MongoDB resource must match the version that the internally managed Application Database runs, and it must be a MongoDB version that the management Ops Manager instance offers.
The Kubernetes Operator doesn't support
spec.applicationDatabase.passwordSecretKeyRefduring migration. The Kubernetes Operator generates a new password, and it rotates any password that you provided.The Application Database can be unavailable for one to two minutes if the MongoDB resource configuration differs from the internally managed Application Database configuration, such as a different pod template or a different set of containers. If the two configurations are semantically identical, the Application Database remains available.
The Kubernetes Operator supports migration on a single Kubernetes cluster only.
Procedure
Set the environment variables for the migration.
export K8S_CTX="<your-kube-context>" export MDB_NS="mongodb" export MANAGEMENT_OM_NAME="management-om" export PRIMARY_OM_NAME="primary-om" export APPDB_NAME="${PRIMARY_OM_NAME}-db" export APPDB_VERSION="8.0.5-ent" export MANAGEMENT_OM_URL="http://${MANAGEMENT_OM_NAME}-svc.${MDB_NS}.svc.cluster.local:8080" export MANAGEMENT_OM_ADMIN_KEY_SECRET="${MDB_NS}-${MANAGEMENT_OM_NAME}-admin-key" export APPDB_PROJECT_CONFIGMAP="${APPDB_NAME}-config" export APPDB_PROJECT_NAME="external-appdb"
Confirm the starting state.
Confirm that the primary Ops Manager resource and its internally managed Application Database are in the
Runningphase:kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \ -o jsonpath='{.status.opsManager.phase} / appdb={.status.applicationDatabase.phase}{"\n"}' Confirm that the Ops Manager resource owns the Application Database StatefulSet:
kubectl get statefulset "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \ -o jsonpath='{range .metadata.ownerReferences[*]}{.kind}/{.name}{"\n"}{end}' The command returns
MongoDBOpsManager/${PRIMARY_OM_NAME}.
Create the MongoDB resource for the external Application Database.
Give the resource the same name as the existing Application Database StatefulSet.
kubectl apply --context "${K8S_CTX}" -n "${MDB_NS}" -f - <<EOF apiVersion: mongodb.com/v1 kind: MongoDB metadata: name: ${APPDB_NAME} spec: members: 3 version: ${APPDB_VERSION} type: ReplicaSet role: AppDB opsManager: configMapRef: name: ${APPDB_PROJECT_CONFIGMAP} credentials: ${MANAGEMENT_OM_ADMIN_KEY_SECRET} persistent: true security: authentication: enabled: true modes: ["SCRAM"] ignoreUnknownUsers: true EOF
Confirm that the MongoDB resource waits for ownership.
Until the Ops Manager resource releases the StatefulSet, the MongoDB resource stays in the Pending phase. This is expected and isn't an error.
kubectl wait --for=jsonpath='{.status.phase}'=Pending \ mdb/"${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=300s kubectl get mdb "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \ -o jsonpath='{.status.message}{"\n"}'
The status message reports that the resource can't take ownership of the Application Database StatefulSet.
Add the external Application Database reference to the Ops Manager resource.
kubectl patch om "${PRIMARY_OM_NAME}" \ --context "${K8S_CTX}" -n "${MDB_NS}" \ --type merge \ -p "{\"spec\":{\"externalApplicationDatabaseRef\":{\"name\":\"${APPDB_NAME}\",\"kind\":\"MongoDB\"}}}"
You can remove spec.applicationDatabase in the same patch. Leaving it in place has no effect: once you set spec.externalApplicationDatabaseRef, the Kubernetes Operator stops managing an internal Application Database for this resource.
Wait for the migration to finish.
kubectl wait --for=jsonpath='{.status.phase}'=Running \ mdb/"${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=1200s kubectl wait --for=jsonpath='{.status.opsManager.phase}'=Running \ om/"${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=1800s
Verify the migration.
Confirm that the MongoDB resource owns the Application Database StatefulSet:
kubectl get statefulset "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \ -o jsonpath='{range .metadata.ownerReferences[*]}{.kind}/{.name}{"\n"}{end}' The command returns
MongoDB/${APPDB_NAME}.Confirm that the Ops Manager resource reports its Application Database as
Disabled, which means that the Kubernetes Operator no longer manages an internal Application Database for it:kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \ -o jsonpath='{.status.applicationDatabase.phase}{"\n"}' Confirm that the Ops Manager pods didn't restart by checking their age and restart counts:
kubectl get pods --context "${K8S_CTX}" -n "${MDB_NS}"
Common Migration Issues
The MongoDB Resource Reports a Version Error
If the MongoDB resource reports Failed with a message that the MongoDB version isn't available, set spec.version to a version that the management Ops Manager instance offers, and keep the Ops Manager version and the Application Database version on the same major version.
The MongoDB Resource Stays Pending After the Patch
The Kubernetes Operator must detach the StatefulSet before the MongoDB resource can take ownership of it. Confirm that you applied spec.externalApplicationDatabaseRef to the primary Ops Manager resource, and that the value of spec.externalApplicationDatabaseRef.name is exactly <primary-om-name>-db.
The MongoDB Resource Reports a Project Error
If the MongoDB resource stays in the Pending phase with a project or registration error, the management Ops Manager public API might not have been ready when you created the resource. Confirm that the management Ops Manager resource is in the Running phase and that its API answers requests, then reconcile the resource again.
The Ops Manager Pods Restart During the Migration
If the Ops Manager pods restart, the computed connection string changed. For a replica set that uses the default port, the connection string is identical before and after the migration. The Kubernetes Operator doesn't support non-default ports for this migration.
Next Steps
To back up the external Application Database, enable backup on the MongoDB resource in the project that the management Ops Manager instance manages. To learn more, see Configure MongoDB Database Backups.
To reverse this migration, see Return an External Application Database to Ops Manager.