MongoDB中 oplog的作用是什么

本篇文章為大家展示了MongoDB中 oplog的作用是什么，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

1：oplog簡介

oplog是local庫下的一個固定集合，Secondary就是通過查看Primary 的oplog這個集合來進行復制的。每個節點都有oplog，記錄這從主節點復制過來的信息，這樣每個成員都可以作為同步源給其他節點。

 Oplog 可以說是Mongodb Replication的紐帶了。

2：副本集數據同步的過程

副本集中數據同步的詳細過程：Primary節點寫入數據，Secondary通過讀取Primary的oplog得到復制信息，開始復制數據并且將復制信息寫入到自己的oplog。如果某個操作失敗（只有當同步源的數據損壞或者數據與主節點不一致時才可能發生），則備份節點停止從當前數據源復制數據。如果某個備份節點由于某些原因掛掉了，當重新啟動后，就會自動從oplog的最后一個操作開始同步，同步完成后，將信息寫入自己的oplog，由于復制操作是先復制數據，復制完成后再寫入oplog，有可能相同的操作會同步兩份，不過MongoDB在設計之初就考慮到這個問題，將oplog的同一個操作執行多次，與執行一次的效果是一樣的。

• 作用：

　　當Primary進行寫操作的時候，會將這些寫操作記錄寫入Primary的Oplog 中，而后Secondary會將Oplog 復制到本機并應用這些操作，從而實現Replication的功能。
　　同時由于其記錄了Primary上的寫操作，故還能將其用作數據恢復。
　　可以簡單的將其視作Mysql中的binlog。

3：oplog的增長速度

oplog是固定大小，他只能保存特定數量的操作日志，通常oplog使用空間的增長速度跟系統處理寫請求的速度相當，如果主節點上每分鐘處理1KB的寫入數據，那么oplog每分鐘大約也寫入1KB數據。如果單次操作影響到了多個文檔（比如刪除了多個文檔或者更新了多個文檔）則oplog可能就會有多條操作日志。db.testcoll.remove() 刪除了1000000個文檔，那么oplog中就會有1000000條操作日志。如果存在大批量的操作，oplog有可能很快就會被寫滿了。

• 大小：

　　Oplog 是一個capped collection。
　　在64位的Linux, Solaris, FreeBSD, and Windows 系統中，Mongodb默認將其大小設置為可用disk空間的5%（默認最小為1G，最大為50G），或也可以在mongodb復制集實例初始化之前將mongo.conf中oplogSize設置為我們需要的值。

　　local.oplog.rs 一個capped collection集合.可在命令行下使用--oplogSize 選項設置該集合大小尺寸.
　　但是由于Oplog 其保證了復制的正常進行，以及數據的安全性和容災能力。

4：oplog注意事項：

local.oplog.rs特殊的集合。用來記錄Primary節點的操作。

oplog的大小

capped collection是MongoDB中一種提供高性能插入、讀取和刪除操作的固定大小集合，當集合被填滿的時候，新的插入的文檔會覆蓋老的文檔。

所以，oplog表使用capped collection是合理的，因為不可能無限制的增長oplog。MongoDB在初始化副本集的時候都會有一個默認的oplog大小：

• 在64位的Linux,Solaris,FreeBSD以及Windows系統上，MongoDB會分配磁盤剩余空間的5%作為oplog的大小，如果這部分小于1GB則分配1GB的空間

• 在64的OS X系統上會分配183MB

• 在32位的系統上則只分配48MB

oplog的大小設置是值得考慮的一個問題，如果oplog size過大，會浪費存儲空間；如果oplog size過小，老的oplog記錄很快就會被覆蓋，那么宕機的節點就很容易出現無法同步數據的現象。

比如，基于上面的例子，我們停掉一個備份節點（port=33333），然后通過主節點插入以下記錄，然后查看oplog，發現以前的oplog已經被覆蓋了。

通過MongoDB shell連接上這個節點，會發現這個節點一直處于RECOVERING狀態。

解決方法：

數據同步

在副本集中，有兩種數據同步方式：

• initial sync（初始化）：這個過程發生在當副本集中創建一個新的數據庫或其中某個節點剛從宕機中恢復，或者向副本集中添加新的成員的時候，默認的，副本集中的節點會從離它最近的節點復制oplog來同步數據，這個最近的節點可以是primary也可以是擁有最新oplog副本的secondary節點。

• 該操作一般會重新初始化備份節點，開銷較大

• replication（復制）：在初始化后這個操作會一直持續的進行著,以保持各個secondary節點之間的數據同步。

initial sync

當遇到上面例子中無法同步的問題時，只能使用以下兩種方式進行initial sync了

• 第一種方式就是停止該節點，然后刪除目錄中的文件，重新啟動該節點。這樣，這個節點就會執行initial sync

• 注意：通過這種方式，sync的時間是根據數據量大小的，如果數據量過大，sync時間就會很長

• 同時會有很多網絡傳輸，可能會影響其他節點的工作

• 第二種方式，停止該節點，然后刪除目錄中的文件，找一個比較新的節點，然后把該節點目錄中的文件拷貝到要sync的節點目錄中

通過上面兩種方式中的一種，都可以重新恢復"port=33333"的節點。改變一直處于RECOVERING狀態的錯誤。

查看oplog的信息

通過"db.printReplicationInfo()"命令可以查看oplog的信息

字段說明：

• configured oplog size： oplog文件大小

• log length start to end: oplog日志的啟用時間段

• oplog first event time: 第一個事務日志的產生時間

• oplog last event time: 最后一個事務日志的產生時間

• now: 現在的時間

<h4 id="_nav_7" background-position:left top;background-size:initial;background-repeat:no-repeat;background-attachment:initial;background-origin:initial;background-clip:initial;height:auto;line-height:1.8;padding-left:20px;color:#666666;margin:10px 0px;font-family:verdana, Arial, Helvetica, sans-serif;white-space:normal;"> 查看slave狀態

通過"db.printSlaveReplicationInfo()"可以查看slave的同步狀態

副本節點中執行db.printSlaveReplicationInfo()命令可以查看同步狀態信息

• source——從庫的IP及端口

• syncedTo——當前的同步情況，延遲了多久等信息

上述內容就是MongoDB中 oplog的作用是什么，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。