このチュートリアルでは、シャーディングされたクラスターをシャーディングされていないレプリカセットに変換する方法について説明します。レプリカセットをシャーディングされたクラスターに変換するには、「 自己管理型レプリカセットをシャードクラスタに変換 」を参照してください。シャーディングされたクラスターの詳細については、 シャーディング に関するドキュメントを参照してください。
このチュートリアルでは、次のタスクについて説明します。
バランサーを無効にします。
クラスターをレプリカセットに変換します。
クラスターのロックを解除します（マルチシャード クラスターのみ）。
始める前に
MongoDB 8.0以降では、 directShardOperationsロールを使用して、シャードに対してコマンドを直接実行する必要があるメンテナンス操作を実行できます。
警告
directShardOperations ロールを使用して コマンドを実行すると、クラスターが正しく動作しなくなり、データが破損する可能性があります。Only use the directShardOperations ロール for maintenance purposes or under the ガイダンス of MongoDB support.メンテナンス操作の実行が終了したら、directShardOperations ロールの使用を停止します。
バージョンの互換性
このチュートリアルの手順にはMongoDB 6.0 以降が必要です。
承認
fsyncfsyncUnlockコマンドと コマンドには 認可アクションが必要です。このアクションは、fsync hostManagerロールまたはカスタムロールを通じて割り当てられます。
ユーザーとロール
シャーディングされたクラスターでは、 MongoDB はユーザーとロールの定義をadmin コンフィギュレーションサーバー の データベースに保存します。これらの定義は、クラスターを変換するときにレプリカセットに転送されません。
アプリケーションがレプリカセットに接続する前に、レプリカセットで必要な配置に必要なユーザーとロールを作成します。詳細については、「 自己管理型配置でのユーザーの作成 」および「 自己管理型配置でのユーザーとロールの管理 」を参照してください。
クラスター変換のスケジュール
チャンクの移行、再シャーディング、スキーマ変換が通常実行されない場合は、 クラスターを変換します 。
手順
シャードが 1 つしかないシャードクラスターの場合、そのシャードには完全なデータセットが含まれます。そのクラスターをシャーディングされていないレプリカセットに変換するには :
クラスターのレプリカセットへの変換
すべての
mongosインスタンスを停止します。新しいレプリカセットとなるシャードのレプリカセットに直接接続するようにアプリケーションを再構成します。
レプリカセットのノードのローリング再起動を実行して、
--shardsvrmongodから オプションを除きます。Tip
--shardsvrオプションを変更すると、mongodが着信接続をリッスンするポートが変更されます。
単一シャード クラスターは、データセットに対する読み取りおよび書き込み (write) 操作を受け入れる非シャーディングのレプリカセットになりました。必要に応じて、コンフィギュレーションサーバーを廃止できます。
複数のシャードを持つシャーディングされたクラスターから完全に新しいレプリカセットに移行するには、次の手順に従います。
バランサーを無効にし、クラスターをロックする
バランサーを無効にしてクラスターをロックには、次の手順に従います。
バランサー を停止するには、次のコマンドを実行します。
sh.stopBalancer()バランサーが無効になっていることを確認するには、次のコマンドを実行し、出力が
falseであることを確認します。sh.getBalancerState()シャーディングされたクラスターをロック、データベースへの書込みを防ぐには、次のコマンドを実行します。
db.getSiblingDB( "admin" ).fsyncLock()ロック を確認するには、次のコマンドを実行します。
db.getSiblingDB( "admin" ).aggregate( [ { $currentOp: { } }, { $facet: { "locked": [ { $match: { $and: [ { fsyncLock: { $exists: true } } ] } } ], "unlocked": [ { $match: { fsyncLock: { $exists: false } } } ] } }, { $project: { "fsyncLocked": { $gt: [ { $size: "$locked" }, 0 ] }, "fsyncUnlocked": { $gt: [ { $size: "$unlocked" }, 0 ] } } }] )出力で
fsyncLockedがtrueであることを確認します。これはクラスタがロックされていることを意味します。[ { fsyncLocked: true }, { fsyncUnlocked: false } ]
クラスターのレプリカセットへの変換
シャーディングされたクラスター をロックし、バランサーを無効にした状態で、シャーディングされたクラスターに加えて新しいレプリカセットを配置します。レプリカセットには、現在のすべてのシャードからのすべてのデータファイルを組み合わせて保持できる十分なキャパシティーが必要です。 データ転送が完了するまで、アプリケーションを新しいレプリカセットに接続するように構成しないでください。
mongodump と mongorestoreを使用して、
mongosインスタンスから新しいレプリカセットにデータを移行します。mongorestoreを実行する場合はconfigデータベースを除外します。--nsExcludeこの例に示すように、 オプションを使用します。mongorestore --nsExclude="config.*" <connection-string> /data/backup注意
必ずしもすべてのデータベースのすべてのコレクションがシャーディングされているわけではありません。 シャーディングされたコレクションのみを移行しないでください。 すべてのデータベースとすべてのコレクションが正しく移行されていることを確認します。
インスタンスの代わりに、シャーディングされていない レプリカセット
mongosを使用するようにアプリケーションを再構成します。シャーディングされたクラスターをレプリカセットに変換した後、アプリケーションで使用される 接続文字string stringをレプリカセットの に更新します。次に、アプリケーションを再起動します。
アプリケーションでは、読み取りと書き込みにシャーディングされていないレプリカセットが使用されるようになりました。残っている未使用のシャーディングされたクラスター インフラストラクチャを廃止できるようになりました。
クラスターのロック解除
シャーディングされたクラスターをレプリカセットに変換した後、クラスターのロックを解除します。
クラスターのロックを解除してデータベースへの書込みを再開できるようにするには、次のコマンドを実行します。
db.getSiblingDB( "admin" ).fsyncUnlock()ロックを確認するには、次のコマンドを実行します。
db.getSiblingDB( "admin" ).aggregate( [ { $currentOp: { } }, { $facet: { "locked": [ { $match: { $and: [ { fsyncLock: { $exists: true } } ] } } ], "unlocked": [ { $match: { fsyncLock: { $exists: false } } } ] } }, { $project: { "fsyncLocked": { $gt: [ { $size: "$locked" }, 0 ] }, "fsyncUnlocked": { $gt: [ { $size: "$unlocked" }, 0 ] } } }] )出力に
fsyncLockedがfalseであることが表示されていることを確認します。これは、クラスタがロックされていないことを意味します。[ { fsyncLocked: false }, { fsyncUnlocked: true } ]