摘要：正常同步和副本集，在正常工作的情況下，是以一種不斷的異步的方式進(jìn)行同步。是一個(gè)特殊的固定大小的，固定大小意味著，新的操作記錄的寫(xiě)入會(huì)導(dǎo)致最老的操作記錄的刪除，以保證的大小。而且已經(jīng)降級(jí)為，將無(wú)法接受請(qǐng)求，以及不能變成。

Devops一般很少時(shí)間會(huì)花在數(shù)據(jù)庫(kù)的部署上，只有到了不得不去考慮的情況下，才會(huì)去考慮如何調(diào)整數(shù)據(jù)庫(kù)，以適應(yīng)業(yè)務(wù)的發(fā)展。mongodb本身就很適合Devops，大部分情況下，部署基本按照說(shuō)明操作一下即可。但實(shí)際操作起來(lái)，其實(shí)還有會(huì)有一些坑，比如Resync。

mongo副本集，在正常工作的情況下，是以一種不斷的、異步的方式進(jìn)行同步。每個(gè)副本都會(huì)不斷的記錄自己進(jìn)行的操作進(jìn)入到oplog表里；Secondary副本就會(huì)不斷的從Primary副本那里同步最新的操作，從而完成整個(gè)副本集的同步。當(dāng)然Secondary的副本也可以選擇從其他的Secondary副本同步，因?yàn)槊總€(gè)副本都會(huì)記錄oplog。詳細(xì)的描述可以參考官方文檔Replica Set Data Synchronization。

Oplog是一個(gè)特殊的固定大小的collection，固定大小意味著，新的操作記錄的寫(xiě)入會(huì)導(dǎo)致最老的操作記錄的刪除，以保證oplog的大小。這個(gè)值如果不去設(shè)置，mongo會(huì)自動(dòng)根據(jù)硬盤(pán)大小的5%來(lái)設(shè)定。大部分情況下沒(méi)有什么問(wèn)題，但有一個(gè)非常重要的設(shè)(da)定(keng)：

oplog一旦大小固定，那么只能通過(guò)重啟+配置來(lái)進(jìn)行修改

為什么這會(huì)是一個(gè)坑，后面會(huì)繼續(xù)討論。

副本集之間一般通過(guò)網(wǎng)絡(luò)連接，副本集之間的性能也有可能有差異（當(dāng)然最好不要有），所以同步操作有可能出現(xiàn)毫秒級(jí)別的延遲，甚至到1s以上，這個(gè)可以通過(guò)在任意一個(gè)副本集上執(zhí)行

rs.status()

來(lái)查看所有副本集的同步狀態(tài)。這個(gè)打印出的各個(gè)副本的optime，就是這個(gè)副本最后一條操作執(zhí)行的時(shí)間，Secondary和Primary之間optime的時(shí)間差，其實(shí)就是同步延遲。

同步延遲一般情況下，頂多也就一兩秒，但是一些異常情況，例如宕機(jī)、長(zhǎng)時(shí)間過(guò)載overload，可能會(huì)導(dǎo)致這個(gè)時(shí)間越來(lái)越長(zhǎng)。這里，我們的oplog的巨大作用就顯現(xiàn)出來(lái)了！

Secondary和Primary之間的同步差，最大不能超過(guò)Primary的oplog能存儲(chǔ)的條數(shù)

注意！因?yàn)镾econdary是從Primary同步oplog，所以，這里只與Primary的oplog大小有關(guān)，與Secondary自身記錄的oplog無(wú)關(guān)！當(dāng)然，如果Secondary是從其他的Secondary同步數(shù)據(jù)，那么至于同步目標(biāo)的oplog有關(guān)。

為了幫助用戶(hù)直觀(guān)的理解oplog里面存儲(chǔ)了多少條操作，mongo還額外提供了兩個(gè)數(shù)據(jù)：

tFirst 第一條oplog的時(shí)間

tLast 最后一條oplog的時(shí)間

這兩個(gè)數(shù)據(jù)，可以通過(guò)在primary上執(zhí)行：

db.getReplicationInfo()

獲得。tLast - tFirst就是mongo同步機(jī)制所允許你進(jìn)行停機(jī)同步數(shù)據(jù)的最大時(shí)間，當(dāng)然這個(gè)時(shí)間不是固定的，如果當(dāng)前的負(fù)載很低，相當(dāng)于相同的oplog表可以存更長(zhǎng)時(shí)間內(nèi)的操作數(shù)據(jù)，就會(huì)給你留更多的停機(jī)操作時(shí)間。

上圖中，Secondary落后于Primary，也就是說(shuō)，同步延遲有10分鐘(兩個(gè)optime相減)，但此時(shí)，Primary上存有最近20分鐘的oplog，那么Secondary通過(guò)獲取這些oplog，仍然能夠在短時(shí)間內(nèi)趕上Primary的進(jìn)度。

但是，一旦optime的差距超出了Primary的tFirst，情況就不妙了，如下圖：

此時(shí)，自動(dòng)的同步已經(jīng)無(wú)法完成同步了(stale)，必須執(zhí)行手動(dòng)操作Resync。而且Secondary已經(jīng)降級(jí)為Recovering，將無(wú)法接受請(qǐng)求，以及不能變成master。

Resync機(jī)制官網(wǎng)有詳細(xì)的介紹，基本思路就是把數(shù)據(jù)拷貝過(guò)來(lái)，再進(jìn)行上面的oplog的同步。例如：

使用磁盤(pán)快照，把快照的數(shù)據(jù)庫(kù)文件直接覆蓋到Secondary上，重啟Secondary

使用Initial Sync，把Secondary的數(shù)據(jù)清空，讓mongo自動(dòng)從0開(kāi)始，重新同步所有數(shù)據(jù)

磁盤(pán)快照看起來(lái)很美好，但是是mongo的數(shù)據(jù)存儲(chǔ)是分配后就不返回的，也就是說(shuō)實(shí)際占用的磁盤(pán)空間要比真實(shí)數(shù)據(jù)的大小要大，使用操作系統(tǒng)的scp也好rsync也好，這些無(wú)用的空間也會(huì)被復(fù)制，耽誤復(fù)制的時(shí)間。除此之外，建立快照本身也需要耗時(shí)，反正在阿里云上建快照并不快，200G的數(shù)據(jù)大約要1小時(shí)多。

而Initial Sync是mongo之間拷貝表數(shù)據(jù)，拷貝完了就地重建索引，所以相當(dāng)于只傳輸了真實(shí)的表數(shù)據(jù)，連索引數(shù)據(jù)都不用傳輸，從整體的復(fù)制時(shí)間來(lái)看更加節(jié)省，但是會(huì)對(duì)拷貝對(duì)象Primary有一些性能影響，但畢竟只是讀，而且不需要Primary停機(jī)。

無(wú)論使用上面的哪種Resync機(jī)制，思路都是一致的，通過(guò)某種快速的方式同步更多的數(shù)據(jù)，然后剩下的使用oplog彌補(bǔ)在執(zhí)行操作時(shí)的新操作?？雌饋?lái)很美好，而實(shí)際的執(zhí)行過(guò)程中，如果操作的時(shí)間，要大于oplog所記錄的時(shí)間，怎么辦？將永遠(yuǎn)無(wú)法不停機(jī)Resync成功！

這里Initial Sync為什么也不能成功呢？其實(shí)在Initial Sync的日志中，就可以看出來(lái)，在STATUP2的狀態(tài)，就是一張表一張表的拷數(shù)據(jù)，也就是說(shuō)，就算拷貝過(guò)程中的數(shù)據(jù)已經(jīng)同步過(guò)去了，當(dāng)拷貝下一張表時(shí)，上一張表的數(shù)據(jù)其實(shí)已經(jīng)過(guò)期了。而當(dāng)數(shù)據(jù)量很大的情況下（其實(shí)不需要太大，幾百G），整個(gè)拷貝過(guò)程也要持續(xù)數(shù)小時(shí)，此時(shí)如果oplog的記錄時(shí)間低于STARTUP2所需要花費(fèi)的時(shí)間，恭喜你，你中獎(jiǎng)了。

當(dāng)然，如果你能有一臺(tái)正常同步數(shù)據(jù)的Secondary，新的機(jī)器指向這臺(tái)也是可以的，但是你的架構(gòu)是一臺(tái)Arbiter一臺(tái)Primary一臺(tái)Secondary的話(huà)……就沒(méi)辦法了，只能指望Primary了。別問(wèn)我為什么知道，我就是知道。（╯‵□′）╯︵┴─┴

遇到這種情況怎么辦？

半夜Primary停機(jī)，同步數(shù)據(jù)。這對(duì)于DBA也都不奇怪，只是在用了mongo集群后沒(méi)享受到mongo的便利。當(dāng)然，到了半夜負(fù)載下降，相當(dāng)于oplog允許的操作時(shí)間變長(zhǎng)了，也許不用停機(jī)。

如果有很多冗余數(shù)據(jù)、日志數(shù)據(jù)什么的，可以刪除，從而降低Initial Sync花費(fèi)的時(shí)間，那也是很值得嘗試的！

上面的坑，其實(shí)主要是在于oplog的值相對(duì)于數(shù)據(jù)量過(guò)小的時(shí)候會(huì)出現(xiàn)。一般默認(rèn)情況下，oplog取磁盤(pán)大小的5%似乎沒(méi)太大問(wèn)題?？釉谀哪?？

磁盤(pán)擴(kuò)容

高負(fù)載

一開(kāi)始我就提到，oplog的存儲(chǔ)大小一旦確定是不會(huì)改的，也就是說(shuō)，一旦隨著業(yè)務(wù)的發(fā)展，進(jìn)行了磁盤(pán)擴(kuò)容，或者移動(dòng)到了一塊更大的硬盤(pán)上，oplog的大小不會(huì)隨之改變！

一旦兩件巧合的事情遇到了一起：磁盤(pán)曾經(jīng)擴(kuò)容且沒(méi)有額外考慮oplog；需要新增副本或者副本stale了；此時(shí)正常的機(jī)器只有一臺(tái)Primary；就會(huì)變成一件解決起來(lái)不那么輕松的事情了。

而高負(fù)載也是潛在的另外一個(gè)可能，由于負(fù)載過(guò)高，雖然oplog存儲(chǔ)很大，但是實(shí)際上oplog所支持的停機(jī)操作時(shí)間變少了，此時(shí)也會(huì)遇到相同的情況。

總結(jié)一下，在用mongo副本集群的時(shí)候，隨著數(shù)據(jù)的增長(zhǎng)、磁盤(pán)的擴(kuò)容，一方面在考慮sharding的同時(shí)，一定要注意當(dāng)前的oplog存儲(chǔ)是否夠用，提前為下一次部署策略更換準(zhǔn)備好，給下一次的操作留夠時(shí)間。特別是Devops，平時(shí)沒(méi)時(shí)間管的，一定要未雨綢繆呀。