mongodb副本集常用操作
[TOC]
副本集 • 状态检查
- 执行 rs.conf() 检查副本集配置,副本集支持节点成员切换,其中使用的是投票竞选机制,而投票竞选机制主要是通过 priority 参数来控制,节点的 priority 值越大,切换时的优先级越高
[root@localhost ~]# mongo 10.30.3.232:3717
set3717:PRIMARY> rs.conf()
{
"members" : [
{"_id" : 2, "host" : "10.30.3.231:3717", "arbiterOnly" : false, "hidden" : false, "priority" : 10, "votes" : 1},
{"_id" : 3, "host" : "10.30.3.232:3717", "arbiterOnly" : false, "hidden" : false, "priority" : 15, "votes" : 1},
{"_id" : 5, "host" : "10.30.3.233:3717", "arbiterOnly" : false, "hidden" : false, "priority" : 5, "votes" : 1}
]
}
- 执行 rs.status() 检查副本集状态
[root@localhost ~]# mongo 10.30.3.232:3717
set3717:PRIMARY> rs.status()
{
"members" : [
{"_id" : 2,"name" : "10.30.3.231:3717","state" : 2,"stateStr" : "SECONDARY","syncingTo" : "10.30.3.232:3717"},
{"_id" : 3,"name" : "10.30.3.232:3717","state" : 1,"stateStr" : "PRIMARY"},
{"_id" : 5,"name" : "10.30.3.233:3717","state" : 2,"stateStr" : "SECONDARY","syncingTo" : "10.30.3.232:3717"}
]
}
- 附:复制集的各种节点状态参考
节点state | 节点stateStr | 节点状态描述 |
---|---|---|
1 | PRIMARY | 主节点 |
2 | SECONDARY | 备份节点 |
- | STARTUP | 刚加入到复制集中,配置还未加载 |
- | STARTUP2 | 配置已加载完,初始化状态 |
- | RECOVERING | 正在恢复,不适用读 |
- | ARBITER | 仲裁者 |
- | DOWN | 节点不可到达 |
- | UNKNOWN | 未获取其他节点状态而不知是什么状态,一般发生在只有两个成员的架构,脑裂啦 |
- | REMOVED | 移除复制集 |
- | ROLLBACK | 数据回滚,在回滚结束时,转移到RECOVERING或SECONDARY状态 |
- | FATAL | 出错。查看日志grep “replSet FATAL”找出错原因,重新做同步 |
副本集 • 延迟调优
- 延迟过高,通常是由于从库节点的磁盘io性能较差所致。查看存在延迟的节点的磁盘规格,确认iops与主库一致
- 分析延迟的常用命令如下:
rs.status() #.显示复制集的节点状态
rs.isMaster() #.显示当前谁是primay
rs.secondaryOk() #.在从库上执行读操作.新版本
rs.slaveOk() #.在从库上执行读操作.旧版本
rs.printSlaveReplicationInfo() #.查看复制延迟,主从均有效
rs.printSecondaryReplicationInfo(); #.查看复制延迟,仅主库有效
db.currentOP(); #.查看当前操作
- 通过调整写操作的确认级别来提高性能及降低延迟
#.mongodb的3种写操作的确认级别
majority 数据写入到副本集大多数成员后向客户端发送确认,适用于对数据安全性要求比较高的场景,该选项会降低写入性能
acknowledged 默认的writeConcern,数据写入到Primary就向客户端发送确认
unacknowledged 对客户端的写入不需要发送任何确认,适用于性能要求高,但不关注正确性的场景
#.如何调整写操作的确认级别
写入操作中指定: db.collection.insertOne({name: "sam",age:30},{writeConcern: {w: "majority"}});
集合级别确认: db.collection.getWriteConcern();
集合级别设置: db.collection.setWriteConcern({w: "majority"});
数据库级别设置: db.getMongo().setWriteConcern({w: "majority"});
副本集 • 节点管理
- 示例环境:主节点为
10.30.3.231:3717
[root@localhost ~]# mongo 10.30.3.231:3717
set3717:PRIMARY> rs.conf()
{
"members" : [
{"_id" : 2, "host" : "10.30.3.231:3717", "arbiterOnly" : false, "hidden" : false, "priority" : 15, "votes" : 1},
{"_id" : 3, "host" : "10.30.3.232:3717", "arbiterOnly" : false, "hidden" : false, "priority" : 10, "votes" : 1},
{"_id" : 5, "host" : "10.30.3.233:3717", "arbiterOnly" : false, "hidden" : false, "priority" : 5, "votes" : 1}
]
}
- 调整某个节点(示例 members[2] 即 第3个节点 即 _id:5)的优先级,修改优先级会触发选举,注:调用 rs.reconfig 可能会导致当前主库中断,因为需要重新执行主节点竞选
[root@localhost ~]# mongo 10.30.3.231:3717
set3717:PRIMARY> var cfg=rs.conf()
set3717:PRIMARY> cfg.members[2].priority = 2
set3717:PRIMARY> rs.reconfig(cfg)
- 调整某个节点(示例 members[2] 即 第3个节点 即 _id:5)为隐藏节点,注:仅当其优先级为0时,才可以设置节点隐藏
[root@localhost ~]# mongo 10.30.3.231:3717
set3717:PRIMARY> var cfg=rs.conf()
set3717:PRIMARY> cfg.members[2].priority=0
set3717:PRIMARY> cfg.members[2].hidden=1
set3717:PRIMARY> rs.reconfig(cfg)
- 添加节点:登录主节点,利用 rs.add 添加新节点(为了不与现有的节点冲突,示例 _id:6),并调整priority为最低,此时新节点的数据将从0初始化(注:新节点不用做备份+还原哦)
#.添加之前(1.创建mongo目录;2.拷贝keyfile;3.取消所有注释后启动Mongo进程)
[root@localhost ~]# mongo 10.30.3.231:3717
set3717:PRIMARY> rs.add({ _id:6, host:"10.30.3.234:3717", priority:1, votes:1});
set3717:PRIMARY> rs.conf();
- 删除节点:登录主节点,利用 rs.remove 移除老节点
[root@localhost ~]# mongo 10.30.3.231:3717
set3717:PRIMARY> rs.remove("10.30.3.233:3717")
set3717:PRIMARY> rs.conf();