首页 / MONGODB / MongoDB复制二：复制集的管理

MongoDB复制二：复制集的管理

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了MongoDB复制二：复制集的管理，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含5137字，纯文字阅读大概需要8分钟。

内容图文

.shutdownServer()在新的端口中启动实例
  1. mongod --port 37017 --dbpath /usr/local/mongodb-linux-x86_64-3.2.0/data
2)备份原来的oplog
  1. [root@node1 mongodb-linux-x86_64-3.2.0]# mongodump --db local --collection ‘oplog.rs‘ --port 37017 2015-12-27T02:27:40.577+0800 writing local.oplog.rs to dump/local/oplog.rs.bson 2015-12-27T02:27:40.579+0800 done dumping local.oplog.rs (4 documents)
3)复制最新的oplog条目到tmp表
  1. [root@node1 mongodb-linux-x86_64-3.2.0]# mongo --port 37017
  2. MongoDB shell version: 3.2.0
  3. connecting to: 127.0.0.1:37017/test
  4. > db.temp.save(db.oplog.rs.find({},{ts:1,h:1}).sort({$natural:-1}).limit(1).next());
  5. WriteResult({ "nInserted" : 1 })
  6. > db.temp.find();
  7. { "_id" : ObjectId("567edd9e48b1a3ebcf06049c"), "ts" : Timestamp(1451203909, 1), "h" : NumberLong("4300737341732033822") }
4)删除原来的oplog
  1. db.oplog.rs.drop()
5)重建oplog
    1. db.runCommand( { create: "oplog.rs", capped: true, size: (2 * 1024 * 1024 * 1024) } )
    2. (单位是字节)
    3. db.oplog.rs.save( db.temp.findOne() ) 把temp中oplog保存到新建的oplog中
    4. db.oplog.rs.find()

6)关闭实例，启动实例为replications sets的成员
  1. db.shutdownServer()
  2. mongod --replSet rs0 --dbpath /usr/local/mongodb-linux-x86_64-3.2.0/data
7)在primary中执行切换primary为secondary：
  1. rs.stepDown()
然后重复以上操作。
2.执行维护任务的步骤上面介绍了如何修改oplog。对于Recplication sets来说，执行维护任务的最常用流程如下：1)关闭secondary节点use admindb.shutdownServer()2)以单实例的方式在不同端口启动该结点mongod --dbpath /usr/mongodb/data/db --port 370173)执行维护任务，比如升级数据库4)关闭单实例节点use admindb.shutdownServer()5)以replication sets的方式启动节点mongod --replSet "rs01" --dbpath /usr/local/data/db --port 27017按上面的方式把所有secondary节点处理完。
在主节点上：1)执行db.stepDown()切换为secondary节点2)按照上面的1－5执行
3.强制某个节点变成主节点原理就是修改节点的优先级。1)方法一：有m1,m2,m3三个节点，原来m1是主节点，优先级都是1.执行以下操作：
  1. cfg = rs.conf()
  2. cfg.members[0].priority = 0.5
  3. cfg.members[1].priority = 0.5
  4. cfg.members[2].priority = 1
  5. rs.reconfig(cfg)
此时 m3的优先级最高。如果m3和m1之间的同步进度小于10秒，m1就切换为scondary节点m3就切换为primary节点;如果m3和m1之间的同步进度大于10秒，就先不切换，直接到m3追上m1(进度差小于10秒)
即使m3和m1之间的进度差大于10秒，想让m1变成secondary节点可以执行：
  1. db.adminCommand({replSetStepDown: 86400, force: 1})  24小时内让其成为主节点
此时全部节点为secondary，没有primary节点！等到m3赶上m1的进度，m3就成了primary节点。
2)方法二使用命令设置primarym1,m2,m3，m1为主节点.在m2上进入mongo：
  1. mongo
  2. >rs.freeze(120);120秒内不能成为主节点
在m1上执行：
  1. mongo
  2. >rs.stepDown(120);120秒内不能成为主节点
这时打开m3发现已经成为主节点。
4.节点执行resync有两种方式实现resync:a.清空--dbpath目录，自动实现resyncb.复制其它节点的--dbpath目录内容,然后启动实例，自动使用oplog同步
1)自动resynca.关闭节点 db.shutdownServer()b.清空--dbpath目录里的所有内容
c.以replication sets方式启动实例
2)手动复制数据a.在源节点上做--dbpath的磁盘快照；复制磁盘快照或者直接复制--dbpath目录。b.替换本节点上的--dbpath目录。c.启动实例问题：由于源节点上的--dbpath目录一直在改变，可能无法复制--dbpath目录。所以要做数据快照。
5.强制重新配置replication sets某些情况下(primary宕机又不能选出primary、配置错误导致大部分的节点宕机)，可以使用强制措施重新配置replication sets.正常情况下不要使用。1)连接到没有宕机的节点上2)执行cfg = rs.conf() cfg.members = [cfg.members[0] , cfg.members[4] , cfg.members[7]]  去掉宕机的节点rs.reconfig(cfg, {force : true})  然后这个设置自动传播到其它节点，之后节点会选出一个primary.
6.Trouble shooting1)检查replications set状态rs.status();2)检查复制间隙
  1. rs0:SECONDARY> rs.printSlaveReplicationInfo();
  2. source: 192.168.75.10:27017
  3.         syncedTo: Sun Dec 27 2015 16:11:49 GMT+0800 (CST)
  4.         0 secs (0 hrs) behind the primary 
  5. source: 192.168.75.11:27017
  6.         syncedTo: Sun Dec 27 2015 16:11:49 GMT+0800 (CST)
  7.         0 secs (0 hrs) behind the primary
有延迟的secondary节点也可能显示落后primary节点0秒。原因：主节点的空闲时间大于从节点上的SlaveDelay值。复制间隙产生的原因：
  • 网络原因
  • 磁盘原因
  • 大量并发
  • 大量写数据
  • oplog
3)测试连接性用mongo --host --port  测试各个节点
4)检查oplog日志rs.printReplicationInfo() oplog的日志的大小应该满足至少24个小时的操作，一般48小时或者72小时最好
5) 日志入口时间错误
错误信息：replSet error fatal couldn‘t query the local local.oplog.rs collection. Terminating mongod after 30 <timestamp> [rsStart] bad replSet oplog entry?  
原因：一般是由oplog最新一条的ts字段的格式错误造成的。该字段的格式是timestamp。检查字段：
  1. db = db.getSiblingDB("local")
  2. db.oplog.rs.find().sort({$natural:-1}).limit(1)
  3. db.oplog.rs.find({ts:{$type:17}}).sort({$natural:-1}).limit(1)
如果两个查询没有返回相同的结果，说明日志有错误：
  1. 第一个查询结果
  2. { "ts" : {t: 1347982456000, i: 1},
  3. "h" : NumberLong("8191276672478122996"),
  4. "op" : "n",
  5. "ns" : "",
  6. "o" : { "msg" : "Reconfig set", "version" : 4 } }
  7. 第二个查询结果
  8. { "ts" : Timestamp(1347982454000, 1),
  9. "h" : NumberLong("6188469075153256465"),
  10. "op" : "n",
  11. "ns" : "",
  12. "o" : { "msg" : "Reconfig set", "version" : 3 } }
更新错误的条目：
  1. db.oplog.rs.update( { ts: { t:1347982456000, i:1 } },{ $set: { ts: new Timestamp(1347982456000, 1)}})

7.复制集相关的函数MongoDB复制二：复制集的管理 - 文章图片

8.复制输命令MongoDB复制二：复制集的管理 - 文章图片





















来自为知笔记(Wiz)

MongoDB复制二：复制集的管理

标签：

本文系统来源：http://www.cnblogs.com/skyrim/p/5099839.html

内容总结

以上是互联网集市为您收集整理的MongoDB复制二：复制集的管理全部内容，希望文章能够帮你解决MongoDB复制二：复制集的管理所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/459394.html

来源：【匿名】