本站文章除注明转载/出处外,均为本站原创或翻译,转载前请务必署名原文链接~~~

MongoDB 副本集的成员状态

微信搜索 zze_coding 或扫描 👉 二维码关注我的微信公众号获取更多资源推送:


每个成员都需要知道其他成员的状态:哪个是主节点?哪个可以作为同步源?哪个挂掉了?为了维护集合的最新视图,每个成员每隔两秒钟就会向其他成员发送一个心跳请求( 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 状态的时间点)。这时,通常应该重启服务器,进行重新同步或者是从备份中恢复。
# MongoDB  

如果这篇文章对您有帮助,可点击下方链接分享给你的朋友们😋,如果遇到问题欢迎评论、留言~~~😇

评论

公众号:zze_coding

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×