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

外部アプリケーション データベースを MongoDB Ops Manager に返す

Ops Managerリソースによって、外部のアプリケーション データベースを内部管理に返すことができます。 Ops Managerリソースは既存のアプリケーションデータベースのステートメントを再利用し、それを管理していたMongoDBリソースを削除します。 Kubernetes Operator はデータを移動または再作成せず、Ops Manager ポッドを再起動しません。

Ops Managerリソースは、外部のアプリケーションspec.role AppDB<primary-om-name>-dbデータベースで起動します。これは、アプリケーション データベースのステートメントを所有する、 が に設定されているMongoDBリソースです。移行は、次のように進行します。

  1. Kubernetes演算子は、 MongoDBリソースに ステートメントをリリースするよう要求します。 MongoDBリソースは、Ops Managerリソースが再利用するまで待機している間に Pending フェーズを報告します。

  2. Kubernetes Operator はステートメントを再利用し、それを内部アプリケーションデータベースとして管理します。接続文字列が変更されないため、Ops Manager ポッドは再起動しません。

  3. 何も所有しなくなったMongoDBリソースを削除します。

警告

MongoDBリソースは、Ops Managerリソースが内部アプリケーションデータベースを再度管理した後にのみ削除します。ステートメントを所有しているときにMongoDBリソースを削除すると、 Kubernetes はアプリケーション データベースをゴミ箱とします。その状態から回復するには、保持されている永続ボリューム要求からアプリケーション データベースを再作成する必要があります。これにより、ダウンタイムが発生し、アプリケーション データベースの認証情報がローテーションされます。

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

  • Install the Kubernetes Operator and kubectl. To learn more, see Install with Kubernetes.

  • Ops Manager のプライマリリソースが外部のアプリケーションspec.externalApplicationDatabaseRef <primary-om-name>-dbspec.applicationDatabasestatus.applicationDatabase.phaseDisabledデータベースを使用していることを確認します。 が という名前のMongoDBリソースに設定されており、 が設定されておらず、その が を報告しています。

  • MongoDBリソースがRunning フェーズにあり、アプリケーション データベースのステートメントを所有していることを確認します。

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

  • spec.applicationDatabase.versionをアプリケーション データベースがすでに実行しているバージョンに設定します。同じバージョンを再利用すると、同じバイナリとデータが同じ場所で保持されます。別のバージョンでは、ハンドオーバーと同時にアプリケーション データベースのアップグレードが開始されます。

  • Kubernetes Operator は、外部アプリケーション データベース用に作成した Ops Managerプロジェクトを削除しません。そのプロジェクトを削除すると、アプリケーション データベースの履歴メトリックが読み取れなくなるため、クリーンアップはユーザーが決定します。

1
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"
2
  1. Ops Managerリソースが外部のアプリケーション データベースを参照し、そのアプリケーション データベースが Disabled として報告されていることを確認します。

    kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \
    -o jsonpath='ref={.spec.externalApplicationDatabaseRef.name} appdb={.status.applicationDatabase.phase}{"\n"}'
  2. 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}.

3

このパッチは を削除し、spec.externalApplicationDatabaseRef 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}\"}}}"
4
  1. MongoDBリソースがステートメントをリリースすることを確認します。リソースは、Ops Managerリソースへの逆移行が行われているというメッセージとともに Pending フェーズを報告します。

    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"}'
  2. Ops Managerリソースが内部アプリケーション データベースを再度管理するまで待ちます。

    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
5

前のステップで applicationDatabase.phase=Running が報告された後にのみ、このステップを完了します。

kubectl delete mdb "${APPDB_NAME}" \
--context "${K8S_CTX}" -n "${MDB_NS}" --wait=true --timeout=300s
6
  1. 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}.

  2. MongoDB Ops Managerリソースがアプリケーション データベースを Running として報告し、 MongoDBリソースが存在しないことを確認します。

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

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

MongoDBリソースがRunning フェーズに留まり、ステートメントを引き続き所有している場合、Ops Managerリソースはリリースを要求していません。パッチがspec.externalApplicationDatabaseRef nullを に設定し、spec.applicationDatabase が追加されていることを確認します。

spec.applicationDatabase.versionをアプリケーション データベースがすでに実行しているバージョンに設定して、再利用されたステートメントが同じバイナリを保持するようにします。

ステートメントを所有しているときにMongoDBリソースを削除すると、 Kubernetes のガベージは Atlas App Services のリソースと共有するステートメントとシークレットを収集します。回復するには、保持された永続ボリューム要求からアプリケーション データベースを再作成します。このパスはダウンタイムを発生させ、アプリケーション データベースの認証情報をローテーションします。詳細については、「 Ops Manager と AppDB リソースの障害復旧 」を参照してください。

外部のアプリケーション データベースを再度使用するには、「 アプリケーション データベースを外部配置に移行する 」を参照してください。