mongodb：修改oplog.rs 的大小size

其內容字段說明：

• ts：操作日志的timestamp
• t： 未知？
• h：操作唯一隨機值
• v：oplog.rs的版本
• op：操作類型：
  • 　　i：insert操作
  • 　　u：update操作
  • 　　d：delete操作
  • 　　c：command操作
  • 　　n：null操作
• ns：名字空間：由 【db.collection】組成
• o：操作日志文檔內容
• o2：操作查詢條件，僅update有

 

----------------------------------------------------------------------------------------------------

那如何修改oplog.rs的大小呢？

　　（個人猜測）mongodb在replication模式下，啟動是會檢測local下的幾個相關collection，其中的oplog.rs就是本地的操作日志集合。

如果該集合存在，mongodb就不會考慮你的配置或命令選項中關於其大小的參數設置【replication.oplogSizeMB：n】的設置；否則，在第一次初始化replset時，根據該參數創建相關collection；而在其他人為配置有問題的情況下，報錯啟動失敗！

　　mongodb官方給出了不同版本下修改oplog.rs的方法，原則是：

1. 滾動處理，先secondary，再到primary
2. 處理primary時，先降級stepdown為secondary，讓系統自行選出新的primary后，再處理

 

　　本文，給出一個可能最便捷但可能不靠譜的方式，修改oplog.rs大小。其中的關鍵點：

• 新的oplog.rs的大小必須在990m~50G之間，默認系統選擇free-disk-space的5%作為默認值
• 新的oplog.rs自然是capped的
• 新的oplog.rs內必須添加一個文檔記錄： {ts: Timestamp(155555555,1), h: NumberLong("-35456346546456")}

　　關鍵之處就在此，【ts、h】字段是必須的，其值只有合乎語法規范即可，當然為了保證replset運行邏輯的正確性，就必須仔細考慮了。

1. 1. 　　如果是secondary的話，應該是隨便設置都可以的，只要比 replset.minvalid 小都可以
   2. 　　如果是primary的話（比如單節點replset），隨便設置，因為根本不會啟動同步源
   3. 　　如果是primary的話，后面跟着很多的secondary，理論上，必須還原修改大小之前的oplog.rs的內容，否則后果難以預料！這也是官方再三強調先降級為secondary角色再處理的原因！

 

操作命令：

use admin
rs.initiate({_id:"rset",members:[{_id:0,host:"127.0.0.1:27017"}]});
rs.initiate
(
    {
        "_id":"rset",   #必須的，replset的名字
        "members":[ #必須的
                       {
                            "_id":0,    #必須的
                            "host":"127.0.0.1:27017"    #必須的
                       }
                  ]
    }
);

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

use local ---- standalone
db.oplog.rs.renameCollection("oplog.rs.2")
db.createCollection("oplog.rs",{size:(3*1024*1024*1024),capped:1})
db.oplog.rs.insert({ts:Timestamp(1142268227, 1),h:NumberLong("-8215191208524156281")})

use test
for (i=1; i<=29999;i++) { db.tab.insert({c1:i});}
db.tab.count()