對(dui)于集群方式部署的實例，常(chang)見Shard間負載(zai)不(bu)均衡，一般(ban)有(you)如下原因(yin)：沒有(you)做(zuo)分片，片鍵(jian)選(xuan)擇不(bu)正確，不(bu)做(zuo)chunk預(yu)置(zhi)，shard間均衡速度低于數據插入速度等。
排查方法
步驟 1 通過客(ke)戶(hu)端連接數據庫(ku)。
步驟 2 執(zhi)行如下命令，查看分片信息。
mongos> sh.status()
\--- Sharding Status ---
sharding version: {
"_id" : 1,
"minCompatibleVersion" : 5,
"currentVersion" : 6,
"clusterId" : ObjectId("60f9d67ad4876dd0fe01af84")
}
shards:
{ "_id" : "shard_1", "host" : "shard_1/172.16.51.249:8637,172.16.63.156:8637", "state" : 1 }
{ "_id" : "shard_2", "host" : "shard_2/172.16.12.98:8637,172.16.53.36:8637", "state" : 1 }
active mongoses:
"4.0.3" : 2
autosplit:
Currently enabled: yes
balancer:
Currently enabled: yes
Currently running: yes
Collections with active migrations:
test.coll started at Wed Jul 28 2021 11:40:41 GMT+0000 (UTC)
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
300 : Success
databases:
{ "_id" : "test", "primary" : "shard_2", "partitioned" : true, "version" : { "uuid" : UUID("d612d134-a499-4428-ab21-b53e8f866f67"), "lastMod" : 1 } }
test.coll
shard key: { "_id" : "hashed" }
unique: false
balancing: true
chunks:
shard_1 20
shard_2 20
- “databases”中列出的所有數據庫都是通過enableSharding開放了分片的庫。
- “test.coll”表示開啟分片的namespace信息，其中test為集合所在的庫名，coll為開啟分片的集合名。
- “shard key”表示前面集合的分片鍵，分片方式“_id : hashed”表示通過_id進行哈希分片，如果是“_id : -1”，則代表通過_id的范圍進行分片。
- “chunks”代表分片的分布情況。
步驟(zou) 3 根據步驟(zou)2查詢出的(de)結果，分(fen)析分(fen)片信(xin)息。
- 如果業務性能存在瓶頸的數據庫和集合，在上述“databases”以及子項中不存在，則說明業務集合沒有進行分片。對于集群來說這意味著業務只有一個Shard承載，沒有應用DDS的水平擴展能力。
此場景下(xia)可以(yi)通過如(ru)下(xia)的(de)命令開啟分片，充分發揮實例的(de)水平擴展(zhan)能(neng)力。
mongos> sh.enableSharding("<database>")
mongos> use admin
mongos> db.runCommand({shardcollection:"<database>.<collection>",key:{"keyname":<value> }})
- 如果“shardKey”分片片鍵選擇不合理，也會導致負載不均衡。典型場景有業務熱點數據分布在某個范圍內，而分片的片鍵選擇范圍分片的方式，那么可能會出現熱點數據所在的chunk對應的Shard負載會明顯的高于其他Shard，最終導致整體性能出現瓶頸。
此場景下(xia)可以通過重新設計片(pian)鍵的(de)分布(bu)方式來達到目標，比(bi)如(ru)將范圍分片(pian)修(xiu)改(gai)為哈(ha)希分片(pian)。
mongos> db.runCommand({shardcollection:"<database>.<collection>",key:{"keyname":<value> }})
說明
一個集合選擇了分片方式，則不能在原(yuan)集合上隨時修改。所在集合在設(she)計階(jie)段需要充分考慮分片方式。
更多關于設置數據分片的內容請參見設置數據分片以充分利用分片性能。
- 如果存在集中大批量的插入數據的場景，數據量超過單shard承載能力的話，可能會出現Balance速度趕不上插入速度，導致主shard存儲空間占用率過高。
此場景可(ke)以(yi)使用sar命令查看服務器網(wang)(wang)絡連接情況(kuang)，分析(xi)每(mei)個網(wang)(wang)卡的傳輸(shu)量和是否達到傳輸(shu)上(shang)限。
sar -n DEV 1 //1為間隔時間
Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
Average: lo 1926.94 1926.94 25573.92 25573.92 0.00 0.00 0.00 0.00
Average: A1-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: A1-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: NIC0 5.17 1.48 0.44 0.92 0.00 0.00 0.00 0.00
Average: NIC1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: A0-0 8173.06 92420.66 97102.22 133305.09 0.00 0.00 0.00 0.00
Average: A0-1 11431.37 9373.06 156950.45 494.40 0.00 0.00 0.00 0.00
Average: B3-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: B3-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
說明
“rxkB/s”為每秒接收的kB數。
“txkB/s”為每秒發(fa)送(song)的(de)kB數(shu)。
檢查(cha)完后，按“Ctrl+Z”鍵(jian)退出(chu)查(cha)看。
對(dui)于網絡(luo)過(guo)高的情況，建議對(dui)MQL語句進行分析，優化思路，降(jiang)低帶寬消耗，提(ti)升(sheng)規格擴大(da)網絡(luo)吞(tun)吐能力。
- 建議排查業務是否存在分片集合的情況消息中未攜帶ShardKey的情況，此場景下請求消息會進行廣播，增加帶寬消耗。
- 控制客戶端并發線程數，降低網絡帶寬流量。
- 以上操作無法解決問題時，請及時提升實例規格，高規格節點對應更高網絡吞吐能力的虛擬機。
