背景

Part1:寫在最前

我們在使用MongoDB sharding集群時，會使用如下命令來管理啟停Balancer：

>sh.stopBalancer() 停止Balancer>sh.startBalancer() 開啟Balancer

Part2:背景

開啟balancer后，客戶反饋前端應用寫入緩慢，查詢超時。因此我們嘗試關閉balancer，來避免chunk遷移對集群性能帶來的影響。

但是在調用sh.stopBalancer的時候，發(fā)現(xiàn)卻停不下來，sh.stopBalancer會處于卡住的狀態(tài)：

mongos>sh.stopBalancer()Waiting for active hosts...Waiting for the balancer lock...assert.soon failed,msg:Waited too long for lock balancer to unlockdoassert@src/mongo/shell/assert.js:18:14assert.soon@src/mongo/shell/assert.js:202:13sh.waitForDLock@src/mongo/shell/utils_sh.js:198:1sh.waitForBalancerOff@src/mongo/shell/utils_sh.js:264:9sh.waitForBalancer@src/mongo/shell/utils_sh.js:294:9sh.stopBalancer@src/mongo/shell/utils_sh.js:161:5@(shell):1:1Balancer still may be active, you must manually verify this is not the case using theconfig.changelog collection.2018-02-11T16:28:29.753+0800E QUERY [thread1] Error: Error:assert.soon failed, msg:Waited too long for lock balancer to unlock :sh.waitForBalancerOff@src/mongo/shell/utils_sh.js:268:15sh.waitForBalancer@src/mongo/shell/utils_sh.js:294:9sh.stopBalancer@src/mongo/shell/utils_sh.js:161:5@(shell):1:1

從上述報錯能夠看出，是由于目前balancer正在運行導致的，

Warning:警告 在3.4版本中，balancer運行在config server 的主節(jié)點上，在早期的版本中，balancer是運行在mongos上的。 當balancer進程處于活動狀態(tài)時，config server副本集的主服務器通過修改config數(shù)據(jù)庫的lock集合中的文檔，來獲取“平衡器鎖”。 這個“平衡器鎖”只能自己主動釋放。

Part3:排查方法

我們調用sh.status()命令能夠看到當前balancer已經關閉了，但是running還是yes，這說明有遷移正在運行。 

 balancer:Currently enabled: noCurrently running: yes

我們查看發(fā)現(xiàn)migrations集合下為空，說明沒有集合在遷移

mongos> db.migrations.find()

我們查看locks集合下的信息，處于2狀態(tài)的說明正持有鎖

mongos> db.locks.find(){ "_id" : "balancer", "state" : 2, "ts" : ObjectId("5a324c42329457086086da07"), "who" : "ConfigServer:Balancer", "process" : "ConfigServer", "when" : ISODate("2018-01-31T08:33:43.346Z"), "why" : "CSRS Balancer" }

Warning:警告

locks集合中的why列告訴我們持有鎖的原因，如果有正在遷移的文檔，其狀態(tài)應該是2,why中的原因會顯示Migrating chunk(s) in collection db.collationname.

從3.4版本起，balancer的狀態(tài)字段將始終為值2，以防止老版本的mongos實例執(zhí)行平衡操作。 when字段指config server 成員成為主節(jié)點的時間。

解決辦法

Part1:寫在最前

sh.stopBalancer停不下來，常見的可能原因有以下幾個：

• 正在做chunk遷移，必須等待chunk遷移完成后,才能夠正常停止；
• 后端的server時間不同步；
• mongo客戶端版本低于server端，本文就是第3種情況。mongo客戶端的版本是3.2版本，config server和mongod都是3.4版本的mongo。

Part2:解決辦法

替換老版本的mongo客戶端，使用3.4版本的客戶端

mongos> sh.stopBalancer(){ "ok" : 1 } config:PRIMARY> db.version()3.4.9-2.9

Part3:原因分析

卡住的原因是由于客戶端mongo是3.2版本，而config節(jié)點是3.4版本，3.2版本的mongos在執(zhí)行stopBalancer()時，stopBalancer代碼假定如果balancerStop命令沒有找到，那么它會使用舊版本的邏輯，等待鎖被釋放。從3.4版本起，Balance進程從mongos移動之configer server的primary節(jié)點上。

總結

通過這個案例，我們能夠了解到mongo客戶端版本帶來的問題，以及有哪些常見原因導致sh.stopBalancer停不下來。由于筆者的水平有限，編寫時間也很倉促，文中難免會出現(xiàn)一些錯誤或者不準確的地方，不妥之處懇請讀者批評指正。

好了，以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對VEVB武林網的支持。