/ /

Deploy Ops Manager

Docs Home

Management

Controllers for Kubernetes Operator

Deploy Ops Manager

Docs Home

Management

Controllers for Kubernetes Operator

Deploy Ops Manager

Return an External Application Database to Ops Manager

You can return an external Application Database to internal management by the Ops Manager resource. The Ops Manager resource reclaims the existing Application Database StatefulSet, and you then delete the MongoDB resource that managed it. 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 external Application Database: a MongoDB resource with spec.role set to AppDB, named <primary-om-name>-db, that owns the Application Database StatefulSet. The migration proceeds as follows:

You remove spec.externalApplicationDatabaseRef from the Ops Manager resource and add spec.applicationDatabase.
The Kubernetes Operator asks the MongoDB resource to release the StatefulSet. The MongoDB resource reports the Pending phase while it waits for the Ops Manager resource to reclaim it.
The Kubernetes Operator reclaims the StatefulSet and manages it as an internal Application Database. Because the connection string doesn't change, the Ops Manager pods don't restart.
You delete the MongoDB resource, which no longer owns anything.

Warning

Delete the MongoDB resource only after the Ops Manager resource manages the internal Application Database again. If you delete the MongoDB resource while it still owns the StatefulSet, Kubernetes garbage collects the Application Database. Recovering from that state requires recreating the Application Database from the retained Persistent Volume Claims, which causes downtime and rotates the Application Database credentials.

Prerequisites

Before you begin, complete the following tasks:

Install the Kubernetes Operator and kubectl. To learn more, see Install with Kubernetes.
Confirm that the primary Ops Manager resource uses an external Application Database: it sets spec.externalApplicationDatabaseRef to a MongoDB resource named <primary-om-name>-db, it doesn't set spec.applicationDatabase, and its status.applicationDatabase.phase reports Disabled.
Confirm that the MongoDB resource is in the Running phase and owns the Application Database StatefulSet.

Considerations

Review the following considerations before you migrate:

Set spec.applicationDatabase.version to the version that the Application Database already runs. Reusing the same version keeps the same binaries and data in place. A different version starts an Application Database upgrade at the same time as the handover.
The Kubernetes Operator doesn't delete the Ops Manager project that it created for the external Application Database. Removing that project makes the Application Database's historical metrics unreadable, so cleaning it up is your decision.

Procedure

Set the environment variables for the migration.

export K8S_CTX="<your-kube-context>"
export MDB_NS="mongodb"
export PRIMARY_OM_NAME="primary-om"
export APPDB_NAME="${PRIMARY_OM_NAME}-db"
export APPDB_VERSION="8.0.5-ent"

Confirm the starting state.

Confirm that the Ops Manager resource references the external Application Database and reports its Application Database as Disabled:
```
kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \
  -o jsonpath='ref={.spec.externalApplicationDatabaseRef.name} appdb={.status.applicationDatabase.phase}{"\n"}'
```
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}.

Reconfigure the Ops Manager resource to use an internal Application Database.

This patch removes spec.externalApplicationDatabaseRef and adds spec.applicationDatabase.

kubectl patch om "${PRIMARY_OM_NAME}" \
  --context "${K8S_CTX}" -n "${MDB_NS}" \
  --type merge \
  -p "{\"spec\":{\"externalApplicationDatabaseRef\":null,\"applicationDatabase\":{\"members\":3,\"version\":\"${APPDB_VERSION}\"}}}"

Wait for the Ops Manager resource to reclaim the StatefulSet.

Confirm that the MongoDB resource releases the StatefulSet. The resource reports the Pending phase with a message that it is under reverse migration to the Ops Manager resource:

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"}'

Wait for the Ops Manager resource to manage the internal Application Database again:

kubectl wait --for=jsonpath='{.status.applicationDatabase.phase}'=Running \
  om/"${PRIMARY_OM_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

Delete the MongoDB resource.

Complete this step only after the previous step reports applicationDatabase.phase=Running.

kubectl delete mdb "${APPDB_NAME}" \
  --context "${K8S_CTX}" -n "${MDB_NS}" --wait=true --timeout=300s

Verify the migration.

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}.
Confirm that the Ops Manager resource reports its Application Database as Running and that the MongoDB resource no longer exists:
```
kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \
  -o jsonpath='{.status.applicationDatabase.phase}{"\n"}'
kubectl get mdb --context "${K8S_CTX}" -n "${MDB_NS}"
```
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 Doesn't Release the StatefulSet

If the MongoDB resource stays in the Running phase and still owns the StatefulSet, the Ops Manager resource hasn't requested the release. Confirm that your patch set spec.externalApplicationDatabaseRef to null and added spec.applicationDatabase.

The Application Database Version Doesn't Match

Set spec.applicationDatabase.version to the version that the Application Database already runs so that the reclaimed StatefulSet keeps the same binaries.

You Deleted the MongoDB Resource Too Early

If you delete the MongoDB resource while it still owns the StatefulSet, Kubernetes garbage collects the StatefulSet and the secrets that it shares with the Ops Manager resource. To recover, recreate the Application Database from the retained Persistent Volume Claims. This path causes downtime and rotates the Application Database credentials. To learn more, see Disaster Recovery for Ops Manager and AppDB Resources.

Next Steps

To use an external Application Database again, see Migrate an Application Database to an External Deployment.

Back

Migrate to an External Application Database

Upgrade