ApsaraDB for MongoDB：如何確認增加或刪除Shard節點的進度

MongoDB 6.0之前版本操作方法

評估任務進度前，您需要擷取Balancer的運行結果（成功和失敗數量的統計）以及待遷移分區表的Chunk資訊。

您可以通過如下兩種方法擷取Balancer的運行結果和待遷移分區表Chunk資訊：

• 方法一：通過sh.status()命令的輸出結果擷取

  sh.status()命令的輸出結果僅需要關注兩部分資訊，第一部分為最近時間Balancer啟動並執行結果，樣本如下。

  ...
    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:
  ...

  第二部分為待遷移的分區表的Chunk資訊，樣本如下。

  ...
  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”即為新增的Shard節點。您也可以在分區表所在的庫執行getShardDistribution命令來擷取Chunk資料的分布資訊，樣本如下。

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

• 方法二：直接讀取config庫中的相關資訊

  查看Chunks統計，按分區彙總，樣本如下。

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

  查看指定分區上的Chunks，按namespace彙總，樣本如下。

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

  查看過去1天內成功遷移到指定Shard節點的Chunk數量，樣本如下。

  // details.to指定chunk遷移的目標shard
  // 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()的結果作為參考，但是在得到結果後，需要減少對各個分區上Chunks數量不均的關注，轉而關注分區上的資料量分布情況。

• 擷取分區表的分布資訊以及資料量的均勻情況。

  建議您優先通過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
                  }
            ]
  }

  通過該返回結果，您可以擷取到以下資訊：執行個體中有4個Shard節點，分區表<db>.<collection>的總資料量約為2051303530231位元組（833101815840+409714745937+178157177704+630329790750=2051303530231），摺合約為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之前版本操作方法

擷取分區表已成功遷移的Chunk數量以及當前分區表資料分布情況後，您就可以預估出任務的整體進度和預期完成時間。

假如當前增加Shard節點的情境中，總Chunk數量保持不變，Shard節點數量也保持不變（期間不會有新增或刪除Shard節點的任務），增加Shard節點的過程中業務負載基本保持固定，且Balancer的參數設定均為預設值。以步驟三的MongoDB 6.0之前版本操作方法中樣本為例，可以得知以下資訊：

• Shard節點數量為5。

• 在Balancer視窗期內，成功遷移的Chunk數量為300個。

• 分區表<db>.<collection>的總Chunk數量為58260個（13630+13629+13652+13630+3719=58260）。

因此可以計算出：

• 達到均衡狀態時，每個分區上的Chunk數量應為11652個（58260÷5=11652）。

• 按照當前的遷移速度，任務完成還需要26.4天（（11652-3719）÷300≈26.4）。

• 該增加Shard節點任務進度為32%（3719÷11652=32%）。

MongoDB 6.0之後版本操作方法

假如分區叢集執行個體中只有一個表需要均衡。以步驟三的MongoDB 6.0以後版本操作方法中樣本為例，可以得知以下資訊：

• Shard節點數量為4。

• 2024-09-21一天內移動的資料量約為170.5GB（183117965820位元組）。

• 分區表<db>.<collection>的總資料量約為1910.4GB（833101815840+409714745937+178157177704+630329790750=2051303530231位元組）。

因此可以計算出：

• 達到均衡狀態時，每個Shard上的資料量應大致為477.6GB（512825882557.75位元組）。

• 各個分區上為了達到均衡狀態，需要移動的總資料量為875559682949位元組，摺合815.4GB。其中：

  Shard1需要遷移的資料量為320275933282.25位元組（833101815840-512825882557.75）。

  Shard2需要遷移的資料量為103111136620.75位元組（409714745937-512825882557.75）。

  Shard3需要遷移的資料量為334668704853.75位元組（178157177704-512825882557.75）。

  Shard4需要遷移的資料量為117503908192.25位元組（630329790750-512825882557.75）。

  （320275933282.25+103111136620.75+334668704853.75+117503908192.25=875559682949）

• 按照當前的遷移速度，達到均衡狀態還需要大概4.8天（815.4 GB÷170.5 GB/天≈4.8天）。