MongoDB副本集功能及节点属性梳理

副本集的主要功能

副本集是MongoDB高可用的基础,其主要作用 归纳为以下几点:

(1)高可用,防止设备(服务器、网络)故障。提供自动FailOver功能。

(2)无需配置高可用性虚拟节点;无论是SQL Server 的AlwaysOn 还是 MySQL 的 MHA方案 都需要有可用性组 或集群的虚拟IP,要求程序连接使用这个虚拟IP。但是MongoDB 副本集不需要  配置虚拟IP,而是当我们在连接字符串中指定replicaSet 参数设置 后,会自动识别查找master节点。这样 可以省去 DBA 对虚拟高可用IP的配置和管理。另外,还有一点 可以保证  主节点、辅助节点切换 对程序的影响,比如丢数据的影响。就是 程序驱动到每个几点都预先建立了一个连接,这个连接 会实时监控节点状态。当主节点切换时,会很快就识别出,这种机制保证了切换对程序的影响。

(3)灾难恢复,当发生故障时,可以从其它节点快速恢复。

(4)功能隔离,用于分析、报表,数据挖掘,系统任务等。用于备份。

副本集节点属性介绍

复制集成员最多50个。参与Primary选举投票的成员最多7个,其他成员的votes属性必须设置为0,即不参与投票。

下面我们对副本集的节点做下梳理。

一般而言,副本集节点有3中类型,主节点(Primary)、辅助节点(Secondary)、见证节点(Arbiter)。

主节点(Primary)

这个节点也比较容易理解。和其他数据库上的主节点一样,可以提供读写。再次不再赘述。

见证节点(Arbiter

没有数据副本,不会成为Primary节点,主要用来选举投票。

当副本集的节点数据为偶数时,可以考虑添加一个见证节点。

见证节点因为没有数据,只是投票,所以见证节点需要的资源很小,可以和其他应用公用一台服务器,但是不建议将见证节点部署在副本集的主节点或辅助节点节点上。

辅助节点(Secondary)

辅助节点也基本上和其他类型数据库的辅助节点一样,可以充当备胎。我们在此主要讲一讲 辅助节点可以设置的几个属性。

设置为优先级为0的节点

优先级为0的节点的特点

1)不会升级为主节点。但是却可以投票。

2)此节点正常参与Primary产生的oplog的读取,进行数据备份和命令执行。

3)此节点可正常参与客户端对于数据的读取,进行担当负载均衡的工作。

4)在write concern 设置中,此节点是可见的,在决定w : <number>.时,是有用节点。与属性votes =0 不同。

Priority=0在mongoDB中的解释就是一个Standby,可投票不可参选,又干活又负载。对于Priority为0节点的情况,通常作为一个standby,或由于硬件配置较差,设置为0以使用不可能成为主。

此节点在数据多中心时很有用。可以将异地的数据节点添加这种属性。

隐藏节点(Hidden

字面上来说,隐藏。这个隐藏式对客户端的隐藏,客户端如果要读取Secondary的数据,永远无法读取Hidden节点的数据,因为设置了Hidden的这个节点对于客户端是透明的,不可见。但是,对于自己的Secondary的群体和Primary来说都是可见的,所以,Hidden依然可以投票,依然要按照oplog进行命令的复制,只是,不参与负载了。

Hidden属性的前提是必须是一个Priority=0的节点,所以会具备一些优先级=0的特点。

1)Hidden节点不能被选为主(Priority为0),并且对Driver不可见。

2)但在Hidden节点上,可做一些数据备份、离线计算的任务,不会影响复制集的服务

3)隐藏节点成员建议总是将其优先级设置为0(priority 0)

4)由于对Driver不可见,因此不会作为read preference节点,隐藏节点可以作为投票节点

5)在分片集群当中,mongos不会同隐藏节点交互。

延迟节点(Delayed

延迟比较容易理解,代表此节点的数据与Primary的数据有一定的迟延,通过设定一个迟延的属性来确定。

1)此节点必须是一个Priority=0且为Hidden的节点。

2)此节点虽然又迟延又Hidden,但是还是可以投票。

3)延迟单位设置为秒。

节点属性如下:

{
   "_id" : <num>,
   "host" : <hostname:port>,
   "priority" : 0,
   "slaveDelay" : <seconds>,
   "hidden" : true
}

非投票节点(votes:0)

我们在前面已经接受了,一个副本集最多有7个投票节点,如果还有其它的节点,需要设置为非投票节点。

非投票节点拥有数据副本,但是不参与投票。另外,非投票节点,其 priority 必须设置为 0。

原文地址:https://www.cnblogs.com/xuliuzai/p/9683889.html

时间: 2024-07-30 06:37:32

MongoDB副本集功能及节点属性梳理的相关文章

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是一种非关系数据库(NoSQL),非关系型数据库的产生就是为了解决大数据量.高扩展性.高性能.灵活数据模型.高可用性.MongoDB官方已经不建议使用主从模式了,替代方案是采用副本集的模式.主从模式其实就是一个单副本的应用,没有很好的扩展性和容错性,而Mongodb副本集具有多个副本保证了容错性,就算一个副本挂掉了还有很多副本存在,主节点挂掉后,整个集群内会实现自动切换. Mongodb副本集的工作原理客户端连接到整个Mongodb副本集,不关心具体哪一台节点机是否挂掉.主节点机负

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

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

MongoDB副本集运维小结

前面的文章介绍了MongoDB副本集和分片集群的做法,下面对MongoDB集群的日常维护操作进行小总结: MongDB副本集故障转移功能得益于它的选举机制.选举机制采用了Bully算法,可以很方便从分布式节点中选出主节点. Bully算法是一种协调者(主节点)竞选算法,主要思想是集群的每个成员都可以声明它是主节点并通知其他节点.别的节点可以选择接受这个声称或是拒绝并进入主 节点竞争.被其他所有节点接受的节点才能成为主节点.节点按照一些属性来判断谁应该胜出.这个属性可以是一个静态ID,也可以是更新

MongoDB副本集

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

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

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

Mongodb副本集实现

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

mongodb副本集维护

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

mongodb 副本集配置与说明

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