コレクションの再シャーディング

このタスクについて

• 一度にリシャーディングできるコレクションは 1 つだけです。

• writeConcernMajorityJournalDefaultはtrueである必要があります。

• 一意の制約があるコレクションを再シャーディングするには、新しいシャードキーが既存の一意なインデックスの一意なインデックス要件を満たす必要があります。

• 次のコマンドと対応する shell メソッドは、再シャーディング操作の進行中に再シャーディングされるコレクションではサポートされていません。

  • collMod

  • convertToCapped

  • createIndexes

  • createIndex()

  • drop

  • drop()

  • dropIndexes

  • dropIndex()

  • renameCollection

  • renameCollection()

• リシャーディング操作の進行中、 クラスターでは以下のコマンドとメソッドはサポートされません。

  • addShard

  • removeShard

  • db.createCollection()

  • dropDatabase

  警告

  リシャーディング操作中に上記のコマンドのいずれかを使用すると、リシャーディング操作は失敗します。

• 再シャーディングするコレクションが Atlas Searchを使用する場合、再シャーディング操作の完了時に検索インデックスは使用できなくなります。 再シャーディング操作が完了してから、検索インデックスを手動で再構築する必要があります。

• シャーディングされた時系列コレクションを再シャーディングすることはできません。

始める前に

コレクションを再シャーディングする前に、次の要件を満たしていることを確認してください。

• アプリケーションは、再シャーディング中のコレクションが書込みをブロックする期間を2 秒許容できます。 書込み (write) がブロックされている期間中、アプリケーションのレイテンシが増加します。 ワークロードがこの要件を許容できない場合は、代わりにシャードキーの改良を検討してください。

• データベースが次のリソース要件を満たしている。

  • 使用可能なストレージ容量: コレクションを分散する各シャードで使用可能なストレージ容量が、少なくとも再シャーディングするコレクションのサイズとその合計インデックス サイズの 2 倍で、シャードの数で割られていることを確認してください。

    storage_req = ( ( collection_size + index_size ) * 2 ) / shard_count

    たとえば、 2 TB のデータを含み、4 つのシャードに分散された400 GB インデックスを持つコレクションを考えてみましょう。 このコレクションでリシャーディング操作を実行するには、各シャードに1.2が必要です TB の使用可能なストレージ。

    1.2 TB storage = ( ( 2 TB collection + 0.4 TB index ) * 2 ) / 4 shards

    ストレージ要件を満たすには、再シャーディング操作中に 1 つ上のストレージ階層にアップグレードする必要がある場合があります。 操作が完了したらスケールダウンできます。

  • I/O: I/O 容量が 50% 未満であることを確認します。

  • CPU 負荷: CPU 負荷が 80% 未満であることを確認します。

  重要

  これらの要件はデータベースによって強制されません。 十分なリソースを割り当てられない場合、次の結果が発生する可能性があります。

  • データベースの容量が不足し、シャットダウンした

  • パフォーマンスの低下

  • リシャーディング操作に予想よりも時間がかかる

  アプリケーションにトラフィックが少ない期間がある場合は、可能であれば、その時間中にコレクションを再シャーディングします。

• 現在のシャードキーと新しいシャードキーの両方を使用するには、アプリケーションのクエリを書き直す必要があります。

  Tip

  アプリケーションがダウンタイムを許容できる場合は、現在のシャードキーと新しいシャードキーの両方を使用するようにアプリケーションのクエリを書き換えるのを避けるために、次の手順を実行します。

  1. アプリケーションを停止します。

  2. 新しいシャードキーを使用するようにアプリケーションを書き換えます。

  3. リシャーディングが完了するまで待ちます。 リシャーディング プロセスをモニターするには、 $currentOpパイプライン ステージを使用します。

  4. 書き換えたアプリケーションをデプロイします。

  リシャーディングが完了する前に、クエリフィルターに現在のシャードキーまたは一意のフィールド（ _idなど）が含まれていない場合、次のクエリではエラーが返されます。

  • deleteOne()

  • findAndModify()

  • findOneAndDelete()

  • findOneAndReplace()

  • findOneAndUpdate()

  • replaceOne()

  • updateOne()

  最適なパフォーマンスを得るには、新しいシャードキーを含むように他のクエリも書き換えることをお勧めします。

  再シャーディング操作が完了したら、クエリから古いシャードキーを削除できます。

• インデックスのビルドは進行中ではありません。 実行中のインデックス ビルドを確認するには、 db.currentOp()を使用します。

   db.adminCommand(
      {
        currentOp: true,
        $or: [
          { op: "command", "command.createIndexes": { $exists: true }  },
          { op: "none", "msg" : /^Index Build/ }
        ]
      }
  )

  結果ドキュメントでは、 inprogフィールド値が空の配列の場合、インデックスビルドは進行中ではありません。

  {
     inprog: [],
     ok: 1,
     '$clusterTime': { ... },
     operationTime: <timestamp>
  }

手順

コレクションの再シャーディング操作では、シャードは次のようになります。

• ドナーは、シャーディングされたコレクションのチャンクを現在保存しています。

• 受信者。シャードキーとゾーンに基づいてシャーディングされたコレクションの新しいチャンクを保存します。

シャードは同時にドナーでも受信者でもあることができます。 ゾーン を使用する場合を除き、ドナー シャードのセットは受信者シャードと同じです。

コンフィギュレーションサーバーのプライマリは常にリシャーディング コーディネーターであり、リシャーディング操作の各フェーズを開始します。

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

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

[
  {
    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>,
    ...
  },
  ...
]

動作

エラーケース