一 简介:来试试更改副本集的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已经改变