标签:tar 组成 失败 table over 批量 固定 inf startup
Mongodb的复制功能是使用操作日志oplog实现的,操作日志包含了主节点的每一次写操作。oplog是主节点的local数据库中的一个固定集合。
每个备份节点都维护这自己的oplog,记录着每一次从主节点复制数据的操作。
如果某个备份节点挂掉了,重新启动之后会自动从oplog中最后一个操作开始同步。由于复制操作是先复制数据再写入oplog,所以备份节点可能会在已经同步过的数据上再次执行复制操作。
由于oplog的大小是固定的,只能保存特定数量的操作日志。通常oplog使用空间的增长速度和系统处理写请求的速率近乎相同;但是如果执行db.foo.remove()
,如果foo中存在100条数据,则oplog就会有100条操作日志。如果执行大量的批量操作,oplog很快就被填满。
local.me
中为自己创建一个标识符,删除所有已经存在的数据库STARTUP | 成员刚启动时处于这个状态。在这个状态下,MongoDB会尝试加载成员的副本集配置,配置加载成功后,就会进入STARTUP2。 |
STARTUP2 | 整个初始化同步过程都处于这个状态,但是如果是在普通成员上,这个状态只会持续几秒钟,这个状态下,Mongodb会创建几个县城,用于处理**复制**和**选举**,然后切换到RECOVERING状态。启动时,成员需要做一些检查以确保自己处于有效状态,以后才可以处理读取请求,在启动过程中,成为备份节点之前,每个成员都要经历RECOVERING状态。在处理非常耗时的操作时,成员也可能进入RECOVERING状态;当一个成员与其他成员脱节时,也会进入RECOVERING状态。 |
RECOVERING | 这个状态表明成员运转正常,但是暂时不能处理读取请求,之后才可以处理读取请求,可能会造成轻微的系统过载。 |
ARBITER | 在正常的操作中,仲裁者应该始终处于该状态。 |
出现错误时的状态 | |
DOWN | 如果一个正常运行的成员不可达,就处于DOWN状态。 |
UNKNOWN | 如果一个成员无法到达其他任何成员,其他成员不知道它处于什么状态,会将其报告为UNKNOWN状态。 |
REMOVED | 成员被移除副本集时,就处于该状态。 |
ROLLBACK | 表明该成员正处于数据回滚。 |
FATAL | 成员发生了不可挽回的错误,也不在尝试恢复正常。 |
当一个成员无法到达主节点时,就会申请成为主节点。
希望被选举为主节点的成员,会向他能到达的所有成员发出通知,如果该成员数据落后于副本集,或者已经有一个运行中的主节点,其他成员不会允许选举。
如果该成员得到副本集中“大多数”赞成票,选举成功,切换为主节点。如果不满足票数,选举失败,保持在备份节点状态。
副本集重新配置也会导致主节点退位
当重新选举主节点时,某一个备份节点的操作数大于主节点的操作数,此时该节点需要将自己的操作数回滚,与主节点相同。
标签:tar 组成 失败 table over 批量 固定 inf startup
原文地址:https://www.cnblogs.com/iFanLiwei/p/12898024.html