Mongodb 複製的紐帶–Oplog

可以說是Mongodb Replication的紐帶了。

• 作用：

當Primary進行寫操作的時候，會將這些寫操作記錄寫入Primary的中，而後Secondary會將複製到本機並應用這些操作，從而實現Replication的功能。
同時由於其記錄了Primary上的寫操作，故還能將其用作資料恢復。
可以簡單的將其視作Mysql中的binlog。

• 大小：

是一個capped collection。
在64位的Linux, Solaris, FreeBSD, and Windows 系統中，Mongodb預設將其大小設定為可用disk空間的5%（預設最小為1G，最大為50G），或也可以在mongodb複製集例項初始化之前將mongo.conf中oplogSize設定為我們需要的值。
但是由於其保證了複製的正常進行，以及資料的安全性和容災能力。
我們可以透過如下兩個圖(MMS)來了解他增加的情況：

上圖分別是每小時的增量，以及現有儲存了多少小時的操作。我們可以根據這個來監控並觀察oplog情況。我們需要足夠的oplog大小來保證資料的安全性。
也可以透過命令來檢視：

我們在生產環境中很可能會發現，可用disk的5%可能不夠用，那麼我們就需要進行的擴容了。

• ：
• 背景：一個由3個節點組成的複製集。
• 主節點：A 從節點：B,C
• 需求：Oplog擴容，儘量少的影響業務。
• 思路：先由從節點開始，一臺一臺的從複製集中剝離，修改，再回歸複製集，最後操作主節點來減少業務影響時間。
• 流程：
• 先將B節點關閉，去掉–replSet啟動引數,更換啟動埠–port,將節點以單機模式啟動。
• 然後備份其現有的oplog：

1. mongodump –db local –collection ‘oplog.rs’ –port 37017

• 進入mongo，將現在的oplog中最新的位置複製到tmp表（local資料庫）中：

1. use local
2. db.temp.save( db.oplog.rs.find( { }, { ts: 1, h: 1 } ).sort( {$natural : -1} ).limit(1).next() )

• 確認tmp中的資料：

1. db.temp.find()

• 刪除原有的oplog：

1. db.oplog.rs.drop()

• 建立新的oplog（capped），下例為2G大小，可根據需求修改：

1. db.runCommand( { create: “oplog.rs”, capped: true, size: (2 * 1024 * 1024 * 1024) } )

• 將tmp中的資料儲存到新的oplog中，並驗證：

1. db.oplog.rs.save( db.temp.findOne() )
2. db.oplog.rs.find()

• 關閉B節點，並恢復原有config配置，並在config中設定oplogSize為你之前設定的大小，並啟動。
• 繼續對C節點進行如上操作，C節點完成後最後對主節點A進行如上操，作即可完成。