シャードの追加と削除のための再シャーディング

このタスクについて

リシャーディングを使用して、シャーディングされたコレクションを新しいシャードに分散できます。また、を使用して、チャンクの移行よりも速くシャードを削除することもできます。

リシャーディング操作では、これらのフェーズを順番に実行されます。

クローンフェーズは、現在のコレクションデータを複製します。
インデックス構築フェーズでは、再シャーディングされたコレクションにインデックスが構築されます。
キャッチアップフェーズは、保留中の書込み (write) 操作をリシャーディングされたコレクションに適用します。
コミットフェーズでは、一時コレクションの名前を変更し、古いコレクションを削除してカットオーバーを実行します。

始める前に

リシャーディングする前に、クラスターのストレージ要件、レイテンシ要件、および追加のリソース要件を計算する必要があります。

ストレージ要件

次の式を使用して、最小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% 未満である。

手順

クラスターにシャードを追加または削除します。

クラスターにシャードを追加するには、「クラスターにシャードを追加する」を参照してください。クラスターからシャードを削除するには、「シャードクラスタからシャードを削除する」を参照してください。

シャーディングされたコレクションを同じシャードキーに一度に 1 つずつ再シャーディングします。

クラスター全体にデータを再分散するには、reshardCollection コマンドと forceRedistribution オプションを併用します。

db.adminCommand(
   {
      reshardCollection: "<db>.<collection>",
      key: { "<shardkey>" },
      forceRedistribution: true
   }
)

forceRedistribution: true を使用して再シャーディングすると、ドレイン状態ではないクラスター内のすべてのシャードにわたってデータが再書込まれます。デフォルトでは、リシャーディングでは numInitialChunks: 90 が使用されます。再シャーディングにより、クラスター内に少なくとも numInitialChunks - 1 チャンクが作成されます。90 を超えるシャードがある場合は、reshardCollection コマンドで numInitialChunks の数を増やします。

リシャーディング操作を監視します。

リシャーディング操作をモニターするには、 $currentOpパイプラインステージを使用できます。

db.getSiblingDB("admin").aggregate(
   [
     { $currentOp: { allUsers: true, localOps: false } },
     {
       $match: {
         type: "op",
         "originatingCommand.reshardCollection": "<database>.<collection>"
       }
     }
   ]
)

注意

更新された値を確認するには、パイプラインを継続的に実行する必要があります。

$currentOpパイプラインの出力は次のとおりです。

totalOperationTimeElapsedSecs: 経過したoptime （秒単位）
remainingOperationTimeEstimatedSecs: 現在のリシャーディング操作の推定残り時間（秒単位）。新たにリシャーディング操作を開始すると、 -1として返されます。
MongoDB 7.0 以降では、リシャーディング操作中にコーディネーターで remainingOperationTimeEstimatedSecs も使用できます。
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>,
    ...
  },
  ...
]

forceRedistribution: true を使用して再シャーディングすると、コレクションデータが関連するすべてのシャードに書き換えられ、古いコレクションが削除されます。これは、クラスター内のデータを移動する最速の方法です。

詳細

戻る

コレクションを同じシャードキーに再シャードします

参照