MongoDB：シングルレプリカからマルチレプリカへ

MongoDB Helm Chart を使用してシングルレプリカからマルチレプリカに移行するプロセスには、いくつかのステップがあります。これらの手順については次のセクションで説明します。このガイドでは、古い MongoDB がデフォルトのネームスペースにインストールされていると仮定し、新しい MongoDB ReplicaSet を mongodb ネームスペースにインストールします。データ移行処理が簡単になるため、既存のクラスタの内部で移行を行うことを強く推奨します。

マルチレプリカ MongoDB Helm チャートのセットアップ

  1. こちらの公式ガイドに従って、3 つのレプリカからなる MongoDB Helm Release をセットアップします。
  2. 新しいセットアップでは、root パスワードを古いものと同じ値に設定する必要があります。既存のインストールのルートパスワードは、現在のKubernetesクラスタで次のコマンドを実行することで調べることができます：
kubectl get secret -n default cognigy-mongo-server -ojsonpath='{.data.mongo-initdb-root-password}' | base64 --decode

このパスワードを、新しいセットアップのvalues_prod.yamlファイルのauth.rootPasswordとmetrics.passwordとして使用します。

MongoDB接続文字列シークレットの変更

MongoDBにアクセスするために、Cognigy.AIのサービスはデータベース接続文字列を含むKubernetesシークレットを使用します。シークレットは新しいMongoDBのセットアップ用に調整する必要があります。このプロセスを自動化するスクリプトがこのリポジトリにあります。スクリプトを実行する前に、すべての古いシークレットが secretsフォルダに保存されていることをご確認ください。

git clone https://github.com/Cognigy/cognigy-mongodb-helm-chart.git
cd scripts
chmod +x secrets-migration.sh
./secrets-migration.sh

スクリプトは現在のMongoDB接続文字列をリクエストします（例：

mongo-server:27017

そして、新しい接続文字列を含む置換文字列を要求します　(例：

mongodb-0.mongodb-headless.mongodb.svc.cluster.local:27017,mongodb-1.mongodb-headless.mongodb.svc.cluster.local:27017,mongodb-2.mongodb-headless.mongodb.svc.cluster.local:27017

スクリプトを実行します：

./secrets-migration.sh
Enter current MongoDB host: mongo-server:27017
Enter new MongoDB host(s): mongodb-0.mongodb-headless.mongodb.svc.cluster.local:27017,mongodb-1.mongodb-headless.mongodb.svc.cluster.local:27017,mongodb-2.mongodb-headless.mongodb.svc.cluster.local:27017

スクリプトは、関連するすべての古いシークレットを original_secretsという名前のフォルダに保存し、調整したものを new_secrets という名前のフォルダに保存します。

MongoDBデータ移行

1. このステップではCognigy.AIのインストールを停止する必要があります。MongoDBデータ移行を開始する前に、Cognigy.AIインストールのデプロイメントをスケールダウンする必要があります：

for i in $(kubectl get deployment --namespace default --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}'|grep service-)
do
kubectl --namespace default scale --replicas=0 deployment $i
done

2. rs.status()を実行して新しいMongoDBクラスタのプライマリノードを確認します：

kubectl exec -it -n mongodb mongodb-0 bash
mongo -u root -p $MONGODB_ROOT_PASSWORD --authenticationDatabase admin
rs.status()

3. Multi-replicaのMongoDBをセットアップする場合：

  • 別のKubernetesクラスタ上 – ステップ5にスキップ。
  • シングルレプリカの MongoDB が動作しているのと同じ Kubernetes クラスタ上 – プライマリの MongoDB ポッドに接続。例えば、mongodb-0がプライマリノードの場合：
kubectl exec -it mongodb-0 -n mongodb -- bash

4. マルチレプリカ MongoDB セットアップのプライマリポッドに接続したら、次のコマンドを実行して既存のデータベースのダンプを取得し、マルチレプリカ MongoDB にリストアします：

mongodump --archive --authenticationDatabase admin -u admin -p <password> --host "mongo-server.default.svc:27017" | mongorestore --host "mongodb-0.mongodb-headless.mongodb.svc.cluster.local:27017" --authenticationDatabase admin -u root -p <password> --archive --drop

5. マルチレプリカのMongoDBセットアップを別のKubernetesクラスタでセットアップする場合、既存のデータベースをローカルのクライアントファイルシステムにダンプし、その後でマルチレプリカのセットアップにインポートする必要があります。この処理にかかる時間は、データベースのサイズとインターネット接続速度により大きく異なります。処理速度を速めるには、Kubernetesクラスタが稼働している同じデータセンターで稼働しているサーバーからコマンドを実行します。このシナリオに従う場合、事前にダンププロセスをテストし、停止時間を評価することを強くお勧めします：

a. ローカルファイルシステムにダンプするには、古いシングルレプリカのMongoDBポッドにログインします：

kubectl exec -it deployment/mongo-server -- bash
mkdir -p ./tmp/backup
mongodump --authenticationDatabase admin -u admin -p <password> --host "mongo-server.default.svc:27017" --out ./tmp/backup
exit
kubectl cp -n default <mongodb-pod-id>:/tmp/backup <path-to-the-local-directory>

b.  データをマルチレプリカの MongoDB クラスタにインポートします：

kubectl cp -n mongodb <path-to-the-local-directory> mongodb-0:/tmp/
kubectl exec -it mongodb-0 -n mongodb -- bash
mongorestore --host "mongodb-0.mongodb-headless.mongodb.svc.cluster.local:27017" --authenticationDatabase admin -u root -p <password> ./tmp/<backup-folder>

ここでは mongodb-0 をプライマリノードとします。mongodb-1 や mongodb-2 など、プライマリノードが異なる場合は変更してください。

6. 既存のシークレットを新しいシークレットに置き換えます：

kubectl replace -f new_secrets

ロールバックが発生した場合、以下を実施することで古いシークレットを復元できます：

kubectl delete -f new_secrets
kubectl apply -f original_secrets

7. すべてのデプロイメントをスケールアップして、期待通りに動くかを確認します。

8. new_secrets フォルダから secrets フォルダにシークレットを移動し、original_secrets フォルダを削除します。