此文已由作者温正湖授权网易云社区发布。
欢迎访问网易云社区，了解更多网易技术产品运营经验。
Primary（主）是MongoDB复制集中的最重要的角色，是能够接受客户端/Driver写请求的节点，（读请求也是默认路由到Primary节点）。在复制集中，与Primary相对应的有Secondary节点和Arbiter节点，分别表示从节点（可以接受读请求）和投票节点（仅用于投票选出新的Primary）。复制集是MongoDB的高可用框架，同时可以作为业务读写分离的一种方式。复制集提供了自动故障处理功能（当然还有其他功能，本文不展开），能够自动检测Primary节点是否宕机，进而选取新的Primary节点，并通过数据回追或数据回滚等方式实现复制集中数据一致。本文借助蜂巢MongoDB云服务的运行日志查看功能，来简要介绍Primary的选举过程。
MongoDB提供了强大的SystemLog模块，相比MySQL，MongoDB的运行日志模块做得更为贴心，通过日志能够有效跟踪MongoDB内部是如何进行一个个操作的。下面的图都截取自蜂巢MongoDB云服务的运行日志模块，从中能够看到了一串的MongoDB选主日志，非常清晰明了。
1、什么时候会发起选举？
图中所示，该节点（我）发现在过去的10s中时间内，复制集中没有Primary，
那么我怎么知道这段时间没有主呢，因为我每2s会给复制集中的其他节点发送心跳，
有些节点不回我
在超时时间内（默认10s）我会一直发。
除了心跳，我还会发送其他的命令，另外我还需要跟着Primary的opLog做复制，但是我发现没法再跟他做复制了，也找不到其他节点做复制
既然没有Primary。。。
2、我能不能被选为Primary呢？
我先试探性的问大家愿不愿意让我当Primary。于是我打算先发起 “dry election”，让人惊喜的是另一个节点竟然同意了，开心 ：）。由于复制集中一共3个节点。除了自己外另一个节点也同意了，那么我就有资格当Primary；注意此时term 没有更新，还是0（看第一个图~~）。因为这个是非正式选举
3、既然这样，那我就发起正式选举吧
结果当然是十拿九稳了，那么为什么要先有dry呢，为了保证选举成功率，相比正式选举，dry阶段检查的东西少，效率更高些。此时term已经自豪地更新为1。
4、我果然被大家选为Primary
一切尽在掌握中的感觉真爽！！
5、那我就把自己的角色切换为Primary呗
等等，这个时候我还不能马上接受客户端的写请求，因为我得看看自己的数据是不是最新的，怎么办呢，oplog里面的optime。看看大家的状态（数据新旧情况）
我等大家回复我：
好了，节点202回我了（他把他自己的rs.status()发给我， 看看在他的世界里这个复制集是什么情况），（200连不上），从这些信息我可以知道，我的数据是最新的。而且我从202知道200确实挂了。
6、既然我的数据是最新的，那么我就不需要从其他节点拷贝数据了
这里跟raft不一样，从raft的论文中，可以确定raft选为primary是必须要求数据最新的。但MongoDB选出的Primary，数据不一定要最新，只需要满足一个约定条件即可（oplog落后10s以内）。如果数据落后集群中的某个/些存活节点（这个情况一般出现在当前节点的priority比拥有更新数据的节点高的时候），在我对外提供写服务前，我先把这些数据从其他节点从抓过来，应用到我自己这里。但是我这个是有原则的，我不会那么贪婪，给我2s（catchUpTimeoutMillis）就好了。我能追上多少就追多少。如果时间到了，我还没有完全追上咋办呢，那也没有办法，让这些节点把没追上的数据回滚掉好了。
7、现在我的数据是最新的了，我开始作为Primary对外提供写服务。你们把写请求发过来吧~~~
也就是说，并不是成为Primary后马上就会提供写服务，而是会有个追数据的过程。我觉得这个特性如果大家么有正确理解，很容易出现问题。比如用户设置了writeconcern是majority，在主从切换的场景下，可能还未写到大多数节点的请求因为主挂了返回失败，但其实这个数据会被持久化到新主上。而严格的raft不会出现这个情况。
以上用第一张图大体介绍了选举过程。然后每一点的仔细介绍时，我将MongoDB的SystemLog级别通过db.setLogLevel()从0设置为2，重演了一遍选举。让大家看到更多的细节。
最后安利下，网易蜂巢MongoDB云服务已经重磅上线，蜂巢MongoDB由业界著名的数据库专家姜承尧亲自把关架构设计，免费提供售前技术支持。要知道姜大神的出台费可是业界最贵的 ：），欢迎大家注册试用。有任何意见和建议，请随时提出。
网易云免费体验馆，0成本体验20+款云产品！
更多网易技术、产品、运营经验分享请点击。
文章来源：