MongoDB复制集成员及状态转换

此文已由做者温正湖受权网易云社区发布。

欢迎访问网易云社区，了解更多网易技术产品运营经验。

复制集（Replica Set）是MongoDB核心组件，相比早期版本采用的主从（Master-Slave）架构，复制集具备不少自然的优点，包括自动故障恢复、多机房部署、读写行为控制等。本文介绍复制集中最基础的部分，就是复制集成员（Replica Set Member）。大致分为成员的角色及转换、成员状态及转换两部分。

先来讲说成员角色，可分为Primary、Secondary和Arbiter三类。其中前两种是常规角色，每一个复制集在正常状态下都会有这两种角色，Arbiter是一种特殊角色，其不包含用户数据，仅在选举时起做用。在这之中，Secondary又能够细分出不少熟悉，详见下面描述。

MongoDB在分布式架构上与Raft相相似，其Leader被称为Primary，Follower称为Secondary，但MongoDB中没有定义candidate角色。Primary即复制集的主节点，是惟一有权限接受客户端写请求的节点，会将全部的插入和更新操做记录到oplog中，Primary也是默认全部读请求的目标节点。Secondary复制Primary（或其余Secondary）的oplog记录并本地回放，来保持与Primary数据一致，可设置为容许客户端读，但默认状况下Secondary不容许读，须要设置slaveok参数。

Arbiter与上述两种角色不一样，其不包含用户数据副本，复制集中添加Arbiter的目的仅仅是为了选主操做。一般在拥有偶数个节点的复制集中添加（且仅能添加）一个Arbiter，这样可使一次选举中达到大多数（majority）而避免选举分裂（split vote）。以下所示：

  当Primary由于某些缘由挂掉或降级时，Secondary可经过选举成为新的Primary，原Primary恢复并从新加入复制集后，变为Secondary。Arbiter因为不包含用户数据，因此不可能成为Primary。这是他们间的相互转换关系。Primary、Secondary和Arbiter应独立部署在不一样的网络节点上，对于云环境下，也不能位于相同的宿主机上，确保相互间数据安全性和选举独立性。

  一个复制集中仅有一个Primary，在某些特殊场景下，可能没有Primary。Arbiter在集群中不是必须的。因此，集群中最普通的角色是Secondary，通常很多于2个。不一样的Secondary能够有不一样的属性，处于不一样的状态中。Secondary属性有以下几类：

与选举相关的属性：

一、  是否能被选为Primary，该属性由priority控制，priority越高，就越有机会成为Primary，一般状况下，Primary老是复制集中priority最高的成员，priority为0的Secondary不能被选为Primary，该特性通常用于跨机房部署时，避免failover后新Primary切到另外一个机房；

二、  是否有选举权，MongoDB复制集能够有多大50个成员，但仅容许7个成员有选举权，该属性由votes控制，votes为0的成员没有选举权，但能够否决选举，也能够成为Primary（能够理解为没法投同意票，均可以投反对票和发起选举，由于被选举权由priority控制）。MongoDB 3.0版本开始，不容许设置成员的votes大于1。

与客户端相关的属性：

  一、客户端是否可见，该参数由hidden控制，hidden为true表示不可见，客户端没法从该节点读取数据，mongos不会跟其交互；因为对客户端不可见，则确定不能被选举为Primary，因此其priority属性必须为0；该节点通常用于进行备份等用途。

与数据延迟相关的属性：

  一、slaveDelay用于控制该Secondary节点跟Primary节点的复制延迟关系，例如slaveDelay为3600，表示其数据相比Primary落后1小时，延迟判断是经过oplog中的信息来肯定。该属性通常做为在线的历史备份，用来回滚人为操做致使的错误，包括误删除数据库或集合等；该属性潜在地须要priority属性为0，hidden属性为true；

能够看出，相比MySQL的Replication，MongoDB的Replica Set成员的类型和属性更为丰富，固然，主要缘由是MySQL目前仍是Master-Slave主从复制，因此与选举相关的属性或角色就没有存在的必要。但，MySQL也有相似的slaveDelay功能。另外，尚处于实验室状态MySQL Group Replication正式发布将会惊动数据库界。

聊完类型和属性，下面再来看当作员状态，很少很多，MongoDB一共有10种状态，官方将其分为3大类，核心状态（Core States）为三种成员类型对应的属性（PRIMARY/SECONDARY/ARBITER），还有7种属性，被分为其余状态（Other States）和错误状态（Error States）两类。

按照时间序，其余状态分别为STARTUP、STARTUP2和RECOVERING。每一个复制集成员在mongod启动后，都先进入STARTUP状态，而后加载成员的复制集配置，以后进入到STARTUP2状态。若是该成员须要进行初始同步（initial sync），那么它将长期处于该状态，知道同步完全部的数据和索引。随后进入到RECOVERING状态，处于该状态的成员不能接受客户端的读请求，也不能被选举为Primary，但能够进行投票选举。

错误状态以下所示：若成员已加入了复制集，但还未进行状态信息同步的，会被其余复制集成员标记为UNKNOWN;若成员再也不可以经过心跳来进行状态同步，即失去联系，则被其余成员标记为DOWN；REMOVED表示该成员已经被移出复制集；成员处于rollback过程时，状态为ROLLBACK，该状态在旧的primary从新加入复制集时可能出现，用于回滚其上还未同步到其余Secondary的操做；FATAL状态表示成员遇到了没法恢复的错误，必须进行人工处理。

选举行为除了受vote和priority两个属性影响外，成员的状态也会影响选举，仅有PRIMARY, SECONDARY, RECOVERING, ARBITER和ROLLBACK五种状态的成员容许进行投票操做。

网易云免费体验馆，0成本体验20+款云产品！ 

更多网易技术、产品、运营经验分享请点击。

相关文章：
【推荐】 网易云原生架构实践之服务治理
【推荐】 网易云复盘：云计算前端这一年（AngularJS粉慎入）
【推荐】 一次活动引起的血案