mongodb复制集主辅节点升降级的一次实践和注意事项
目的
- 本文是接上篇mongodb3.0.7扩容存储记录,作为补充说明完整的升级过程;
解决上文遗留的问题
上次降级回3.0的原因是部分应用的mongodb驱动过低,不支持mongodb3.4造成,本次升级前检查了所有应用的驱动并做了升级并通过了兼容性测试。
示例如下
假设有一个复制集有一个primary和三个sencondary组成
primary:10.0.1.32 secondary:10.0.1.31 、10.0.1.33、192.168.1.230
rs.status()显示
rs.status() { ...... "members" : [ { "_id" : 0, "name" : "10.0.1.31:27017", "health" : 1, "state" : 1, "stateStr" : "SECONDARY", ...... }, { "_id" : 1, "name" : "10.0.1.32:27017", "health" : 1, "state" : 5, "stateStr" : "PRIMARY", ...... }, { "_id" : 2, "name" : "192.168.1.230:27017", "health" : 1, "state" : 5, "stateStr" : "SECONDARY", ...... }, { "_id" : 3, "name" : "10.0.1.33:27017", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", ...... } ], "ok" : 1 }
切换目标:31升级为primary,32降级为secondary
primary:10.0.1.31 secondary:10.0.1.32 、10.0.1.33、192.168.1.230
切换步骤(均在mongodb shell上执行)
- 1、primary上设定各个节点优先级
cfg = rs.conf() cfg.members[0].priority = 1 cfg.members[1].priority = 0.5 cfg.members[2].priority = 0.5 cfg.members[3].priority = 0.5 rs.reconfig(cfg)
- 2、33和230节点上执行rs.freeze(120)命令,组织其在120秒内成为primary节点
rs.freeze(120)
- 3、primary上执行降级命令,使其120秒内不再成为primary
rs.stepDown(120)
- 4、观察31节点发现已经成为primary
rs.status() { ...... "members" : [ { "_id" : 0, "name" : "10.0.1.31:27017", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", ...... }, { "_id" : 1, "name" : "10.0.1.32:27017", "health" : 1, "state" : 5, "stateStr" : "SECONDARY", ...... }, { "_id" : 2, "name" : "192.168.1.230:27017", "health" : 1, "state" : 5, "stateStr" : "SECONDARY", ...... }, { "_id" : 3, "name" : "10.0.1.33:27017", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", ...... } ], "ok" : 1 }
5、升级32节点mongodb到3.4版本
详细过程mongodb3.0.7扩容存储记录文中有介绍
6、重新将32节点加入复制集
从节点31上复制集配置文件过来,将bindip修改为本机32保存退出,执行systemctl start mongod即可。
注意事项
- 设定优先级要一定要先做,否则当primary发布stepDown之后,各节点投票选举的primary不一定是期望的节点
- 事先准备好各主机执行命令及执行顺序,每个节点开一个shell窗口,然后把事先准备好的命令粘贴进来按照顺序执行
- 升降级完成之后,各连接mongodb的应用,需要重启连接新的primary,这个执行命令也要事先准备好