Ops Managerリソースによって、外部のアプリケーション データベースを内部管理に返すことができます。 Ops Managerリソースは既存のアプリケーションデータベースのステートメントを再利用し、それを管理していたMongoDBリソースを削除します。 Kubernetes Operator はデータを移動または再作成せず、Ops Manager ポッドを再起動しません。
移行の仕組み
Ops Managerリソースは、外部のアプリケーションspec.role AppDB<primary-om-name>-dbデータベースで起動します。これは、アプリケーション データベースのステートメントを所有する、 が に設定されているMongoDBリソースです。移行は、次のように進行します。
spec.externalApplicationDatabaseRefOps Managerリソースから を削除し、spec.applicationDatabaseを追加します。Kubernetes演算子は、 MongoDBリソースに ステートメントをリリースするよう要求します。 MongoDBリソースは、Ops Managerリソースが再利用するまで待機している間に
Pendingフェーズを報告します。Kubernetes Operator はステートメントを再利用し、それを内部アプリケーションデータベースとして管理します。接続文字列が変更されないため、Ops Manager ポッドは再起動しません。
何も所有しなくなったMongoDBリソースを削除します。
前提条件
始める前に、次のタスクを完了してください。
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フェーズにあり、アプリケーション データベースのステートメントを所有していることを確認します。
Considerations
移行する前に、次の考慮事項を確認してください。
spec.applicationDatabase.versionをアプリケーション データベースがすでに実行しているバージョンに設定します。同じバージョンを再利用すると、同じバイナリとデータが同じ場所で保持されます。別のバージョンでは、ハンドオーバーと同時にアプリケーション データベースのアップグレードが開始されます。Kubernetes Operator は、外部アプリケーション データベース用に作成した Ops Managerプロジェクトを削除しません。そのプロジェクトを削除すると、アプリケーション データベースの履歴メトリックが読み取れなくなるため、クリーンアップはユーザーが決定します。
手順
起動状態を確認します。
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"}' 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}.
内部のアプリケーションデータベースを使用するように Ops Managerリソースを再構成します。
このパッチは を削除し、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}\"}}}"
Ops Manager のリソースがステートメントを再利用するまで待ちます。
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"}' 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
移行 を確認します。
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}.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}" Ops Manager ポッドが再起動していないことを確認するには、経過時間と再起動カウントをチェックします。
kubectl get pods --context "${K8S_CTX}" -n "${MDB_NS}"
一般的な移行の問題
MongoDBリソースはステートメントをリリースしない
MongoDBリソースがRunning フェーズに留まり、ステートメントを引き続き所有している場合、Ops Managerリソースはリリースを要求していません。パッチがspec.externalApplicationDatabaseRef nullを に設定し、spec.applicationDatabase が追加されていることを確認します。
アプリケーション データベースのバージョンが一致しない
spec.applicationDatabase.versionをアプリケーション データベースがすでに実行しているバージョンに設定して、再利用されたステートメントが同じバイナリを保持するようにします。
MongoDBリソースを早く削除した
ステートメントを所有しているときにMongoDBリソースを削除すると、 Kubernetes のガベージは Atlas App Services のリソースと共有するステートメントとシークレットを収集します。回復するには、保持された永続ボリューム要求からアプリケーション データベースを再作成します。このパスはダウンタイムを発生させ、アプリケーション データベースの認証情報をローテーションします。詳細については、「 Ops Manager と AppDB リソースの障害復旧 」を参照してください。
次のステップ
外部のアプリケーション データベースを再度使用するには、「 アプリケーション データベースを外部配置に移行する 」を参照してください。