MongoDB选主问题一例

微信公众号：DBA随笔

01、问题描述

今天遇到其他团队同事问了一个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节点了。

02、分析定位

其实这个问题还是比较好定位的，在MongoDB的选举机制中，要满足"大多数法则"，"大多数"的概念，不难理解。节点数、赞成票数和最高可容错节点数的关系，如下：

可以看到：

3节点情况下，要满足大多数法则，集群中需要2个可投票的节点；

4节点情况下，要满足大多数法则，集群中需要3个可投票的节点;

而上述场景中，原本集群是3副本节点，一主两从，其中1个节点出现问题，另外2个仍旧可以投票选举出来primary节点；加入1个节点之后，变成了4个节点，再想投票选举primary节点，需要3个的投票，而实际过程中，挂掉了节点3和节点4，就导致无法选举，primary节点降级成为了secondary节点。

从上述的描述中不难得出以下结论：

新节点的引入后，如果集群节点为偶数，那么这个操作并没有增加集群的容错数，相反，会导致集群的大多数法则下的票数增加，集群的稳定性降低。

具体表现在：原来3节点情况下，只要有2个存活，就能够投票选出primary；而4节点情况下，有2个存活，不能投票选举出primary

可以从上面的表格中进一步总结，得到以下结论：

如果集群的节点个数从奇数增加到偶数，则容错节点数不变，赞成票数增加；

如果集群的节点个数从偶数增加到奇数，则赞成票数不变，容错节点数增加；

因此，为了保证集群稳定性，一般需要设置MongoDB集群的个数为奇数。

03、解决问题

为了更好理解，这里把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/