一 简介:来试试更改副本集的oplog问题
二 背景: oplog的作用类似于mysql的binlog,传递增量操作到从节点

三 oplog介绍
   1 oplog在local库：
      1 master/slave 架构下
         local.oplog.$main;
      2 replica sets 架构下：
        local.oplog.rs
      3 sharding 架构下，
        mongos下不能查看oplog，可到每一片去看。
   2 oplog属性

capped collection 当写满后会进行覆盖写入

   3 oplog大小
    1 在默认情况下,oplog分配的是5%的空闲磁盘空间

四 问题: 当主库的操作量积累超过oplog时,就会覆盖oplog,这时候从节点无法获取之前的oplog就会发生全量传输,是不行的
五 常见场景:
       1 并发量非常高的DML操作,导致oplog被很快应用覆盖,从库无法追上
       2 新加入从节点全量同步的时间远远高于oplog被使用的时间,从库无法追上
六 常用命令:
       db.printReplicationInfo()查看oplog大小和使用情况
         oplog first event time: 最早切换时间
         oplog end event time: 最新时间
七 方法1:
    一 先更改从节点的oplog
        1 配置文件去掉shard相关参数 重启应用,以单机模式运行
        2 创建新的oplog应用
           # 存储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()
         #创建新的Oplog
        db.runCommand( { create: "oplog.rs", capped: true, size: (2 * 1024 * 1024 * 1024) } ) 这里2代为2G
        # 插入前面保存的旧的oplog的时间点的记录
       db.oplog.rs.save( db.temp.findOne() )
       db.oplog.find()
     3 将从节点从新加入主节点
  二 调整集群成员,将从变成主,主变成从
      1)PRIMARY> config=rs.conf()
      2)PRIMARY>config.members[3].priority = 3
      3)PRIMARY> rs.reconfig(config)
 三 继续调整从节点的oplog 
 四 调整完成

八 方法2

1 停止mongo进程并 删除所有数据目录

2 启动文件添加

oplogSize = N  单位M

3 启动进程进行全量同步

4 查看可发现oplog已经改变