MongoDB 8.0以降では、 moveCollectionコマンドを使用して、シャーディングされていないコレクションを別のシャードに移動できます。
このタスクについて
moveCollectionは、シャーディングされたクラスターでのみ実行できます。moveCollectionは、シャーディングされていないコレクションのみを移動できます。moveCollectionは一度に 1 つのコレクションのみを移動できます。moveCollectionの最小期間は5分です。MongoDB Search インデックスは、
moveCollectionの実行後に再構築する必要があります。moveCollectionが完了するまで、シャードの追加や削除、埋め込みコンフィギュレーションサーバーと専用コンフィギュレーションサーバー間での移行などのトポロジー変更を行うことはできません。moveCollectionの進行中に移動されるコレクションに対して次の操作を実行することはできません。moveCollectionが進行中の間は、クラスターに対して次の操作を実行することはできません。moveCollectionの進行中に発生するインデックスビルドは、メッセージが表示されずに失敗する可能性があります。moveCollectionの進行中は、インデックスを作成しないでください。インデックスビルドが進行中の場合は、
moveCollectionを呼び出しないでください。
アクセス制御
デプロイメントでアクセス制御が有効になっている場合、 enableShardingロールはmoveCollectionコマンドを実行するためのアクセスを許可します。
始める前に
コレクションを移動する 前に、次の要件を満たしていることを確認してください。
アプリケーションは、影響を受けるコレクションが書込みをブロックする期間を2 秒許容できます。 書込み (write) がブロックされている期間中、アプリケーションのレイテンシが増加します。
データベースが次のリソース要件を満たしている。
コレクションを移動するシャードに、コレクションとそのインデックス用の十分なストレージ領域があることを確認します。 宛先シャードでは少なくとも
( Collection storage size + Index Size ) * 2バイトが使用可能である必要があります。I/Oキャパシティーが50 % 未満であることを確認します。
CPU 負荷が80 % 未満であることを確認します。
重要
これらの要件はデータベースによって強制されません。 十分なリソースを割り当てられない場合、次の結果が発生する可能性があります。
データベースの容量が不足し、シャットダウンした
パフォーマンスの低下
操作に予想よりも時間がかかる
アプリケーションにトラフィックが少ない期間がある場合は、可能であれば、その時間中にコレクションに対してこの操作を実行します。
手順
コレクションを移動します。
appデータベース上のinventoryという名前のシャーディングされていないコレクションをshard02シャードに移動するには、 moveCollectionを実行します。
db.adminCommand( { moveCollection: "app.inventory", toShard: "shard02" } )
使用可能なシャード ID のリストを取得するには、 sh.status()を実行します。 詳細についてはsh.status() 出力 を参照してください。
moveCollection操作の進行状況を監視します。
残り時間を監視します。
moveCollection操作の残り時間をモニターするには、$currentOpパイプラインステージを使用します。次の例は、
app.inventoryコレクションでmoveCollectionの進行状況を確認する方法を示しています。db.getSiblingDB("admin").aggregate( [ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "app.inventory" } } ] ) 注意
更新された値を確認するには、前のパイプラインを継続的に実行する必要があります。
$currentOpパイプラインの出力は次のとおりです。totalOperationTimeElapsedSecs: 経過したoptime (秒単位)remainingOperationTimeEstimatedSecs: 現在のmoveCollection操作の推定残り時間(秒単位)。 新しいmoveCollection操作を開始すると、-1として返されます。
注意
remainingOperationTimeEstimatedSecsは悲観的な時間推定値に設定されています。- キャッチアップフェーズ時間の推定値はクローンフェーズ時間に設定され、
- は比較的長い時間です。
- 実際には、保留中の書込み操作が少ない場合、
- 実際のキャッチアップ フェーズ時間は比較的短いです。
このパイプラインステージには、次のような出力があります。
[ { shard: '<shard>', type: 'op', desc: 'ReshardingRecipientService | ReshardingDonorService | ReshardingCoordinatorService <reshardingUUID>', op: 'command', ns: '<database>.<collection>', originatingCommand: { reshardCollection: '<database>.<collection>', key: <shardkey>, unique: <boolean>, collation: { locale: 'simple' } }, totalOperationTimeElapsedSecs: <number>, remainingOperationTimeEstimatedSecs: <number>, ... }, ... ] 転送されるバイト数を監視します。
転送されるバイト数をモニターするには、
shardingStatistics.resharding.active.bytesCopiedを使用し、コレクション内のバイト数と比較します。
コレクションが移動されたことを確認します。
コレクションが予想されるシャードに移動されたことを確認するには、 $collStatsパイプラインステージを使用します。
次の例は、 app.inventoryコレクションが期待されるシャードに存在することを確認する方法を示しています。
db.inventory.aggregate( [ { $collStats: {} }, { $project: { "shard": 1 } } ] )
このパイプラインステージには、次のような出力があります。
[ { shard: 'shard02' } ]