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

移行の仕組み

MongoDB Ops Manager リソースは、外部アプリケーションデータベースから始まります。このデータベースは、spec.role が AppDB に設定され、<primary-om-name>-db という名前の MongoDB リソースであり、アプリケーションデータベース StatefulSet を所有します。移行は次のように進行します。

1. MongoDB Ops Manager リソースから spec.externalApplicationDatabaseRef を除き、spec.applicationDatabase を追加します。

2. Kubernetes 演算子は、MongoDBリソースに対してStatefulSetを解放するように要求します。MongoDBリソースは、MongoDB Ops Managerリソースによる再利用を待機している間、Pendingフェーズを報告します。

3. Kubernetes Operator は StatefulSet を回収し、内部アプリケーションデータベースとして管理します。接続文字列が変更されないため、Ops Managerの pod は再起動しません。

4. MongoDBリソースを削除すると、そのリソースは何も所有しなくなります。

前提条件

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

• Kubernetes 演算子と kubectl をインストールします。詳細については、「Kubernetes を使用したインストール。」を参照してください。

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

• MongoDB リソースが Running フェーズにあり、アプリケーションデータベース StatefulSet を所有していることを確認してください。

Considerations

移行する前に、次の検討事項を検討してください。

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

• Kubernetes 演算子は、外部のアプリケーションデータベース用に作成したMongoDB Ops Managerプロジェクトを削除しません。そのプロジェクトを除くと、アプリケーションデータベースの過去のメトリクスが読み取れなくなるため、クリーンアップするかどうかはユーザーが判断してください。

手順

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"

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

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

マルチクラスター アプリケーション データベースを返す

プライマリ Ops Managerリソースが外部の MongoDB MultiCluster Application Database を参照している場合は、それを内部で管理されているマルチクラスターの Application Database に戻すことができます。 Kubernetes Operator は、MongoDB MultiClusterリソースに対して、各ノード クラスタでアプリケーション データベース ステートメントをリリースするように要求します。その後、Ops Managerリソースは各ステートメントを内部アプリケーションデータベースとして再取得します。接続文字列が変更されないため、Ops Manager ポッドは再起動しません。

この手順は、次の違いを除いて、このページの単一クラスターの手順と一致します。

• ノード クラスターとアプリケーション データベース TLS 構成用に次の追加の環境変数を設定します。外部アプリケーション データベースが使用するのと同じ値を使用します。

  export K8S_CTX_MEMBER_1="<member-cluster-1-context>"export K8S_CTX_MEMBER_2="<member-cluster-2-context>"export APPDB_CERT_PREFIX="appdb"export APPDB_CA_CONFIGMAP="${APPDB_NAME}-ca"

• 復元されたspec.applicationDatabase は、topology をMultiCluster に設定し、外部アプリケーション データベースと同じノード 配置と TLS 構成を使用する必要がある必要があります。これにより、Ops Managerリソースは既存の Atlas App Services を再利用できるようになります。

  kubectl patch om "${PRIMARY_OM_NAME}" \  --context "${K8S_CTX}" -n "${MDB_NS}" \  --type merge \  -p "{\"spec\":{\"externalApplicationDatabaseRef\":null,\"applicationDatabase\":{\"topology\":\"MultiCluster\",\"version\":\"${APPDB_VERSION}\",\"security\":{\"certsSecretPrefix\":\"${APPDB_CERT_PREFIX}\",\"tls\":{\"ca\":\"${APPDB_CA_CONFIGMAP}\"}},\"clusterSpecList\":[{\"clusterName\":\"${K8S_CTX_MEMBER_1}\",\"members\":2},{\"clusterName\":\"${K8S_CTX_MEMBER_2}\",\"members\":2}]}}}"

• MongoDB リソースはPending フェーズを報告し、Ops Managerリソースはステートメントを再利用します。 MongoDB MultiClusterリソースは、status.applicationDatabase.phase が Running を報告した後にのみ削除します。

• 移行を確認するには、<primary-om-name>-db-<cluster-index> という名前の各ノードクラスターのアプリケーション データベース ステートメントを調べます。引き継ぎ後、StatusSet は空の ownerReferences のままで維持され、Ops Managerリソースはそれを内部アプリケーション データベースとして管理します。

一般的な移行の問題

次のステップ

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