ApsaraDB for MongoDB:シャードの追加または削除の進行状況を表示する

MongoDB 6.0 より前のバージョンで使用可能な方法

タスクを評価する前に、バランサーの操作結果と、移行するシャードコレクションのチャンク情報を取得する必要があります。バランサーの操作結果には、移行されたチャンクの数と移行に失敗したチャンクの数に関する統計が含まれます。

次のいずれかの方法を使用して、上記の情報を取得できます。

• 方法 1：sh.status() コマンドの出力結果を表示する

  sh.status() コマンドの出力結果では、バランサーの最近の操作結果と、移行するシャードテーブルのチャンク情報に焦点を当てる必要があります。次の例は、バランサーの最近の操作結果を示しています。

  ...
    balancer:
          Collections with active migrations: 
                  <db>.<collection> started at Wed Sep 27 2023 10:25:21 GMT+0800 (CST)
          Failed balancer rounds in last 5 attempts:  0
          Migration Results for the last 24 hours: 
                  300 : Success
    databases:
  ...

  次の例は、移行するシャードコレクションのチャンク情報を示しています。

  ...
  databases:
  ...
      {  "_id" : "<db>",  "primary" : "d-xxxxxxxxxxxxxxx3",  "partitioned" : true,  "version" : {  "uuid" : UUID("3409a337-c370-4425-ad72-8b8c6b0abd52"),  "lastMod" : 1 } }
            <db>.<collection>
                          shard key: { "<shard_key>" : "hashed" }
                          unique: false
                          balancing: true
                          chunks:
                                  d-xxxxxxxxxxxxxxx1      13630
                                  d-xxxxxxxxxxxxxxx2      13629
                                  d-xxxxxxxxxxxxxxx3      13652
                                  d-xxxxxxxxxxxxxxx4      13630
                                  d-xxxxxxxxxxxxxxx5      3719
                          too many chunks to print, use verbose if you want to force print
  ...

  上記の例では、d-xxxxxxxxxxxxxxx5 は追加されたシャードを示しています。パーティションテーブルが配置されているデータベースで getShardDistribution コマンドを実行して、データチャンクの分散に関する情報を取得することもできます。サンプルコード：

  use <db>
  db.<collection>.getShardDistribution()

• 方法 2：config データベースから関連情報を直接読み取る

  チャンクの統計をクエリし、シャードごとに集計します。サンプルコード：

  db.getSiblingDB("config").chunks.aggregate([{$group: {_id: "$shard", count: {$sum: 1}}}])

  指定されたシャードのチャンクをクエリし、名前空間ごとに集計します。サンプルコード：

  db.getSiblingDB("config").chunks.aggregate([{$match: {shard: "d-xxxxxxxxxxxxxx"}},{$group: {_id: "$ns", count: {$sum: 1}}}])

  前日に指定されたシャードに移行されたチャンクの数をクエリします。サンプルコード：

  // details.to フィールドを、チャンクの移行先となるシャードとして指定します。
  // time フィールドを ISODate タイプの期間として指定します。
  db.getSiblingDB("config").changelog.find({"what" : "moveChunk.commit", "details.to" : "d-xxxxxxxxxxxxx","time" : {"$gte": ISODate("2023-09-26T00:00:00")}}).count()

MongoDB 6.0 以降のバージョンで使用可能な方法

タスクを評価する前に、シャード間のデータ分散に焦点を当てる必要があります。sh.status() コマンドによって返される出力は引き続き参照として使用できます。ただし、出力を取得した後は、各シャードのチャンク数の不均一性ではなく、各シャードのデータ分散に注意を払う必要があります。

• シャードコレクションのデータ分散と均一性を取得する。

  次の図に示すように、getShardDistribution コマンドを実行して、シャードコレクションのデータ分散を取得し、データの均一性に焦点を当てることをお勧めします。

  次のコマンドを実行して、ドキュメントの数と合計サイズ、および孤立ドキュメントの数など、より詳細な分散を取得することもできます。

  db.getSiblingDB("admin").aggregate( [{ $shardedDataDistribution: { } },{ $match: { "ns": "<db>.<collection>" } }] ).pretty()

  次の例は、上記のコマンドの出力結果を示しています。出力は、シャード間でデータが著しく不均一であることを示しています。

  {
          "ns" : "<db>.<collection>",
          "shards" : [
                  {
                          "shardName" : "d-xxxxxxxxxxxxxxx1",
                          "numOrphanedDocs" : 0,
                          "numOwnedDocuments" : 504298920,
                          "ownedSizeBytes" : NumberLong("833101815840"),
                          "orphanedSizeBytes" : 0
                  },
                  {
                          "shardName" : "d-xxxxxxxxxxxxxxx2",
                          "numOrphanedDocs" : 0,
                          "numOwnedDocuments" : 250283901,
                          "ownedSizeBytes" : NumberLong("409714745937"),
                          "orphanedSizeBytes" : 0
                  },
                  {
                          "shardName" : "d-xxxxxxxxxxxxxxx3",
                          "numOrphanedDocs" : 0,
                          "numOwnedDocuments" : 109098088,
                          "ownedSizeBytes" : NumberLong("178157177704"),
                          "orphanedSizeBytes" : 0
                  },
                  {
                          "shardName" : "d-xxxxxxxxxxxxxxx4",
                          "numOrphanedDocs" : 0,
                          "numOwnedDocuments" : 382018055,
                          "ownedSizeBytes" : NumberLong("630329790750"),
                          "orphanedSizeBytes" : 0
                  }
            ]
  }

  出力は、次の項目も示しています。1. 上記のコマンドを実行したインスタンスには、4 つのシャードが含まれています。2. インスタンス内の <db>.<collection> という名前のシャードコレクションのデータ量は約 2051303530231 バイト（833101815840 + 409714745937 + 178157177704 + 630329790750）で、これは 1910.4 GB に相当します。

• 前日に正常に移行されたデータ量を表示する。

  次のコマンドを実行します。

  pipeline = [
      { '$match': {
          'what': 'moveChunk.commit',
      } },
      { '$group': {
          '_id': {
              'date': { '$dateToString': { 'format': '%Y-%m-%d', 'date': '$time'} },
           },
          'chunks_moved': { '$sum': 1 },
          'docs_moved': { '$sum': '$details.counts.cloned' },
          'bytes_moved': { '$sum': '$details.counts.clonedBytes' },
      } }, 
      { '$sort': { '_id.date': -1} },
  ]
  db.getSiblingDB("config").changelog.aggregate(pipeline)

  次の図は、上記のコマンドの出力結果を示しています。

  出力は、2024-09-21 に 183117965820 バイトが正常に移行されたことを示しており、これは 170.5 GB に相当します。

MongoDB 6.0 より前のバージョンで使用可能な方法

シャードコレクションから移行されたチャンクの数と、現在のシャードコレクションのデータ分散を取得したら、タスクの全体的な進行状況と予想される完了時間を推定できます。

シャードを追加するとします。シャードが追加される前は、チャンクの総数は変更されません。また、シャードの数も変更されないため、シャードを追加または削除するタスクは開始されません。シャードを追加している間、ビジネスワークロードは一定のままで、バランサーに関連するパラメーターはデフォルト値に設定されます。ステップ 3 の「MongoDB 6.0 より前のバージョンで使用可能な方法」で説明されている最初の例を使用します。この例は、次の項目を示しています。

• 5 つのシャードが追加されます。

• バランサーのタイムウィンドウ内で 300 個のチャンクが移行されます。

• <db>.<collection> という名前のシャードコレクションには、58,260 個のチャンクが含まれています。チャンクの数は、次の式に基づいて計算されます。13,630 + 13,629 + 13,652 + 13,630 + 3,719 = 58,260。

上記の結果に基づいて、次の値を計算できます。

• チャンクがシャードに均等に分散されている場合、各シャードのチャンク数は 11,652（58,260/5 = 11,652）です。

• 現在の移行速度に基づくと、移行の完了にはさらに 26.4 日かかります。日数は、次の式に基づいて計算されます。(11,652 - 3,719)/300 ≈ 26.4。

• シャードを追加するタスクの進行状況は 32%（3,719/11,652 = 32%）です。

MongoDB 6.0 以降のバージョンで使用可能な方法

シャードクラスターインスタンス内の 1 つのコレクションのみをバランスする必要があるとします。ステップ 3 の「MongoDB 6.0 以降のバージョンで使用可能な方法」で説明されている最初の例を使用します。この例は、次の項目を示しています。

• 4 つのシャードが追加されます。

• 2024-09-21 に 183117965820 バイトが正常に移行され、これは 170.5 GB に相当します。

• <db>.<collection> という名前のシャードコレクションのデータ量は約 2051303530231 バイト（833101815840 + 409714745937 + 178157177704 + 630329790750）で、これは 1910.4 GB に相当します。

上記の結果に基づいて、次の値を計算できます。

• シャード間でデータバランスが達成されると、各シャードのデータ量は約 512825882557.75 バイトで、これは 477.6 GB に相当します。

• シャード間でデータバランスを達成するには、シャード間で合計 875559682949 バイトを移行する必要があり、これは 815.4 GB に相当します。各シャードからの具体的なデータ移行：

  シャード 1 から移行されるデータ量は 320275933282.25 バイト（833101815840 - 512825882557.75）です。

  シャード 2 から移行されるデータ量は 103111136620.75 バイト（409714745937 - 512825882557.75）です。

  シャード 3 から移行されるデータ量は 334668704853.75 バイト（178157177704 - 512825882557.75）です。

  シャード 4 から移行されるデータ量は 117503908192.25 バイト（630329790750 - 512825882557.75）です。

  （320275933282.25 + 103111136620.75 + 334668704853.75 + 117503908192.25 = 875559682949）

• 現在の移行速度では、データバランスに到達するまでに約 4.8 日（815.4 GB/1 日あたり 170.5 GB）かかります。