MongoDB副本集的组成

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秒才能开始下一次选举。

时间: 2024-10-10 14:31:24

MongoDB副本集的组成的相关文章

MongoDB副本集

简介 mongodb复制(replication)是将数据同步在多个服务器的过程.主节点记录在其上的所有操作oplog,从节点定期轮询主节点获取这些操作,然后对自己的数据副本执行这些操作,从而保证从节点的数据与主节点一致.复制提供了数据的冗余备份,并在多个服务器上存储数据副本,提高了数据的可用性,并保证数据的安全性.复制还允许您从硬件故障和服务中断中恢复数据. 而副本集(replica set)是从mongodb 1.6 提供的新功能,比复制功能要强大一些并增加了故障自动切换和自动修复成员节点,

Mongodb副本集实现

MongoDB副本集概述 以下图片摘自MongoDB官方文档:http://docs.mongodb.org/manual/core/replication-introduction/ Primary节点接收客户端所有的写操作,整个副本集只会有一个primary节点.MongoDB副本集提供严格的一致性.主节点将所有的操作写入一个叫oplog的capped collection(这个collection的大小一般为磁盘剩余空间的5%,不同的系统可能不一样,详见http://docs.mongod

zabbix使用Python实现监控MongoDB副本集状态

公司有 Windows 和 Linux 服务器,都搭建了 MongoDB 副本集,并且都要在 zabbix 平台中实现监控.Linux 系统直接使用 shell 脚本即可实现,但是 Windows 系统的不太好实现,我这里使用 Python 来实现.下面脚本同样适用于Linux系统(在 Windows server 2012 和 Centos7.3 系统都验证成功) 思路: 1.安装Python2.7 2.采用 Python 的 pymongo 模块来连接 mongodb 数据库,并认证授权 3

mongodb副本集维护

mongodb副本集维护主要工作: 1.查看副本集状态(集群状态.同步延迟.单个库的运行状态mongostate) 2.增删节点.停节点shutdown mongodb副本集集群同步机制 数据复制的目的是使数据得到最大的可用性,冗余,避免单点故障. 副本集中同一时刻只有一台服务器是可以写的,primary主库上写,从库同步数据 副本集主从复制也是异步同步的过程.slave从primary上获取日志,然后在自己身上完全顺序的执行日志记录的操作(该日志不记录查询操作,只记录更新操作).被同步的日志就

mongodb 副本集配置与说明

1,副本集的原理 副本集的原理与主从很相似,唯一不同的是,在主节点出现故障的时候,主从配置的从服务器不会自动的变为主服务器,而是要通过手动修改配置.但是副表集就不用,它会自动选出一台服务器做为主节点,从而保障系统的稳定性. 2,副本集新的主节点是怎么选举出来的呢 是通过bully算法来的,也就是一致性协议.具体如下 1):当主节点挂了后,副本集会获得其他从节点的最后更新时间与主服务做对比 2):如果所有从节点的最后更新时间都是很旧,那就选举停止 3):如果副本集中的大部分服务器挂了,包含主节点,

Mongodb副本集实现及读写分离

在前面的文章"Mongodb的主从模式搭建实例"中,我们对如何搭建一个主从结构的Mongodb服务器环境进行了简单的介绍.但是对于主从结构,Mongodb官方并不推荐我们使用了,可能是因为主从模式存在以下两个缺点: (1)主节点不可用之后,无法自动切换到从节点,无法确保业务访问的不间断性: (2)所有的读写操作都是对主节点的,造成主节点的访问压力较大: 因此,Mongodb为我们提供了另外一种推荐的使用方法,那就是使用副本集ReplicaSets.在这篇文章中简单描述一下副本集是如何实

MongoDB 副本集(类似高可用) [三]

MongoDB 副本集(类似高可用)1.节点类型standard:常规节点,它存储一份完整的数据副本,参与选举投票,有可能成为活跃节点.passive:存储了完整的数据副本,参与投票,不能成为活跃节点.arbiter:仲裁节点,只参与投票,不接收复制的数据,也不能成为活跃节点.2.参数说明--dbpath   数据文件路径--logpath  日志文件路径--port        端口号,默认是27017.我这里使用的也是这个端口号.--replSet   复制集的名字,一个replica s

mongodb副本集的内部机制(借鉴lanceyan.com)

针对mongodb的内部机制提出以下几个引导性的问题: 副本集故障转移,主节点是如何选举的?能否手动干涉下架某一台主节点. 官方说副本集数量最好是奇数,为什么? mongodb副本集是如何同步的?如果同步不及时会出现什么情况?会不会出现不一致性? mongodb的故障转移会不会无故自动发生?什么条件会触发?频繁触发可能会带来系统负载加重? Bully算法 mongodb副本集故障转移功能得益于它的选举机制.选举机制采用了Bully算法,可以很方便从分布式节点中选出主节点.一个分布式集群架构中一般

MongoDB副本集搭建及备份恢复

一.MongoDB副本集(repl set)介绍 早起版本使用master-slave,一主一从和MySQL类似,但slave在此架构中为只读,当主库宕机后,从库不能自动切换为主: 目前已经淘汰了master-slave模式,改为副本集,这种模式下有一个主(primary),和多个从(secondary),只读,支持给他们设置权重,当主宕掉后,权重最高的从切换为主: 在此架构中还可以建立一个仲裁(arbiter)的角色,它只负责裁决,而不存储数据 在此架构中读写数据都是在主上,要想实现负载均衡的

java程序连接MongoDB副本集测试

三个节点有一个节点挂掉也不会影响应用程序客户端对整个副本集的读写! [java] view plaincopy public class TestMongoDBReplSet { public static void main(String[] args) { try { List<ServerAddress> addresses = new ArrayList<ServerAddress>(); ServerAddress address1 = new ServerAddress