AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu

アプリケーション データベースの外部配置への移行

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.

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:

  1. You create a MongoDB resource with spec.role set to AppDB and 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 the Pending phase with a message that it can't take ownership of the Application Database StatefulSet.

  2. You add spec.externalApplicationDatabaseRef to 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.

Kubernetes Operator は同じホスト名を使用する以前と同じ接続文字列を計算するため、Ops Manager ポッドは再起動しません。

始める前に、次のタスクを完了してください。

  • 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 Running phase 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.

移行する前に、次の考慮事項を確認してください。

  • MongoDBリソースに設定するアプリケーション データベース バージョンは、内部で管理されるアプリケーション データベースが実行するバージョンと一致し、管理用の Ops Managerインスタンスが提供するMongoDBバージョンである必要があります。

  • The Kubernetes Operator doesn't support spec.applicationDatabase.passwordSecretKeyRef during migration. The Kubernetes Operator generates a new password, and it rotates any password that you provided.

  • MongoDB のリソース構成が、別のポッド テンプレートや別のコンテナのセットなど、内部で管理されているアプリケーション データベースの構成と異なる場合、アプリケーション データベースは 1 分から 2 分使用できなくなることがあります。 2 つの構成がセマンティクスで同一である場合は、アプリケーション データベースは引き続き使用できます。

  • Kubernetes Operator は、単一のKubernetesクラスターでの移行のみをサポートします。

1
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"
2
  1. Confirm that the primary Ops Manager resource and its internally managed Application Database are in the Running phase:

    kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \
    -o jsonpath='{.status.opsManager.phase} / appdb={.status.applicationDatabase.phase}{"\n"}'
  2. Ops Managerリソースがアプリケーション データベース ステートメントを所有していることを確認します。

    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}.

3
kubectl create configmap "${APPDB_PROJECT_CONFIGMAP}" \
--context "${K8S_CTX}" -n "${MDB_NS}" \
--from-literal=baseUrl="${MANAGEMENT_OM_URL}" \
--from-literal=projectName="${APPDB_PROJECT_NAME}" \
--from-literal=orgId=""
4

リソースに既存のアプリケーションデータベースステートメントと同じ名前を付けます。

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
5

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

ステータス メッセージは、リソースがアプリケーション データベースのステートメントを実行できないことを報告します。

6
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.

7
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
8
  1. MongoDBリソースがアプリケーション データベース ステートメントを所有していることを確認します。

    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}.

  2. 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"}'
  3. Ops Manager ポッドが再起動していないことを確認するには、経過時間と再起動カウントをチェックします。

    kubectl get pods --context "${K8S_CTX}" -n "${MDB_NS}"

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 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.

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.

Ops Manager ポッドが再起動すると、計算された接続文字列が変更されました。デフォルトポートを使用するレプリカセットの場合、接続文字列は移行 の前後で同一です。 Kubernetes Operator は、 この移行ではデフォルト以外のポートをサポートしていません。