zoukankan      html  css  js  c++  java
  • MongoDB复制二:复制集的管理

    1.修改oplog的大小 
    需要在每个机器上都配置。先在secondary上操作,最后在primary上操作。
    1)以单机的方式重启复制集的实例
    1. db.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() ) tempoplog保存到新建的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 admin
    db.shutdownServer()
    2)以单实例的方式在不同端口启动该结点
    mongod --dbpath /usr/mongodb/data/db --port 37017
    3)执行维护任务,比如升级数据库
    4)关闭单实例节点
    use admin
    db.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)方法二
    使用命令设置primary
    m1,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目录,自动实现resync
    b.复制其它节点的--dbpath目录内容,然后启动实例,自动使用oplog同步

    1)自动resync
    a.关闭节点 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 shooting
    1)检查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.复制集相关的函数


    8.复制输命令
























  • 相关阅读:
    cpu_relax
    x86汇编寄存器,函数参数入栈说明
    内核调试打印dump_stack
    内核模块中计算执行时间
    js
    JS解析+预解析相关总结
    github-如何设置SSH Key
    块级元素与行内元素的区别
    编写高质量代码——html、css、javascript
    jquery——简单的下拉列表制作及bind()方法的示例
  • 原文地址:https://www.cnblogs.com/skyrim/p/5099839.html
Copyright © 2011-2022 走看看