MongoDB 升級3.4對均衡的影響

lyhabc

數(shù)據(jù)庫擴容要趁早再趁早
背景

公司有部門春節(jié)期間做活動, 產(chǎn)品中使用了 MonogDB 做彈幕消息的收發(fā)和一些元信息的存儲, 由于預計活動進行時會有流量上漲的情況, 需要對數(shù)據(jù)庫進行擴容

在擴容前, 數(shù)據(jù)庫有4個分片, 每個分片有幾百 G 數(shù)據(jù), 每個分片大概有5000個數(shù)據(jù)塊, 總共有2w 個數(shù)據(jù)塊

擴容為4分片擴8分片, 活動上線時間在兩天后

當時使用的 MongoDB 版本為3.0

問題

在3.0的版本下, 數(shù)據(jù)塊的遷移是全局串行的, 即同一時刻只能有一個數(shù)據(jù)塊在遷移, 在線上開啟了遷移, 進行了速度測試, 平均每個數(shù)據(jù)塊的遷移時間為5分鐘左右, 4分片擴8分片需要移動大約1w 個分片, 耗費的時間為10000 * 5 = 1個月

分析

MongoDB 在3.2以及之前的版本對數(shù)據(jù)的自動均衡做了全局串行處理, 在片數(shù)較多時不能發(fā)揮均衡的完整作用

為在指定時間內(nèi)完成數(shù)據(jù)庫擴容, 需要升級到增加了并行均衡的3.4版本

升級過程

按照官網(wǎng)要求, 3.0到3.4的升級不能直接進行, 需要先升級到3.2, 再升級到3.4

升級順序為 mongod, config, mongos, 需要注意的有兩點:
1. config 升級為復制集的過程較為繁瑣, 參考config 升級復制集文檔
2. 新版本 mongos 可能不能正確連接舊版本 mongod, 所以升級過程中, mongos 應該最后升級

效果

升級完成后, 首先看了一下單個數(shù)據(jù)塊的遷移速度, 速度提升非常明顯, 單個數(shù)據(jù)塊的遷移時間從5分鐘縮短到30s 左右, 有10倍的提升

再考慮到分片之間的并行遷移, 實際均衡時間由1個月降低到10000 * 0.5 / 4 = 18小時

在升級完成的一天內(nèi), 雖然遇到了一點別的問題, 數(shù)據(jù)庫依舊完成了擴容

監(jiān)控

mongodb 提供的 ops manager 監(jiān)控, 比較方便可以搭建起來
在均衡過程中, 請求耗時增長可以接受
bd1fa2051919ba358243591f0

升級后的問題

有幾個小問題

在遷移過程中, 出現(xiàn)了遇到 jumbo chunk 之后剩余的 chunk 不再繼續(xù)遷移的問題, 具體表現(xiàn)是: set1中存在較多的 jumbo chunk( 較大的數(shù)據(jù)塊), balancer 不斷嘗試遷移, 但是總是在連續(xù)兩個 jumbo chunk 之間嘗試, 在日志中不停打印類似的日志:
2017-01-20T11:38:21.030+0800 W SHARDING [conn4192015] possible low cardinality key detected in * - key is { uk: 247332434 }
2017-01-20T11:38:43.070+0800 W SHARDING [conn4192015] possible low cardinality key detected in * - key is { uk: 247332439 }
2017-01-20T11:39:07.806+0800 W SHARDING [conn4192015] possible low cardinality key detected in * - key is { uk: 247332434 }
線下復現(xiàn)未能成功, 線上一直存在問題

后使用腳本運行 movechunk 命令完成均衡

ops manager 的 ip 識別問題, 在進行監(jiān)控時, ops manager 會將 ip 轉(zhuǎn)化為域名進行記錄處理, 但是存在的問題是, ip 與域名的映射并不總是完全準確的, 在映射錯誤的機器上使用 host 命令可以得到正確的結(jié)果, 導致的問題是, ops manager 對于映射錯誤的機器不能得到最新的數(shù)據(jù)
總體來說, 升級3.4版本對于均衡的收益是數(shù)量級的差異, 帶來的效果十分明顯, 對于均衡有需求的場景推薦升級