《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
选举
回滚
总结以上是内存溢出为你收集整理的MongoDB 副本集的组成全部内容,希望文章能够帮你解决MongoDB 副本集的组成所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)