均衡器的用途
均衡器是一個後臺執行緒,執行於配置伺服器(config server)副本集的主節點。它定期檢查分片中塊(chunks)和資料的分佈情況。如果達到某些遷移閾值,均衡器就會決定將塊從一個分片遷移到另一個分片。其主要目標是在所有分片中擁有大致相同的資料量。
在繁忙的叢集中,遷移的成本可能很高。每次遷移都需要從源分片讀取大量文件,然後寫入目標分片。因此,有一個限制:給定一個分片對(shard pair),每次只能移動一個分片。因此,在 N 個分片叢集中,最多隻能同時遷移 N/2 個分片。
如果你在集合中定義的所有分塊鍵都是最優的,那麼均衡器管理的遷移量應該是最小的,或者最終接近於零。如果分塊鍵不理想或集合設計不合理,就會導致大量昂貴的遷移,從而拖慢整個叢集的執行速度。更糟糕的情況是,均衡器無法執行所有需要的遷移,這樣就會導致叢集不平衡,無法管理。
如果沒有定義好分片鍵,你也可以改變主意,建立新的分片鍵。遺憾的是,對大型資料集重新分片的成本很高,應儘量避免。
均衡器的策略
均衡器在開發之初就設定了當分片達到特定的遷移閾值時,對分片中的某一塊進行遷移。這些閾值適用於擁有最多資料集資料塊的分片與擁有最少資料集資料塊的分片之間的資料塊數量差異。
均衡器會持續地將塊從源分片移動到塊數較少的目標分片,確保資料可用於讀寫。這個簡單的邏輯有助於在所有分片中保持大致相同的塊數。
下表顯示了遷移閾值。
塊數 |
遷移閾值 |
小於20 |
2 |
20--79 |
4 |
超過80 |
8 |
遺憾的是,這種邏輯有一些侷限性。在許多使用案例中,有可能擁有不同資料量的資料塊。有些資料塊可能是滿的,接近允許的最大資料塊大小,而另一些資料塊可能接近空。這主要取決於你在集合中定義的分片鍵。如果你的分塊鍵不夠理想,不能提供均勻分佈的值,那麼就有可能出現這種情況。
均衡器進行的遷移可以起到幫助作用,但要記住遷移的成本很高,而且在某些情況下執行遷移的速度不足以確保資料的均勻分佈。分片之間的資料差異可能會持續擴大。
從 MongoDB 6.0 版開始,均衡器邏輯發生了重要變化。策略不再計算分片中塊的數量,而是計算分片中資料的實際大小。遷移閾值仍然有效,但現在無論有多少塊,它們都基於資料的實際大小。
如果一個資料集的分片之間的資料差異小於該資料集配置範圍大小的三倍,那麼該資料集就被認為是平衡的。對於 128 MB 的預設範圍大小,只有當同一資料集的兩個分片之間的資料大小差異至少達到 384 MB 時,才會發生遷移。該閾值受塊的最大大小影響。設定不同的塊大小也會改變閾值,計算公式仍然為塊大小的三倍。
新策略有助於獲得更均衡的群集,即使在分片建並非最佳的情況下也是如此。不過,請記住,非常糟糕的分片鍵會導致叢集非常不穩定。新的均衡器策略並不神奇,無法幫助解決糟糕的情況。
新的自動合併(Automerger)功能
合併塊一直都可以手動完成。有了 mergeChunks 管理命令,就可以合併同一分片中連續的資料塊。合併可以避免有太多資料量過少的資料塊。更多的塊也會使配置資料庫變大,降低效率。從 7.0 版開始,均衡器內部部署了新的自動合併功能。也可以使用 mergeChunks 命令進行手動合併。
Automerger 作為配置伺服器副本集主節點中常規 Balancer 執行緒的一部分執行。
每次執行時,自動合併器都會檢查同一集合中符合特定合併要求的資料塊,並自動將它們合併。可以同時合併兩個或多個資料塊。這裡列出了可合併性要求,所有要求都必須滿足:
·資料塊必須位於同一分片中
·它們不是巨型塊( jumbo chunks)
·它們的歷史記錄可以在不中斷事務和快照讀取的情況下被安全清除
如果需要,可以禁用或配置 Automerger,使其僅在均衡器視窗期間執行。可以透過mongosh客戶端進行開啟或者禁用。比如:
開啟
sh.enableAutoMerger( <namespace> )
禁用
sh.disableAutoMerger( <namespace> )
也可以使用以下管理命令:
db.adminCommand( { configureCollectionBalancing: "<db>.<collection>", chunkSize: <num>, defragmentCollection: <bool> enableAutoMerger: <bool> } )
Automerger 是能幫助你自動最佳化叢集,不再需要考慮手動合併塊的問題。在文件中,你可以獲得更多詳細資訊: https://www.mongodb.com/docs/manual/core/automerger-concept/
總結
7.0 中引入的 Automerger 和 6.0 中的新 Balancer 策略可以簡化管理任務,並有助於獲得更穩定、更可靠的分片叢集。
MongoDB 發展非常迅速。每年都會釋出一個新的主版本,而舊版本在短短几年內就會失去支援。如果還在使用舊版本,建議儘快升級到 7.0。5.0 版本的生命週期將於 2024 年 10 月結束。6.0 版本將於 2025 年 7 月到期。