免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 1464 | 回复: 0

[MongoDB] MongoDB复制集自适应oplog管理 [复制链接]

求职 : Linux运维
论坛徽章:
203
拜羊年徽章
日期:2015-03-03 16:15:432015年辞旧岁徽章
日期:2015-03-03 16:54:152015年迎新春徽章
日期:2015-03-04 09:57:092015小元宵徽章
日期:2015-03-06 15:58:182015年亚洲杯之约旦
日期:2015-04-05 20:08:292015年亚洲杯之澳大利亚
日期:2015-04-09 09:25:552015年亚洲杯之约旦
日期:2015-04-10 17:34:102015年亚洲杯之巴勒斯坦
日期:2015-04-10 17:35:342015年亚洲杯之日本
日期:2015-04-16 16:28:552015年亚洲杯纪念徽章
日期:2015-04-27 23:29:17操作系统版块每日发帖之星
日期:2015-06-06 22:20:00操作系统版块每日发帖之星
日期:2015-06-09 22:20:00
发表于 2016-06-14 10:21 |显示全部楼层
MongoDB复制集运行过程中,经常可能出现Secondary同步跟不上的情况,主要原因是主备写入速度上有差异,而复制集配置的oplog又太小,这时需要人工介入,向Secondary节点发送resync命令。

上述问题可通过配置更大的oplog来规避,目前官方文档建议的修改方案步骤比较长,而且需要停写服务来做,大致过程是先把oplog备份,然后再oplog集合删掉,重新创建,再把备份的内容导入到新创建的oplog。

我们团队针对使用wiredtiger存储引擎的场景,开发了通过collMod命令在线修改oplog大小的功能,已向官方提交了pull request,大家应该能在下一个大版本3.4里享受到这个功能。



即使有了在线修改oplog的功能,从运维角度看,还是需要人去感知到『复制集需要更大oplog』这个需求,然后去进行调整;但实际上复制集的每个成员都是了解所有节点当前的复制状况的(rs.status()的输出,可以看到每个节点最新的optime),Primary只要根据这个信息自适应的保留oplog即可,保证同步最慢的节点也能跟上。

333333.jpg

为了实现上述功能,我们改造了oplog删除的策略,支持『在oplog删除时,只能删除某个特定时间戳之前的oplog』,每个成员不断的根据复制集最慢节点的optime来更新时间戳,这样就能保证同步最慢的节点需要的oplog一定存在,避免了同步跟不上的场景。功能稳定后,我们会将patch提到JIRA上,让社区用户也能用上这个特性,免去管理oplog的烦恼。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP