ApsaraDB for MongoDB：排查分區叢集添加新分區後資料不均衡的原因

1. 檢查均衡器是否已全域啟用

• 檢查方法

  在 mongosh 中執行 sh.getBalancerState() 返回 false，則表示均衡器未啟用。

• 解決方案

  若均衡器未啟用，參考管理MongoDB均衡器Balancer開啟。

2. 檢查均衡器是否在使用中視窗內

均衡器僅在設定的使用中視窗期（Active Window）內執行 Chunk 遷移。如果目前時間不在使用中視窗內，均衡器將不會工作。

• 檢查方法

  db.getSiblingDB("config").settings.find({_id:"balancer"})

  返回樣本：

   { _id: 'balancer', activeWindow: { start: '02:00', stop: '04:00' } }

  如果目前時間不在activeWindow內，則均衡器不會工作或者系統判斷無需均衡。

• 解決方案：修改使用中視窗

  如果使用中視窗設定不當（例如過短或與業務高峰重疊），建議將視窗期設定為時間長度足夠的業務低峰時段。

  例如，設定視窗期為每日淩晨 2 點到 6 點：

  db.getSiblingDB("config").settings.updateOne(
    { _id: "balancer" },
    { $set: { activeWindow : { start : "02:00", stop : "06:00" } } },
    { upsert: true }
  )

3. 確認是否處於初始資料均衡過程

剛添加分區後，系統需要時間將存量資料從舊分區遷移至新分區，此期間資料不均衡是正常現象，資料均衡所需時間與資料量級相關。

• 檢查方法

  通過 sh.isBalancerRunning() 確認均衡進度。

  // 檢查均衡器是否正在運行遷移任務
  sh.isBalancerRunning()

如果 sh.isBalancerRunning() 返回 true說明均衡進行中中。

• 解決方案

  耐心等待均衡過程自然完成，可參考如何確認增加或刪除Shard節點的進度瞭解過程。

1. 檢查是否存在大量未分區集合

一個資料庫內可以同時存在分區集合和非分區集合。非分區集合的資料會完整存放在其主分區（Primary Shard）上，均衡器無法對其進行遷移。如果大型集合未被分區，其資料將永遠無法分布到新分區上。

• 檢查方法

  使用以下指令碼統計指定資料庫中，未分區集合佔用的儲存空間。該指令碼會找出所有未分區的集合，並累加其儲存大小。

  說明

  該指令碼會遍曆庫內所有集合并執行 stats() 命令，可能對資料庫造成效能影響。為降低風險，指令碼內建了 sleep(200) 延時。如果庫內集合數量比較多，建議將sleep時間長度進一步提升到2000或者更高來避免可能的業務影響。

  // 指令碼：統計指定資料庫中未分區集合的儲存佔用
  // 將 "myDB" 替換為需要檢查的資料庫名稱
  var dbName = "myDB";
  
  var unshardSize = 0;
  var totalSize = 0;
  
  var unshardedCollections = [ ];
  
  
  db.getSiblingDB(dbName).getCollectionNames().forEach(function(collName) {
      var stats = db.getSiblingDB(dbName).getCollection(collName).stats();
      
      // 根據 stats.sharded 欄位判斷並累加儲存大小
      if (!stats.sharded) {
          unshardSize += (stats.storageSize || 0);
          unshardedCollections.push(dbName + "." + collName);
      }
      totalSize += (stats.storageSize || 0);
      
      // 每次查詢後短暫休眠，避免對資料庫造成過大壓力
      sleep(200);
  });
  
  print("--- " + dbName + " ---");
  print("Unsharded Collections Count: " + unshardedCollections.length);
  print("--------------------");
  print("Unsharded Storage Size (Bytes): " + unshardSize);
  print("Total Storage Size (Bytes): " + totalSize);
  print("--------------------");
  print("Unsharded Collections List:");
  printjson(unshardedCollections);
  

• 解決方案：參考設定資料分區以充分利用Shard效能。

2. 檢查分區集合資料量是否過小（MongoDB 6.0+）

從 MongoDB 6.0.3開始。均衡器只在集合中分區間最巨量資料量差值達到一定閾值（預設為chunk size的3倍）後才開始遷移。如果一個分區集合的總資料量小於均衡閾值，均衡器不會對其進行處理，導致其資料集中在單個分區上。

• 檢查方法

  使用 db.collection.getShardDistribution() 查看集合在各分區上的分布。如果一個分區集合的資料大部分集中在單個分區上，且分區間最巨量資料量差值遠小於均衡觸發閾值，則可能屬於此情況。

• 解決方案

  對於這類小資料量的分區集合，可適當調小其 chunkSize，觸發 Chunk 拆分和遷移。

  // 樣本將 test_db.test_coll 集合的 chunkSize 調整為 16MB，請根據集合資料分布情況調整合適的chunkSize
  db.adminCommand({
    configureCollectionBalancing: "test_db.test_coll",
    chunkSize: 16 // 單位為 MB，6.0+版本的預設值為128MB。
  })
  

  等待遷移完成後可通過db.collection.getShardDistribution()查看資料分布情況是否符合預期。