同じシャードキーへのコレクションの再シャーディング

このタスクについて

同じシャードキーに再シャーディングすると、データ移動メカニズムとしてリシャーディングを使用できます。これにより、次のことが可能になります。

再シャーディングしてシャード手法を使用して、コレクションをシャーディングし、そのデータを関連するすべてのシャードに分散する
新しいシャードの追加を高速化
シャードの削除がより高速化
ディスク領域を再利用するためにコレクションを書き換える

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

クローンフェーズは、現在のコレクションデータを複製します。
インデックス構築フェーズでは、再シャーディングされたコレクションにインデックスが構築されます。
キャッチアップフェーズは、保留中の書込み (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% 未満である。

手順

コレクションを再シャーディングします。

コレクションを再シャーディングするには、オプションをreshardCollection に設定したコマンドを使用します。forceRedistribution truereshardCollectionコマンドの構文は次のとおりです。

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>
   }
)

例、次のコマンドは、現在のシャードキー{ product_SKU : 1 } で info.productsInformationコレクションを再シャーディングします。

db.adminCommand(
   {
      reshardCollection: "info.productsInformation",
      key: { product_SKU : 1 },
      forceRedistribution: true
   }
)

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

リシャーディング操作をモニターするには、 $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>,
    ...
  },
  ...
]

詳細

戻る

同じシャードキーへの再シャーディング

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