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的方法，原则是：

滚动处理，先secondary，再到primary
处理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. 　　如果是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()