このチュートリアルでは、 のシャーディングされたクラスターをシャーディングされていないレプリカセットに変換する方法について説明します。レプリカセットをシャーディングされたクラスターに変換するには、「 自己管理型レプリカセットをシャードクラスタに変換 」を参照してください。シャーディングされたクラスターの詳細については、 シャーディング に関するドキュメントを参照してください。
始める前に
バージョンの互換性
このチュートリアルの手順にはMongoDB 6.0 以降が必要です。
承認
fsyncfsyncUnlockコマンドと コマンドには 認可アクションが必要です。このアクションは、fsync hostManagerロールまたはカスタムロールを通じて割り当てられます。
クラスター変換のスケジュール
チャンクの移行、再シャーディング、スキーマ変換が通常実行されない場合は、 クラスターを変換します 。
バランサーを無効にし、クラスターをロックする
バランサーを無効にしてクラスターをロックには、次の手順に従います。
- バランサー を停止するには、次のコマンドを実行します。 - 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 } ] 
単一シャードを含むクラスターのレプリカセットへの変換
シャードが 1 つしかないシャーディングされたクラスターの場合、そのシャードには完全なデータセットが含まれます。 次の手順を使用して、そのクラスターをシャーディングされていないレプリカセットに変換します。
- システムが新しいレプリカセットとなる単一シャードをホストしているレプリカセットのプライマリ ノードに接続するようにアプリケーションを再構成します。 
- --shardsvr- mongodから オプションを削除します。- Tip- --shardsvrオプションを変更すると、- mongodが着信接続をリッスンするポートが変更されます。
単一シャード クラスターは、データセットに対する読み取りおよび書込み (write) 操作を受け入れる非シャーディングのレプリカセットになりました。
シャーディングされたクラスターのレプリカセットへの変換
複数のシャードを持つシャーディングされたクラスターから完全に新しいレプリカセットに移行するには、次の手順に従います。
- シャーディングされたクラスター をロックし、バランサーを無効にした状態で、シャーディングされたクラスターに加えて新しいレプリカセットを配置します。レプリカセットには、現在のすべてのシャードからのすべてのデータファイルを組み合わせて保持できる十分なキャパシティーが必要です。 データ転送が完了するまで、アプリケーションを新しいレプリカセットに接続するように構成しないでください。 
- アプリケーションを再構成するか、すべての - mongosインスタンスを停止します。すべての- mongosインスタンスを停止すると、アプリケーションはデータベースから読み取れなくなります。すべての- mongos- mongosインスタンスを停止する場合は、データ移行手順のためにアプリケーションがアクセスできない一時的な インスタンスを開始します。
- mongodump と mongorestoreを使用して、 - mongosインスタンスから新しいレプリカセットにデータを移行します。- mongorestoreを実行する場合は- configデータベースを除外します。- --nsExcludeこの例に示すように、 オプションを使用します。- mongorestore --nsExclude="config.*" <connection-string> /data/backup - 注意- 必ずしもすべてのデータベースのすべてのコレクションがシャーディングされているわけではありません。 シャーディングされたコレクションのみを移行しないでください。 すべてのデータベースとすべてのコレクションが正しく移行されていることを確認します。 
- インスタンスの代わりに、シャーディングされていない レプリカセット - mongosを使用するようにアプリケーションを再構成します。- シャーディングされたクラスターをレプリカセットに変換した後、アプリケーションで使用される 接続文字string stringをレプリカセットの に更新します。次に、アプリケーションを再起動します。 
アプリケーションは、読み取りと書込みにシャーディングされていないレプリカセットを使用するようになりました。 残りの未使用のシャーディングされたクラスター インフラストラクチャを廃止できるようになりました。
次のステップ
シャーディングされたクラスターをレプリカセットに変換した後、次の手順を実行してクラスターのロックを解除します。
- クラスターのロックを解除してデータベースへの書込みを再開できるようにするには、次のコマンドを実行します。 - 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が- falseであることが表示されていることを確認します。これは、クラスタがロックされていないことを意味します。- [ { fsyncLocked: false }, { fsyncUnlocked: true } ]