MongoDB 副本集的组成

《MongoDB 副本集的组成》要点：
本文介绍了MongoDB 副本集的组成，希望对您有用。如果有疑问，可以联系我们。

《MongoDB 副本集的组成》是否对您有启发，欢迎查看更多与《MongoDB 副本集的组成》相关教程，学精学透。编程之家PHP学院为您提供精彩教程。

同步

MongoDB的复制功能是使用操作日志oplog实现的,操作日志包含了主节点的每一次写操作.

这样,每个成员都可以作为同步源供给其他成员使用

备份节点从当前使用的同步源中获取需要执行的操作,然后在自己的数据集上执行这些操作,最后再将这些操作写入自己的oplog

初始化同步

副本集中的成员启动之后,就会坚持自身状态,确定是否可以从某个成员哪里进行同步

如果不行的话,它会尝试从副本的另一个成员那里进行完整的数据复制.这个过程就是初始化同步(initial syncing)

处理陈旧数据

如果备份节点远远落后于同步源当前的操作,那么这个备份节点就是陈旧的(sale).

当一个备份节点陈旧之后,它会查看副本集中的其他成员,如果某个成员的oplog足够详尽,可以用于处理那些落下的操作,就从这个成员处进行同步

如果任何一个成员的oplog都没有参考价值,那么这个成员的复制操作就会中止,这个成员需要重新进行完全同步(或者从最近的备份中恢复)

为了避免陈旧备份节点的出现,让主节点使用比较大的oplog保存足够多的操作日志是很重要的

心跳

每个成员每隔两秒钟就会向其他成员发送一个心跳请求(heartbeat request)

心跳请求的信息量非常小,用于检查每个成员的状态

STARTUP

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

STARTUP2

这个初始化同步过程都处于这个状态,但是如果是在普通成员上,这个状态只会持续几秒钟.在这个状态下,MongoDB会创建几个线程,

用于处理复制和选举,然后就会切换到RECOVERING状态

RECOVERING

这个状态表明成员运作正常,但是暂时还不能处理读取请求.如果有成员处于这个状态,可能会造成轻微的系统过载,以后可能会经常见到

启动时,成员需要做一些检查以确保自己处于有效状态,之后才可以处理读取请求.

ARBITER

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

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

DOWN

如果一个正常运行的成员变得不可达,它就处于DOWN状态,如果网络有问题,状态可能是DOWN状态

UNKNOWN

如果一个成员无法到达其他任何成员,其他成员就无法知道它处于什么状态,会将其报告为UNKNOWN状态

通常,这表明这个未知状态的成员挂掉了,或者是两个成员之间存在网络访问问题

REMOVED

当成员被移出副本集时,它就处于这个状态.

如果被移出的成员又被重新添加到副本集中,它就会回到“正常”状态

ROLLBACK

如果成员正在进行数据回滚,它就处于ROLLBACK状态

回滚过程结束时,服务器会转换为RECOVERING状态,然后成为备份节点

FATAL

如果一个成员发生了不可挽回的错误,也不再尝试恢复正常的话,它就处于FATAL状态

使用"replSet FATAL"关键词在日志上执行grep

选举

回滚