背景

Part1:寫在最前

我們?cè)谑褂肕ongoDB sharding集群時(shí)，會(huì)使用如下命令來管理啟停Balancer：

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

Part2:背景

開啟balancer后，客戶反饋前端應(yīng)用寫入緩慢，查詢超時(shí)。因此我們嘗試關(guān)閉balancer，來避免chunk遷移對(duì)集群性能帶來的影響。

但是在調(diào)用sh.stopBalancer的時(shí)候，發(fā)現(xiàn)卻停不下來，sh.stopBalancer會(huì)處于卡住的狀態(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 unlock
doassert@src/mongo/shell/assert.js:18:14
assert.soon@src/mongo/shell/assert.js:202:13
sh.waitForDLock@src/mongo/shell/utils_sh.js:198:1
sh.waitForBalancerOff@src/mongo/shell/utils_sh.js:264:9
sh.waitForBalancer@src/mongo/shell/utils_sh.js:294:9
sh.stopBalancer@src/mongo/shell/utils_sh.js:161:5
@(shell):1:1
Balancer still may be active, you must manually verify this is not the case using the
config.changelog collection.
2018-02-11T16:28:29.753+0800
E 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:15
sh.waitForBalancer@src/mongo/shell/utils_sh.js:294:9
sh.stopBalancer@src/mongo/shell/utils_sh.js:161:5
@(shell):1:1

從上述報(bào)錯(cuò)能夠看出，是由于目前balancer正在運(yùn)行導(dǎo)致的，

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

Part3:排查方法

我們調(diào)用sh.status()命令能夠看到當(dāng)前balancer已經(jīng)關(guān)閉了，但是running還是yes，這說明有遷移正在運(yùn)行。 

 balancer:
Currently enabled: no
Currently 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)應(yīng)該是2,why中的原因會(huì)顯示Migrating chunk(s) in collection db.collationname.

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

解決辦法

Part1:寫在最前

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

• 正在做chunk遷移，必須等待chunk遷移完成后,才能夠正常停止；
• 后端的server時(shí)間不同步；
• 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é)點(diǎn)是3.4版本，3.2版本的mongos在執(zhí)行stopBalancer()時(shí)，stopBalancer代碼假定如果balancerStop命令沒有找到，那么它會(huì)使用舊版本的邏輯，等待鎖被釋放。從3.4版本起，Balance進(jìn)程從mongos移動(dòng)之configer server的primary節(jié)點(diǎn)上。

總結(jié)

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

好了，以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問大家可以留言交流，謝謝大家對(duì)腳本之家的支持。

最新評(píng)論