MongoDB副本集的组成

，操作日志包含了主节点的每一次写操作。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秒才能开始下一次选举。

 

MongoDB副本集的组成

标签：不可用   操作日志   cin   初始化   最新   color   间隔   读取   应该