mongodb導(dǎo)入數(shù)據(jù)導(dǎo)致的復(fù)制集解體怎么辦

這篇文章主要介紹mongodb導(dǎo)入數(shù)據(jù)導(dǎo)致的復(fù)制集解體怎么辦，文中介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們一定要看完！

最近公司的MONGO DB 已經(jīng)上線了，存儲大量應(yīng)用操作中的日志，或者一些傳統(tǒng)數(shù)據(jù)庫不能，不方便存儲的數(shù)據(jù)。 作為NO SQL 中的NO.1 MONGO DB 在穩(wěn)定性和數(shù)據(jù)巨形吞吐是有目共睹的。 在測試庫經(jīng)歷了 幾次斷電，MONGO 進程啟動后，集群還是馬上能開始工作，這已經(jīng)說明在健壯性方面，MONGODB 集群比其他的傳統(tǒng)數(shù)據(jù)庫要 “牛的多”，當(dāng)然從原理上講也是應(yīng)該的，非事務(wù)話的操作，不尋求數(shù)據(jù)某一個時間段的唯一性。 另外MONGODB  存儲日志，對比Elasticsearch 也是各有優(yōu)勢，MONGO DB 在于他對日志操作的連續(xù)性，以及關(guān)聯(lián)性，這點是Elasticsearch 所不能給的，所以重要的系統(tǒng)的日志，部分企業(yè)還是使用MONGO DB 而不是 Elasticsearch。

話歸正傳，最近比較忙，MONGO 上線，雖然性能分析器OPS已經(jīng)上線了，但監(jiān)控運維還是在搞的狀態(tài)，并且手上還有 MYSQL MGR 系統(tǒng)的搭建，今天來了一個需求，要從傳統(tǒng)的數(shù)據(jù)庫中導(dǎo)入不到20G 的數(shù)據(jù)，這本來對MONGO DB 來說塞牙縫都不夠，在測試庫上，（配置不高），導(dǎo)出數(shù)據(jù)也就花了10分鐘左右，在導(dǎo)入到生產(chǎn)數(shù)據(jù)庫時，由于腦子放到了MYSQL MGR 上面，忘記了MONGO DB 這邊的OPLOG 設(shè)置僅僅20G，并且我還先導(dǎo)入了生產(chǎn)非正式表，讓開發(fā)先驗證了數(shù)據(jù)的準(zhǔn)確性，導(dǎo)入的速度非?？觳坏?0分鐘，20G 不到的數(shù)據(jù)就妥妥的存入了MONGO DB。

我忽略的就是OPLOG 設(shè)置大小與已經(jīng)快速導(dǎo)入了20G的數(shù)據(jù)到MONGO DB，雖然我已經(jīng)有所警覺，再次導(dǎo)入數(shù)據(jù)的時候，已經(jīng)限速了，想著不會出什么事情，看了一眼oplog windows ，7 DAYS ，還長著呢。

導(dǎo)入的速度由于限速了，速度很慢，我偶爾看一眼 OPLOG WINDOWS ，后來降到 3 DAYS ，在后面降到 1 DAYS ，我開始注意到，OPLOG 窗口越來越小。

這里普及一個知識，什么是OPLOG，當(dāng)Primary進行寫操作的時候，會將這些寫操作記錄寫入Primary的Oplog 中，而后Secondary會將Oplog 復(fù)制到本機并應(yīng)用這些操作，從而實現(xiàn)Replication的功能。同時由于其記錄了Primary上的寫操作，故還能將其用作數(shù)據(jù)恢復(fù)?？梢院唵蔚膶⑵湟曌鱉ysql中的binlog，但部分原理不一樣。

如果這放到了MONGO DB 3.4 估計只有等死的份了，但選型的時我們選擇了MONGO DB 3.6， 可以在線擴充 OPLOG 的容量，這點在這個時刻是可以救命的。

馬上擴充OPLOG ，直接將原來的20G 改為 45G 在所有的節(jié)點上操作

這時OPLOG WINDOWS 給我的時間已經(jīng)不足40分鐘了。

隨著調(diào)節(jié)OPLOG WINDOWS 后，OPLOG 的時間窗口在一點點的提升，情況好轉(zhuǎn)了，警報解除了。

繼續(xù)通過命令來觀察

每刷新一次，OPLOG  first event time  和  last event time 之間的距離越來越遠。至此一場危機度過。 咻

經(jīng)過查詢，其實張友東，早在MONGO 3.2 就提出過即時修改的方案給官方，但3.6才被應(yīng)用。

以上是“mongodb導(dǎo)入數(shù)據(jù)導(dǎo)致的復(fù)制集解體怎么辦”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道！