单台MongoDB实例开启Oplog
2018-09-19 00:00
1896 查看
背景
随着数据的积累,MongoDB中的数据量越来越大,数据分析团队从数据库中抽取变化数据(假如依据栏位createdatetime,transdatetime),越来越困难。我们知道MongoDB的副本集有一个数据结构Oplog,里面存储了Primary节点的所有写操作(此处的写操作是指查询以外的操作,包含 更新、异常等)。其实,数据的抽取完全可以从Oplog中抓取这些操作,然后去重放。
但是在实际的生产环境中,我们很多MongoDB 数据库是单实例的,那么我们能否在单实例数据库上开启Oplog?
答案是肯定的。
其原理就是,在单实例上配置副本集,如果配置成功了,自然就有了Oplog。
step 1 : 在配置文件中 添加副本集参数(replSet);
step 2 :重启服务;
step 3:在local数据库或admin数据库执行初始化副本集的脚本,rs.initiate()。
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 issue rs.initiate() on the local database:
4. 初始完,副本集中唯一的节点,可能短时间显示为SECONDARY或OTHER。一般而言,稍等一会,就会自然恢复为primary,无需人工干预。
或
如果数据库的数据量不大,并且长时间初始这种过渡状态(SECONDARY或OTHER),去看实例的日志,也显示无进展,此时可以考虑重启服务。
下面案例是我们实际遇到的一个场景,我们是通过重启服务解决此问题,角色由other重启转换为Primary
随着数据的积累,MongoDB中的数据量越来越大,数据分析团队从数据库中抽取变化数据(假如依据栏位createdatetime,transdatetime),越来越困难。我们知道MongoDB的副本集有一个数据结构Oplog,里面存储了Primary节点的所有写操作(此处的写操作是指查询以外的操作,包含 更新、异常等)。其实,数据的抽取完全可以从Oplog中抓取这些操作,然后去重放。
但是在实际的生产环境中,我们很多MongoDB 数据库是单实例的,那么我们能否在单实例数据库上开启Oplog?
答案是肯定的。
其原理就是,在单实例上配置副本集,如果配置成功了,自然就有了Oplog。
配置过程
其实配置的过程比较简单。step 1 : 在配置文件中 添加副本集参数(replSet);
step 2 :重启服务;
step 3:在local数据库或admin数据库执行初始化副本集的脚本,rs.initiate()。
注意事项
1. 在配置文件中增加副本集参数(replSet=??),MongoDB实例重启,第一次登入,执行其他命令时(例如:show dbs),会提示错误,错误信息如下, { "ok" : 0, "errmsg" : "not master and slaveOk=false", "code" : 13435, "codeName" : "NotMasterNoSlaveOk" } 此时一定要执行初始化的命令: rs.initiate({ _id: "副本集名称", members: [{_id:0,host:"ServerIP:MongoDBPort"}]})
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 issue rs.initiate() on the local database:
4. 初始完,副本集中唯一的节点,可能短时间显示为SECONDARY或OTHER。一般而言,稍等一会,就会自然恢复为primary,无需人工干预。
或
如果数据库的数据量不大,并且长时间初始这种过渡状态(SECONDARY或OTHER),去看实例的日志,也显示无进展,此时可以考虑重启服务。
下面案例是我们实际遇到的一个场景,我们是通过重启服务解决此问题,角色由other重启转换为Primary
相关文章推荐
- 关于单台MongoDB实例开启Oplog的过程详解
- mongodb之oplog
- MongoDB副本集配置系列七:MongoDB oplog详解
- 查询MongoDB oplog.rs
- 使用MONGODB 集群的OPLOG 日志进行数据恢复
- MongoDB安装以及MongoDB开启多实例
- Mongodb Journaling and replica-set oplog
- mongoDB的复制集2----同步机制(工作原理,oplog详解,初始化同步的过程
- mongoDB oplog的说明及应用
- Nosql Mongodb之旅(23)—MongoDB Replica oplog
- Mongodb源码分析--Replication之OpLog
- Mongodb 源码分析--Replication之OpLog
- MongoDB Replication Oplog
- MongoDB学习之旅二十二:MongoDB Replica oplog
- 关于mongodb 的Oplog
- mongodb之 oplog 日志详解
- 修改mongodb oplog size
- 利用MongoDB中oplog机制实现准实时数据的操作监控
- mongodb中mongodump 使用 --oplog 参数备份非常的慢
- MongoDB oplog 深入剖析