时间:2021-05-23
背景
随着数据的积累,MongoDB中的数据量越来越大,数据分析团队从数据库中抽取变化数据(假如依据栏位createdatetime,transdatetime),越来越困难。我们知道MongoDB的副本集有一个数据结构Oplog,里面存储了Primary节点的所有写操作(此处的写操作是指查询以外的操作,包含 更新、异常等)。其实,数据的抽取完全可以从Oplog中抓取这些操作,然后去重放。
oplog是local库下的一个固定集合,Secondary就是通过查看Primary 的oplog这个集合来进行复制的。每个节点都有oplog,记录这从主节点复制过来的信息,这样每个成员都可以作为同步源给其他节点。
Oplog 可以说是Mongodb Replication的纽带了。
但是在实际的生产环境中,我们很多MongoDB 数据库是单实例的,那么我们能否在单实例数据库上开启Oplog?
答案是肯定的。
其原理就是,在单实例上配置副本集,如果配置成功了,自然就有了Oplog。
配置过程
其实配置的过程比较简单。
step 1 : 在配置文件中 添加副本集参数(replSet);
step 2 :重启服务;
step 3:在local数据库或admin数据库执行初始化副本集的脚本,rs.initiate()。
注意事项
1. 在配置文件中增加副本集参数(replSet=??),MongoDB实例重启,第一次登入,执行其他命令时(例如:show dbs),会提示错误,错误信息如下,
此时一定要执行初始化的命令:
2 . 初始化时,请指明 Server信息和端口信息,否则初始化时可能报错,报错信息如下
"errmsg" : "No host described in new configuration 1 for replica set replwms maps to this node",
指定IP 和 端口,副本集名称,例如执行以下命令,OK
3 . 副本集初始化可以在admin中执行,不仅仅可以在local数据库中执行【真正的副本集建立多是在admin库中执行】。
而不像有些文章中要求的那样 :You just need to issuers.initiate()on thelocaldatabase:
4. 初始完,副本集中唯一的节点,可能短时间显示为SECONDARY或OTHER。一般而言,稍等一会,就会自然恢复为primary,无需人工干预。
或
如果数据库的数据量不大,并且长时间初始这种过渡状态(SECONDARY或OTHER),去看实例的日志,也显示无进展,此时可以考虑重启服务。
下面案例是我们实际遇到的一个场景,我们是通过重启服务解决此问题,角色由other重启转换为Primary
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,如果有疑问大家可以留言交流,谢谢大家对的支持。
声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。
方法一:通过oplog恢复如果部署的是MongoDB复制集,这时还有一线希望,可以通过oplog来尽可能的恢复数据;MongoDB复制集的每一条修改操作都会记录
详解mongoDB主从复制搭建详细过程实验目的搭建mongoDB主从复制主192.168.0.4从192.168.0.7mongodb的安装1:下载mongod
mongodb数据如何还原,同步到其他系统?只要我们了解了数据库日志原理,一切都是那么简单oplog原理Oplog.rs表类型为CappedCollection
前言任何一种数据库都有各种各样的日志,MongoDB也不例外。MongoDB中有4种日志,分别是系统日志、Journal日志、oplog主从日志、慢查询日志等。
前言我们知道,MongoDB的Oplog(operationslog)记录了用户的最近一段时间的操作(时间长短主要受设置的oplogSize和程序的写入更新量的