MongoDB 副本集的成员状态

每个成员都需要知道其他成员的状态：哪个是主节点？哪个可以作为同步源？哪个挂掉了？为了维护集合的最新视图，每个成员每隔两秒钟就会向其他成员发送一个心跳请求（ heartbeat request）。心跳请求的信息量非常小，用于检查每个成员的状态。

心跳最重要的功能之一就是让主节点知道自己是否满足集合“大多数”的条件。如果主节点不再得到“大多数”服务器的支持，它就会退位，变成备份节点。

各个成员会通过心跳将自己的当前状态告诉其他成员。我们已经讨论过两种状态了：主节点和备份节点。还有其他一些常见状态。

• STARTUP
  成员刚启动时处于这个状态。在这个状态下， MongoDB 会尝试加载成员的副本集配置。配置加载成功之后，就进入 STARTUP2 状态。

• STARTUP2
  整个初始化同步过程都处于这个状态，但是如果是在普通成员上，这个状态只会 持续几秒钟。在这个状态下， MongoDB 会创建几个线程，用于处理复制和选举，然后就会切换到 RECOVERING 状态。

• RECOVERING
  这个状态表明成员运转正常，但是暂时还不能处理读取请求。如果有成员处于这个状态，可能会造成轻微的系统过载，以后可能会经常见到。
  启动时，成员需要做一些检查以确保自己处于有效状态，之后才可以处理读取请求。在启动过程中，成为备份节点之前，每个成员都要经历 RECOVERING 状态。在处理非常耗时的操作时，成员也可能进入 RECOVERING 状态。比如压缩或者是响应 replSetMaintenance 命令。
  当一个成员与其他成员脱节时，也会进入 RECOVERING 状态。通常来说，这时这个成员处于无效状态，需要重新同步。但是，成员这时并没有进入错误状态，因为它期望发现一个拥有足够详尽 oplog 的成员，然后继续同步 oplog，最后回到正常状态。

• ARBITER
  在正常的操作中，仲裁者应该始终处于 ARBITER 状态。

系统出现问题时会处于下面这些状态。

• DOWN
  如果一个正常运行的成员变得不可达，它就处于 DOWN 状态。注意，如果有成员被报告为 DOWN 状态，它有可能仍然处于正常运行状态，不可达的原因可能是网络问题。
• UNKNOWN
  如果一个成员无法到达其他任何成员，其他成员就无法知道它处于什么状态，会将其报告为 UNKNOWN 状态。通常，这表明这个未知状态的成员挂掉了，或者是两个成员之间存在网络访问问题。
• REMOVED
  当成员被移出副本集时，它就处于这个状态。如果被移出的成员又被重新添加到副本集中，它就会回到“正常”状态。
• ROLLBACK
  如果成员正在进行数据回滚，它就处于 ROLLBACK 状态。回滚过程结束时，服务器会转换为 RECOVERING 状态，然后成为备份节点。
• FATAL
  如果一个成员发生了不可挽回的错误，也不再尝试恢复正常的话，它就处于 FATAL 状态。应该查看详细日志来查明为何这个成员处于 FATAL 状态（使用
  replSet FATAL 关键词在日志上执行 grep，就可以找到成员进入 FATAL 状态的时间点）。这时，通常应该重启服务器，进行重新同步或者是从备份中恢复。