スタンドアロンから 1 ノードのレプリカセットへの移行

新しいプロジェクトの ConfigMap を作成します。

Ops Managerプロジェクトは1 つの配置を保持するため、スタンドアロン配置で使用するプロジェクトを再利用することはできません。スタンドアロンデプロイが参照する ConfigMap をコピーし、baseUrl とorgId の値を保持し、新しい一意のprojectName を設定します。スタンドアロン配置と同じKubernetes名前空間に ConfigMap を適用します。

詳しくは、「 ConfigMap を使用してMongoDB配置ごとに 1 つのプロジェクトを作成する 」を参照してください。

1 つのノードのレプリカセットを配置します。

MongoDBspec.typeReplicaSetをspec.members に、 を1 spec.versionに設定して、 リソースを作成します。スタンドアロン配置で実行されるのと同じMongoDBバージョンに を設定し、前の手順で作成した ConfigMapを参照。スタンドアロン配置で使用される認証情報のシークレットを再利用できます。スタンドアロンリソースから追加の spec設定をコピーします。

---apiVersion: mongodb.com/v1kind: MongoDBmetadata:  name: <my-replica-set>  namespace: <my-namespace>spec:  members: 1  # Must match the MongoDB version of the standalone deployment  version: "<mongodb-version>"  opsManager:    configMapRef:      # Must match metadata.name in the new project ConfigMap file      name: <configMap.metadata.name>  # Can match the credentials Secret that the standalone deployment uses  credentials: <mycredentials>  type: ReplicaSet  persistent: true...

リソースを適用します。

kubectl apply -f <replica-set-yaml> --namespace <my-namespace>

MongoDBリソースのステータスを確認するには、次のコマンドを使用します。

kubectl get mdb <resource-name> -o yaml -w

-w （監視）フラグが設定されている場合、構成が変更されると、ステータスフェーズがRunning状態に達するまで出力が直ちに更新されます。 リソース配置ステータスの詳細については、 「 Kubernetes 演算子のトラブルシューティング 」を参照してください。

ツール ポッドを配置します。

データベースポッドを実行するコンテナイメージには、 MongoDB Database Tools は含まれていません。 mongodump と mongorestore を実行するには、mongodb-enterprise-server イメージに基づいて専用のツール ポッドを配置します。スタンドアロン配置で実行されるのと同じMongoDBバージョンにイメージ タグを設定します。

---apiVersion: v1kind: Podmetadata:  name: mongodb-tools  namespace: <my-namespace>spec:  containers:  - name: mongodb-tools    # Use the standalone's MongoDB version without the -ent    # suffix, for example 8.0.4    image: quay.io/mongodb/mongodb-enterprise-server:<mongodb-version>-ubi9    command: ["sleep", "infinity"]...

ポッドを適用します。

kubectl apply -f <tools-pod-yaml> --namespace <my-namespace>

スタンドアロン配置への書き込みを停止します。

スタンドアロン配置へのすべてのアプリケーション書き込みを停止し、アプリケーションが新しいレプリカセットに接続するまで書き込みを停止したままにします。ダンプは、ダンプの開始後に発生する書込み (write) をキャプチャしません。

ドキュメント数とデータベースハッシュを記録します。

各コレクションのドキュメント数と、スタンドアロン配置にある各データベースの dbHash adminconfiglocalを記録します（ 、 、 データベースは除く）。復元では、admin データベースとconfig データベース、およびlocal データベースへのレプリケーション書込みが除外されるため、これらの値は一致しません。復元後、レプリカセットに対してこれらの測定を繰り返し、移行を確認します。

スタンドアロンデータをダンプします。

スタンドアロン配置のサービスに対してツールポッドから mongodump を実行します。

kubectl exec mongodb-tools --namespace <my-namespace> -- \  mongodump \  --host "<my-standalone>-svc.<my-namespace>.svc.cluster.local:27017" \  --out /tmp/dump

スタンドアロン配置に認証が必要な場合は、 ロールとbackup readAnyDatabaseロールを持つユーザーとして接続します。配置で TLS が必要な場合は、対応するmongodump 接続オプションを追加します。詳細については、「 mongodump 」を参照してください。

レプリカセットにデータを復元します。

レプリカセットのサービスに対してツール ポッドから mongorestore を実行します。

kubectl exec mongodb-tools --namespace <my-namespace> -- \  mongorestore \  --host "<my-replica-set>-svc.<my-namespace>.svc.cluster.local:27017" \  --nsExclude="admin.*" \  --nsExclude="config.*" \  /tmp/dump

オプションでは、 --nsExcludeデータベースと データベースが復元から除外されます。完全なadmin configmongodumpadmin.system.users出力には、 とadmin.system.version が含まれます。これらを復元すると、データベースユーザーと認証スキーマがオートメーション構成の外部のレプリカセットに書き込まれるため、Ops Manager 内のプロジェクトのユーザー リストはデータベースと一致しなくなります。

レプリカセットに認証が必要な場合は、後の手順でデータベースユーザーを再作成するため、レプリカセットにはまだユーザーがありません。 、 、MongoDBUser ロールを使用して新しいプロジェクトに一時的なrestore readWriteAnyDatabasedbAdminAnyDatabaseリソースを作成し、そのユーザーとして接続します。ユーザーの作成の詳細については、「 データベースユーザーの管理 」を参照してください。

レプリカセットにTLS が必要な場合は、対応するmongorestore 接続オプションを追加します。詳しくは、 mongorestore を参照してください。

復元されたデータを検証します。

レプリカセットに対して前の手順のドキュメント数と dbHash の測定を繰り返し、値がスタンドアロン配置で記録した値と一致していることを確認します。

データベースユーザーを再作成します。

MongoDBUserダンプにはデータベースユーザーは含まれません。新しいプロジェクトで各ユーザーを リソースとして再作成します。復元用に一時ユーザーを作成した場合は、ユーザーを再作成した後に削除してください。詳細については、「 データベースユーザーの管理 」と「 MongoDBユーザー リソースの仕様 」を参照してください。

アプリケーションをレプリカセットに送信します。

アプリケーションの接続文字列を更新して、1 つのメンバーのレプリカセットを参照。

スタンドアロン配置を削除します。

移行 を確認した後、スタンドアロンのMongoDB リソースを削除します。 Kubernetes Operator は、スタンドアロン配置で使用された永続的なボリューム クレームを削除しないため、クレームを手動で削除します。詳しくは、「 リソースを削除する MongoDB」を参照してください。