微信公众号:DBA随笔
今天遇到其他团队同事问了一个MongoDB选主的问题,这里记录一下过程,希望对大家有帮助。
环境描述:
有三台服务器,IP地址分别为:
198.168.0.1
198.168.0.2
198.168.0.3
组成的副本集架构如下:
此时,同事期望加入节点4来代替节点3,加入第4个节点,加入之后,开始进行全量数据同步,架构变成下面这样:
本来这个过程,是没有什么问题的。但是此时有一个不规范的操作,就是在节点4还没有完全加入到集群的时候,对节点3进行了kill 进程的操作,结果kill掉节点3之后,节点4由于配置出错,进程也停掉了,结果导致副本集架构变成了:
很快,在这种架构下,发现primary节点很快降级成了secondary,也就是说,集群中没有primary节点了。
其实这个问题还是比较好定位的,在MongoDB的选举机制中,要满足"大多数法则","大多数"的概念,不难理解。节点数、赞成票数和最高可容错节点数的关系,如下:
可以看到:
3节点情况下,要满足大多数法则,集群中需要2个可投票的节点;
4节点情况下,要满足大多数法则,集群中需要3个可投票的节点;
而上述场景中,原本集群是3副本节点,一主两从,其中1个节点出现问题,另外2个仍旧可以投票选举出来primary节点;加入1个节点之后,变成了4个节点,再想投票选举primary节点,需要3个的投票,而实际过程中,挂掉了节点3和节点4,就导致无法选举,primary节点降级成为了secondary节点。
从上述的描述中不难得出以下结论:
新节点的引入后,如果集群节点为偶数,那么这个操作并没有增加集群的容错数,相反,会导致集群的大多数法则下的票数增加,集群的稳定性降低。
具体表现在:原来3节点情况下,只要有2个存活,就能够投票选出primary;而4节点情况下,有2个存活,不能投票选举出primary
可以从上面的表格中进一步总结,得到以下结论:
如果集群的节点个数从奇数增加到偶数,则容错节点数不变,赞成票数增加;
如果集群的节点个数从偶数增加到奇数,则赞成票数不变,容错节点数增加;
因此,为了保证集群稳定性,一般需要设置MongoDB集群的个数为奇数。
为了更好理解,这里把MongoDB副本集的架构图搬下来:
在这个MongoDB案例中,由于我们的节点3和节点4都是进程挂掉,而配置还保留在集群中,所以无法选举primary。而解决集群中无法选举出primary节点的问题,可以使用下面的方法:
1、将节点一快速使用单机模式启动,单机模式启动,然后再补充其他的节点。可以查看MongoDB官网的这个文章:
https://docs.mongodb.com/manual/tutorial/perform-maintence-on-replica-set-members/#restart-the-secondary-as-a-standalone-on-a-different-port
2、将配置中的节点3或者节点4,删除掉一个,恢复成3节点的配置,让MongoDB自动选主。
如果你直接使用rs.remove命令,会得到如下结果:
SECONDARY> rs.remove("192.168.1.4:10489") { "ok" : 0, "errmsg" : "replSetReconfig should only be run on PRIMARY, but my state is SECONDARY; use the "force" argument to override", "code" : 10107 }
显然,无法在secondary上执行这个命令,提示让我们使用force命令,那么这种情况下,如何使用force命令来清理配置呢?正确的姿势如下:
SECONDARY> cfg=rs.conf() SECONDARY> cfg.members.splice(2,1) # 从下标2的节点开始,删除1个节点配置 SECONDARY> rs.reconfig(cfg,{force:true})
更多详细内容,可参考官方文档:
https://docs.mongodb.com/manual/tutorial/remove-replica-set-member/