このチュートリアルでは、シャーディングされたクラスターをシャーディングされていないレプリカセットに変換する方法について説明します。レプリカセットをシャーディングされたクラスターに変換するには、「 自己管理型レプリカセットをシャードクラスタに変換 」を参照してください。シャーディングされたクラスターの詳細については、 シャーディング に関するドキュメントを参照してください。
このチュートリアルでは、次のタスクについて説明します。
バランサーを無効にします。
クラスターをレプリカセットに変換します。
クラスターのロックを解除します（マルチシャード クラスターのみ）。
始める前に
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 8.3 以降では、以前にシャーディングされたクラスターであったレプリカセットをシャーディングされたクラスターに戻すことはできません。
シャーディングされたクラスターをレプリカセットに変換すると、 シャード ID documentなど、以前の配置のシャーディングメタデータが保持され、再度シャーディングされたクラスターになるのがブロックされます。自己管理型変換をシャーディングされたクラスターに戻しようとすると、 MongoDB はエラーを返します。
このようなレプリカセットをシャーディングされたクラスターに変換するには、テクニカル サポート にお問い合わせください。
手順
シャードが 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インスタンスから新しいレプリカセットにデータを移行します。configを実行する場合はmongorestore--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 } ]