一日三省吾身

博客园 首页 联系 订阅 管理

1>、同步:复制用于在多台服务器之间备份数据。mongodb的复制功能是使用日志oplog实现的,操作日志包含了主节点的每一次写操作。oplog是主节点的local数据库中的一个固定集合。备份节点通过查询这个集合就可以知道需要进行复制的操作。每个备份节点都维护着自己的oplog,记录着每一次从主节点复制数据的操作,这样每个成员都可以作为同步源提供给其他成员使用。备份节点从当前使用的同步源中获取需要执行的操作,然后在自己的数据集上执行这些操作,最后再将这些操作写入自己的oplog。如果遇到某个操作失败的情况,那么备份节点就会停止从当前的同步源复制数据。如果某个备份节点由于某些原因挂掉了,当它重新启动之后,就会自动从oplog中最后一个操作开始进行同步,由于复制操作的过程是先复制数据再写入oplog,所以,备份节点可能会在已经同步过的数据上再次执行复制操作,mongodb中将oplog中的同一个操作执行多次,与只执行一次的效果是一样的。由于oplog是一个固定集合,所以它的大小是固定的,他只能保存特定数量的操作日志。~1、初始化同步:副本集中的成员启动之后,就会检查自身状态,确定是否可以从某个成员那里进行同步。如果不行的话,它会尝试从副本的另一个成员那里进行完整的数据复制,这个过程就是初始化同步(intiial syncing),有如下几步:(1)首先,选择一个成员作为同步源,在local.me中为自己创建一个标识符,删除所有已存在的数据库,以一个全新的状态开始进行同步。注意:在这个过程中,所有现有的数据都会被删除,应该只在不需要保留现有数据的情况下做初始化同步。(2)克隆(cloing),将同步源的所有记录全部复制到本地。(3)进入oplog同步的第一步,克隆过程中的所有操作都会被记录到oplog中。如果有文档在克隆过程中被移动了,就可能会被遗漏,导致没有被克隆,对于这样的文档,可能需要重新进行克隆。(4)oplog同步过程的第二步,用于将第一个oplog同步中的操作记录下来。(5)创建索引,之前几步将本地的数据与主节点在某个时间的数据集完全一致了,可以开始创建索引了,如果集合比较大,或者要创建的索引比较多,这个过程会很耗时。(6)如果当前节点的数据仍然远远落后于同步源,那么oplog同步过程的最后一步就是将创建索引期间的所有操作全部同步过来,防止该成员成为备份节点。从操作这的角度来说,初始化同步是非常简单的:使用空的数据目录启动mongodb即可。但是,更多时候可能需要从备份中恢复而不是进行初始化同步,从备份中恢复的速度比使用mongodb复制全部数据的速度快得多。~2、处理陈旧数据:如果备份节点远远落后于同步源当前的操作,那么这个备份节点就是陈旧的。当一个备份节点陈旧之后,它会查看副本集中的其他成员,如果某个成员的oplog足够详尽,可以用于处理那些落下的操作,就从这个成员进行同步。如果任何一个成员的oplog都没有参考价值,那么这个成员上的复制操作就会中止,这个成员需要重新进行完全同步(或者是从最近的备份中恢复)。为了避免陈旧备份节点的出现,让主节点使用比较大的oplog保存足够多的操作日志非常重要。

2>、心跳:每个成员都需要知道其他成员的状态:那个是主节点?哪个可以作为同步源?哪个挂掉了?为了维护集合的最新视图,每个成员每个两秒就会向其他成员发送一个心跳请求(heartbeat request)。心跳请求的信息量非常小,用于检查每个成员的状态。成员状态:各个成员会通过心跳将自己的当前状态告诉其他成员。*STARTUP:成员刚启动时处于这个状态。在这个状态下,mongodb会尝试加载成员的副本集配置,配置加载成功之后,就进入STARTUP2状态。*STARTUP2:整个初始化同步过程都处于这个状态,但是如果是在普通成员上,这个状态只会持续几秒钟,在这个状态下,mongodb会创建几个线程,用于处理复制和选举,然后就会切换到RECOVERING状态。*RECOVERING:这个状态表明成员运转正常,但是暂时还不能处理读取请求。启动时,成员需要做一些检查以确保自己处于有效状态,之后才可以处理读取请求。再启动过程中,成为备份节点之前,每个成员都要经历RECOVERING状态。在处理非常耗时的操作时,成员也可能进入RECOVERING状态。当一个成员与其他成员脱节时,也会进入RECOVERING状态。*ARBITER:在正常的操作中,仲裁者应该始终处于ARBITER状态。*DOWN:如果一个正常运行的成员变得不可达,他就处于DOWN状态。如果有成员被报告为DOWN状态,它有可能仍然处于正常运行状态,不可达的原因可能是网络问题。*UNKNOWN:如果一个成员无法到达其他任何成员,其他成员就无法知道它处于什么状态,会将其报告为UNKNOWN状态。*REMOVED:当成员被移出副本集时,它就处于这个状态,如果被移出的成员又被重新添加到副本集中,它就会回到“正常”状态。*ROLLBACK:如果成员正在进行数据回滚,它就处于ROLLBACK状态。回滚过程结束时,服务器会转换为RECOVERING状态,然后成为备份节点。*FATAL:如果一个成员发生了不可挽回的错误,也不再尝试恢复正常的话,它就处于FATAL状态。

3>、选举:当一个成员无法到达主节点时,它就会申请被选举为主节点,希望被选举为主节点的成员,会向它能到达的所有成员发送通知。如果这个成员得到副本集中“大多数”赞成票,它就选举成功,会转换到主节点状态。如果达不到“大多数”的要求,那么选举失败,它仍然处于备份节点状态,之后还可以再次申请被选举为主节点。主节点会一直处于主节点状态,除非它由于不再满足“大多数”的要求或者挂了而退位,另外,副本集被重新配置也会导致主节点退位。如果主节点不可用,2秒钟(心跳的间隔是2秒)之内就会有成员发现这个问题,然后会立即开始选举,整个过程只会花费几毫秒。如果网络问题,或者是服务器过载导致响应缓慢,都可能触发选举,在这种情况下,心跳会在最多20秒之后超时,如果选举打成平局,每个成员都需要等待30秒才能开始下一次选举。

 

posted on 2017-01-11 16:58  一日三省吾身  阅读(146)  评论(0编辑  收藏  举报