mongodb 學習之oplog

背景：

   原來一個同事問我主從mongodb數據庫爲什麼數據差距很大,我讓他察看一下兩邊有啥不一樣，發現

主的local庫有13G從卻很小，進入local之後du發現有一個collection前綴的文件有13g，說明是local數據庫中一個集合太大了，推測是oplog太大了，oplog是類似於mysql的binlog oracle的archivelog

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

爲了進一步確認，進入mongodb之後通過

show dbs 

use local

show collections

看到現有的集合

然後

db.getReplicationInfo()

rs.printReplicationInfo()

瞭解一下複製信息以及oplog大小與使用情況

爲進一步確認相應的文件是否爲oplog

db.printCollectionStats()

根據展示出來的結果只需要知道兩條信息：

"ns" : "local.oplog.$main",

"uri" : "statistics:table:local/collection-2-1716662444632575459"

就可以確認oplog集合的相應文件，oplog如果太大可以清理和修改大小。

MongoDB oplog是一個capped collection，創建capped collection時，createCollection可以設置size（最大字節數）和max（最大文檔數）的參數，當這個集合的『總大小超過size』或者『總文檔數超過max』時，在新插入文檔時就會自動刪除一些集合內最先插入的文檔，相當於一片環形的存儲空間。

oplog（local.oplog.rs集合）默認情況下配置爲可用磁盤空間的5%，當oplog寫滿時，就會開始刪除最先寫入的oplog，一次正常的insert操作包含如下步驟：

1. 將文檔寫入指定的集合

2. 將寫入操作記錄到oplog

3. 如果oplog滿了，刪除最先寫入的oplog

優化策略

MongoDB 3.2爲了提升寫入性能，使用wiredtiger引擎時，針對local.oplog.rs這個集合的刪除策略進行了優化，主要改進：

1. 將刪除動作從用戶的寫入路徑移除，放到後臺線程執行

2. 批量刪除，並不是oplog一滿就立馬觸發刪除，而是一次刪除一批

實施方案

monogd啓動時，會根據oplog的最大字節數將整個集合分爲10-100個Stone（可以理解爲oplog的一段數據，包含多個文檔，Stone的具體個數oplogSizeMB的配置相關）。

WiredTigerRecordStore::OplogStones::OplogStones(OperationContext* txn, WiredTigerRecordStore* rs)
    : _rs(rs) {
    //...
    unsigned long long maxSize = rs->cappedMaxSize();

    const unsigned long long kMinStonesToKeep = 10ULL;
    const unsigned long long kMaxStonesToKeep = 100ULL;

    unsigned long long numStones = maxSize / BSONObjMaxInternalSize;
    _numStonesToKeep = std::min(kMaxStonesToKeep, std::max(kMinStonesToKeep, numStones));
    _minBytesPerStone = maxSize / _numStonesToKeep;
    // ...
}

其中_numStonesToKeep爲oplog應該保持的Stone個數，而_minBytesPerStone代表每個Stone的最小字節數。

接下來，會根據oplog當前的大小以及_minBytesPerStone來估算下，當前的oplog大致包含的Stone數量，並通過採樣的方式來獲取每個Stone的起始位置（不能保證每個Stone的大小跟預期完全一樣），然後將所有的Stone按順序存儲到一個隊列中。

mongod在服務寫請求的過程中，每次都會記錄下新產生oplog的大小，當新產生的oplog的總量超過_minBytesPerStones時，就會產生一個新的Stone加入到隊列中。

void WiredTigerRecordStore::OplogStones::createNewStoneIfNeeded(RecordId lastRecord) {

    if (_currentBytes.load() < _minBytesPerStone) {
        // Must have raced to create a new stone, someone else already triggered it.
        return;
    }

    // ...

    OplogStones::Stone stone = {_currentRecords.swap(0), _currentBytes.swap(0), lastRecord};
    _stones.push_back(stone);

    _pokeReclaimThreadIfNeeded(); // 喚醒後臺回收oplog空間的線程
}

當隊列中的Stone數量超過_numStonesToKeep，後臺線程就會刪除最老的Stone裏的數據，來回收oplog的存儲空間。

修改mongodb oplog size

oplog簡介：

oplog：operations log的簡寫，存儲在一個特殊的數據庫中（local），oplog就存儲在其中的oplog.$main集合裏面，這個集合是一個固定集合，新操作會自動替換舊的操作，以保證oplog不會超過預設的大小，其中的每個文檔都代表主節點上執行的一個操作，oplog會包含所有對數據有修改的的操作（查詢操作不會記錄），默認下，oplog大小會佔用64位的實例5%的可用磁盤空間。
mongo複製的過程：主節點應用業務操作修改到數據庫中，然後記錄這些操作到oplog中，從節點複製這些oplog，然後應用這些修改。ps：這些操作是異步的。如果從節點的操作已經被主節點落下很遠，oplog日誌在從節點還沒執行完，oplog可能已經輪滾一圈了，從節點跟不上同步，複製就會停下，從節點需要重新做完整的同步，爲了避免此種情況，儘量保證主節點的oplog足夠大，能夠存放相當長時間的操作記錄。

查詢oplog的大小及保存的操作記錄持續的時長

repltest:PRIMARY> db.printReplicationInfo()
configured oplog size:   1024MB
log length start to end: 3705secs (1.03hrs)
oplog first event time:  Thu Oct 10 2013 11:13:29 GMT+0800 (CST)
oplog last event time:   Thu Oct 10 2013 12:15:14 GMT+0800 (CST)
now:                     Fri Oct 11 2013 16:33:42 GMT+0800 (CST)

查詢從節點的數據源列表，其中有數據滯後的時間

repltest:PRIMARY> db.printSlaveReplicationInfo()
source:   192.168.1.101:37017
syncedTo: Fri Oct 11 2013 16:38:16 GMT+0800 (CST)
= 1 secs ago (0hrs)
source:   192.168.1.100:37017
no replication info, yet.  State: ARBITER
so,修改oplog的大小：（下面介紹兩種方式）

方式一:

The oplog exists internally as a capped collection, so you cannot modify its size in the course of normal operations.另：改變oplog大小，需要在每個節點上執行維護模式。（官方推薦）
步驟：

1:重啓一個實例以單機模式，

通常再關閉server之前，使用rs.stepDown() 強制primary成爲secondary

2:重新創建一個新大小，

其中包含舊的oplgo的入口條目的oplog

3:重啓mongod作爲replica set的成員

操作步驟：
1>: Restart a Secondary in Standalone Mode on a Different Port
關閉mongod實例：
repset:PRIMARY> use admin
repset:PRIMARY> db.shutdownServer()
重啓mongod實例以單機模式，修改端口，並不要加--replSet參數
＃vim /etc/mongo.conf
  dbpath=/var/lib/mongodb
  logpath=/var/log/mongodb/mongo.log
  pidfilepath=/var/run/mongo.pid
  directoryperdb=true
  logappend=true
  #replSet=repset
  bind_ip=192.168.1.100,127.0.0.1
  port=37017
  oplogSize=2000
  fork=true＃ mongod -f /etc/mongo.conf
備份oplog＃ mongodump --db local --collection 'oplog.rs' --port 37017
2>: Recreate the Oplog with a New Size and a Seed Entry
保存oplog的最新的時間點
> use local
> db.temp.save( db.oplog.rs.find( { }, { ts: 1, h: 1 } ).sort( {$natural : -1} ).limit(1).next() )
> db.temp.find()
刪除舊的oplog
> db.oplog.rs.drop()
3> :Create a New Oplog
創建一個新的Oplog，大小爲2G
> db.runCommand( { create: "oplog.rs", capped: true, size: (2 * 1024 * 1024 * 1024) } )
插入前面保存的舊的oplog的時間點的記錄
> db.oplog.rs.save( db.temp.findOne() )
> db.oplog.rs.find()
4>:Restart the Member：
關閉單機實例：
> use admin
> db.shutdownServer()
修改回配置＃ vim /etc/mongo.conf
  dbpath=/var/lib/mongodb
  logpath=/var/log/mongodb/mongo.log
  pidfilepath=/var/run/mongo.pid
  directoryperdb=true
  logappend=true
  replSet=repset
  bind_ip=192.168.1.100,127.0.0.1
  port=37017
  oplogSize=2000
  fork=true
啓動mongod
＃ mongod -f /etc/mongo.conf
重複上述步驟到所有需要更改的節點。

方式二：

步驟：
1:停掉所有replca set節點.
2:主節點刪除local庫下的文件，從節點刪除數據目錄下所有文件.
3:修改所有節點配置文件.
4:重啓所有節點.
5:重新配置replca set，從節點會重新同步所有數據（initial sync）.
ps：此法好處是簡單，但需要停掉服務，且如果數據量很大，初始同步的成本較高

1>:關閉mongod實例(所有節點)

> use admin
> db.shutdownServer()

2>:刪除local數據庫下的所有文件（PRIMARY節點）

# rm -rf /var/lib/mongodb/local/*
  刪除mongo數據目錄（其他節點上操作，可不要刪錯哦，建議所有rm操作先mv，待無問題時候再刪除）# rm -rf /var/lib/mongodb/*

3> 修改所有節點配置文件（oplogsize）

＃ vim /etc/mongo.conf
  dbpath=/var/lib/mongodb
  logpath=/var/log/mongodb/mongo.log
  pidfilepath=/var/run/mongo.pid
  directoryperdb=true
  logappend=true
  replSet=repset
  bind_ip=192.168.1.100,127.0.0.1
  port=37017
  oplogSize=2000
  fork=true

4> 重啓所有節點mongod

> mongod -f /etc/mongo.conf