同じシャードキーへの再シャーディング
MongoDB 8.0 以降では、同じシャードキーに再シャーディングして、ダウンタイムやワークロードへの影響を与えずにデータを移動できます。これにより、次のことが可能になります。
再シャーディングしてシャード 手法を使用して、コレクションをシャーディングし、そのデータを関連するすべてのシャードに分散する
新しいシャードの追加を高速化
シャードの削除がより高速化
ディスク領域を再利用するためにコレクションを書き換える
MongoDB 8.0 以降、 の再シャーディングでは自然な順序スキャン を使用してデータが読み取られます。リシャーディングではまずすべてのデータがクローンされ、次に関連するインデックスが構築されるため、再シャーディング プロセスの速度が約 桁に向上します。
コマンド構文
forceRedistribution を true に設定して reshardCollection コマンドを使用し、同じキーに再シャーディングできます。
reshardCollection コマンドの構文は次のとおりです。
db.adminCommand( { reshardCollection: "<database>.<collection>", key: { "<shardkey>" }, unique: <boolean>, numInitialChunks: <integer>, collation: { locale: "simple" }, zones: [ { min: { "<document with same shape as shardkey>" }, max: { "<document with same shape as shardkey>" }, zone: <string> | null }, ], forceRedistribution: <bool> } )
詳しくは、 reshardCollection を参照してください。
ユースケース
再シャーディングは 、ダウンタイムやワークロードへの影響を与えずにデータを移動する戦略です。 「 再シャーディングからシャード 」手法を使用してコレクションをシャーディングし、すべてのシャードにデータを分散します。
リシャーディング を使用して、チャンクの移行 よりも速く、関連するすべてのシャードにコレクションを分散します。リシャーディング ではすべてのシャードへの書込みが並行して行われますが、各シャードは一度に 1 つのチャンク移行しか参加できません。再シャーディングにより、プロセスの最後に古いコレクションが削除されます。リシャーディングの最後には、孤立したドキュメントはありません。
シャードへの再シャーディング
「 リシャードからシャード 」手法では、再シャーディングを使用してコレクションをシャーディングし、クラスター内のすべてのシャードにデータを分散できます。
任意の数のシャードにわたる任意のサイズのコレクションを最初にシャーディング場合は、再シャードを使用してシャードを使用することを検討してください。配置がリソースの要件を満たしている場合は、シャーディングするコレクションがどれだけ大きいかに関係なく、再シャードを使用してシャードします。
動作
ストレージ
次の式を使用して、最小oplog ウィンドウが 24 時間であると仮定して、コレクションサイズとインデックスサイズを加算して、リシャーディング操作に必要なストレージ領域を計算します。
Available storage required on each shard = [(collection size + index size) *2 ] / number of shards the collection will be distributed across.
例、2 TB のコレクションと 4 シャードに分散された 400 GBのインデックスには、シャードごとに少なくとも 1.2 TB の使用可能なストレージが必要です。
[ (2 TB + 400GB) * 2 ] / 4 shards = 1.2 TB / shard
クラスターに使用可能なストレージがあることを確認する必要があります。
使用可能なスペースまたは I/O ヘッドルームが不十分な場合は、ストレージサイズを増やす必要があります。 CPU ヘッドルームが不十分な場合は、より大きなインスタンスサイズを選択してクラスターを増やすアップする必要があります。
Tip
MongoDBクラスターが Atlas でホストされている場合は、Atlas UIを使用して、ストレージ、 CPU、 I/O ヘッドルーム メトリクスを確認できます。
待ち時間
再シャーディング中のコレクションがブロックされる場合、アプリケーションが2 秒を許容できることを確認する必要があります。書込み (write) がブロックされると、アプリケーションのレイテンシが増加します。ワークロードがこの要件を許容できない場合は、 チャンクの移行 を使用してクラスターのバランスをとります。
追加のリソース要件
クラスターは、次の追加要件を満たしている必要があります。
最小oplog ウィンドウは 24 時間です。
I/Oキャパシティーが50% 未満。
CPU 負荷が 80% 未満である。