MongoDB 4.4 Oplog終於改爲MySQL Binlog機制

Oplog注意事項  蓋子集合(Capped Collections)，4.4版本以前的工做機制相似MySQL的Redo log，循環覆蓋寫。

工做原理：

1)存1-N增刪改記錄，寫滿了自動覆蓋最舊的文檔，循環寫，相似Redo log。

2)Secondary在本地找到Oplog同步複製的點爲27，發送請求告知Primary從序號28開始同步數據

3)Primary在本地搜索到28後，發送以後的數據給Secondary，若是未搜索到，返回請求沒有此記錄。
4)獲得Primary沒有該記錄後，Secondary會執行initial sync初始化同步，先刪除本地全部數據，拷貝Primary全量數據和在這之間有變動的增量數據。

場景：

假如你的一臺Secondary掛了，Oplog又設置的太小，而且數據增加量又很快，Oplog此時被覆蓋重寫，那麼只能進行initial sync全量同步。雖然在3.6版本里能夠動態調整Oplog大小，但你沒法準確估算Oplog啥時被覆蓋重寫。

在4.4版本里，Oplog能夠像binlog同樣，你能夠根據本身的維護狀況，自定義保存多久時間。

新的參數--oplogMinRetentionHours，單位小時。--oplogMinRetentionHours=24，表明保留24小時的oplog。

也能夠動態修改，命令以下：

db.adminCommand({ "replSetResizeOplog" : 1,   "minRetentionHours" : 24 })

查看：

db.getSiblingDB("admin").serverStatus().oplogTruncation.oplogMinRetentionHours

參考文獻：

https://docs.mongodb.com/manual/reference/command/replSetResizeOplog/#dbcmd.replSetResizeOplog