mongodb副本集高可用架构

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
简介: 一、简介Mongodb复制集由一组Mongod实例(进程)组成,包含一个Primary节点和多个Secondary节点。Mongodb Driver(客户端)的所有数据都写入Primary,Secondary从Primary同步写入的数据,以保持复制集内所有成员存储相同的数据集,实现数据的高可用。

一、简介

Mongodb复制集由一组Mongod实例(进程)组成,包含一个Primary节点和多个Secondary节点。
Mongodb Driver(客户端)的所有数据都写入Primary,Secondary从Primary同步写入的数据,以保持复制集内所有成员存储相同的数据集,实现数据的高可用。

使用场景

  • 数据冗余,用做故障恢复使用,当发生硬件故障或者其它原因造成的宕机时,可以使用副本进行恢复。
  • 读写分离,读的请求分流到副本上,减轻主节点的读压力。

一个典型的副本集架构如下图所示:

img_bc97112ee711a4198cc851cc0cdd6de2.png

二、副本集角色

  1. 主节点(Primary)
    接收所有的写请求,然后把修改同步到所有Secondary。一个Replica Set只能有一个Primary节点,当Primary挂掉后,其他Secondary或者Arbiter节点会重新选举出来一个主节点。
    默认读请求也是发到Primary节点处理的,可以通过修改客户端连接配置以支持读取Secondary节点。

  2. 副本节点(Secondary)
    与主节点保持同样的数据集。当主节点挂掉的时候,参与选主。

  3. 仲裁者(Arbiter)
    不保有数据,不参与选主,只进行选主投票。使用Arbiter可以减轻数据存储的硬件需求,Arbiter几乎没什么大的硬件资源需求,但重要的一点是,在生产环境下它和其他数据节点不要部署在同一台机器上。

三、两种架构模式

  1. PSS
    Primary + Secondary + Secondary模式,通过Primary和Secondary搭建的Replica Set
    Diagram of a 3 member replica set that consists of a primary and two secondaries.

img_a44d27f4434768d38b4665f06ae05aa3.png

该模式下 Replica Set节点数必须为奇数,目的是选主投票的时候要出现大多数才能进行选主决策。

  1. PSA
    Primary + Secondary + Arbiter模式,使用Arbiter搭建Replica Set

img_8918add2e744a5a15460474583015d8a.png

偶数个数据节点,加一个Arbiter构成的Replica Set

四、选举机制

复制集通过 replSetInitiate 命令或 rs.initiate() 命令进行初始化。
初始化后各个成员间开始发送心跳消息,并发起 Primary 选举操作,获得大多数成员投票支持的节点,会成为 Primary,其余节点成为 Secondary。

config = {
    _id : "my_replica_set",
    members : [
        {_id : 0, host : "rs1.example.net:27017"},
        {_id : 1, host : "rs2.example.net:27017"},
        {_id : 2, host : "rs3.example.net:27017"},
  ]
}
rs.initiate(config)

大多数
假设复制集内投票成员(后续介绍)数量为 N,则大多数为 N/2 + 1,当复制集内存活成员数量不足大多数时,整个复制集将无法选举出 Primary,复制集将无法提供写服务,处于只读状态。
关于大多数的计算如下表所示

投票成员数 大多数 容忍失效数
1 1 0
2 2 0
3 2 1
4 3 1
5 3 2

Mongodb副本集的选举基于Bully算法,这是一种协调者竞选算法,详细解析可以参考这里
Primary 的选举受节点间心跳、优先级、最新的 oplog 时间等多种因素影响。官方文档对于选举机制的说明

特殊角色

  • Arbiter
    Arbiter 节点只参与投票,不能被选为 Primary,并且不从 Primary 同步数据。
    当节点宕机导致复制集无法选出 Primary时,可以给复制集添加一个 Arbiter 节点,即使有节点宕机,仍能选出 Primary。
    Arbiter 本身不存储数据,是非常轻量级的服务,当复制集成员为偶数时,最好加入一个 Arbiter 节点,以提升复制集可用性。

  • Priority0
    Priority0节点的选举优先级为0,不会被选举为 Primary。
    比如你跨机房 A、B 部署了一个复制集,并且想指定 Primary 必须在 A 机房,这时可以将 B 机房的复制集成员 Priority 设置为0,这样 Primary 就一定会是 A 机房的成员。
    (注意:如果这样部署,最好将大多数节点部署在 A 机房,否则网络分区时可能无法选出 Primary。)

  • Vote0
    Mongodb 3.0里,复制集成员最多50个,参与 Primary 选举投票的成员最多7个,其他成员(Vote0)的 vote 属性必须设置为0,即不参与投票。

  • Hidden
    Hidden 节点不能被选为主(Priority 为0),并且对 Driver 不可见。
    因 Hidden 节点不会接受 Driver 的请求,可使用 Hidden 节点做一些数据备份、离线计算的任务,不会影响复制集的服务。

  • Delayed
    Delayed 节点必须是 Hidden 节点,并且其数据落后与 Primary 一段时间(可配置,比如1个小时)。
    因 Delayed 节点的数据比 Primary 落后一段时间,当错误或者无效的数据写入 Primary 时,可通过 Delayed 节点的数据来恢复到之前的时间点。

触发选举条件

  • 初始化一个副本集时。
  • 从库不能连接到主库(默认超过10s,可通过heartbeatTimeoutSecs参数控制),由从库发起选举
  • 主库放弃primary 角色,比如执行rs.stepdown 命令

Mongodb副本集通过心跳检测实现自动failover机制,进而实现高可用
img_e46833c055f843c4332f95b904eb90be.png

五、数据同步

Primary 与 Secondary 之间通过 oplog 来同步数据,Primary 上的写操作完成后,会向特殊的 local.oplog.rs 特殊集合写入一条 oplog,Secondary 不断的从 Primary 取新的 oplog 并应用。
因 oplog 的数据会不断增加,local.oplog.rs 被设置成为一个 capped 集合,当容量达到配置上限时,会将最旧的数据删除掉。
另外考虑到 oplog 在 Secondary 上可能重复应用,oplog 必须具有幂等性,即重复应用也会得到相同的结果。
如下 oplog 的格式,包含 ts、h、op、ns、o 等字段。

{
"ts" : Timestamp(1446011584, 2),
"h" : NumberLong("1687359108795812092"),
"v" : 2,
"op" : "i",
"ns" : "test.nosql",
"o" : { "_id" : ObjectId("563062c0b085733f34ab4129"), "name" : "mongodb", "score" : "100" }
}
属性 说明
ts 操作时间,当前 timestamp + 计数器,计数器每秒都被重置
h 操作的全局唯一标识
v oplog 版本信息
op 操作类型
op.i 插入操作
op.u 更新操作
op.d 删除操作
op.c 执行命令(如 createDatabase,dropDatabase)
op.n 空操作,特殊用途
ns 操作针对的集合
o 操作内容
o2 操作查询条件,仅 update 操作包含该字段。

Secondary 初次同步数据时,会先执行 init sync,从 Primary(或其他数据更新的 Secondary)同步全量数据,
然后不断通过执行tailable cursor从 Primary 的 local.oplog.rs 集合里查询最新的 oplog 并应用到自身。

异常回滚
当 Primary 宕机时,如果有数据未同步到 Secondary,当 Primary 重新加入时,如果新的 Primary 上已经发生了写操作,则旧 Primary 需要回滚部分操作,以保证数据集与新的 Primary 一致。
旧 Primary 将回滚的数据写到单独的 rollback 目录下,数据库管理员可根据需要使用 mongorestore 进行恢复

六、读写配置

Read Preference
默认情况下,复制集的所有读请求都发到 Primary,Driver 可通过设置 Read Preference 来将读请求路由到其他的节点。

  • primary:默认规则,所有读请求发到 Primary;
  • primaryPreferred:Primary 优先,如果 Primary 不可达,请求 Secondary;
  • secondary:所有的读请求都发到 secondary;
  • secondaryPreferred:Secondary 优先,当所有 Secondary 不可达时,请求 Primary;
  • nearest:读请求发送到最近的可达节点上(通过 ping 探测得出最近的节点)。
    关于read-preference

Write Concern
默认情况下,Primary 完成写操作即返回,Driver 可通过设置 Write Concern (参见这里)来设置写成功的规则。

如下的 write concern 规则设置写必须在大多数节点上成功,超时时间为5s。

db.products.insert(
  { item: "envelopes", qty : 100, type: "Clasp" },
  { writeConcern: { w: majority, wtimeout: 5000 } }
)

关于write-concern

参考文档

搭建高可用mongodb集群
http://www.lanceyan.com/tech/mongodb_repset2.html

深入浅出Mongodb复制
http://www.mongoing.com/archives/5200

mongodb副本集原理
https://yq.aliyun.com/articles/64?spm=0.0.0.0.9jrPm8

副本集主备切换
https://docs.mongodb.com/manual/tutorial/force-member-to-be-primary/index.html

img_9b09a36f6de95886f52ce82fa1e89c88.jpe

作者: zale

出处: http://www.cnblogs.com/littleatp/, 如果喜欢我的文章,请关注我的公众号

本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出 原文链接  如有问题, 可留言咨询.

相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识,包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用(唯一索引、地理索引、过期索引、全文索引等)、MapReduce操作实现、用户管理、Java对MongoDB的操作支持(基于2.x驱动与3.x驱动的完全讲解)。 通过学习此课程,读者将具备MongoDB数据库的开发能力,并且能够使用MongoDB进行项目开发。   相关的阿里云产品:云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构,具备安全审计,时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版(ApsaraDB for MongoDB)完全兼容MongoDB协议,基于飞天分布式系统和高可靠存储引擎,提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
目录
相关文章
|
1月前
|
存储 SQL 关系型数据库
Mysql高可用架构方案
本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。
162 3
Mysql高可用架构方案
|
4月前
|
存储 Cloud Native 关系型数据库
PolarDB 高可用架构设计与实践
【8月更文第27天】 在现代互联网应用中,数据库作为核心的数据存储层,其稳定性和可靠性尤为重要。阿里云的 PolarDB 作为一款云原生的关系型数据库服务,提供了高可用、高性能和自动化的特性,适用于各种规模的应用。本文将详细介绍 PolarDB 的高可用架构设计,并探讨其实现数据安全性和业务连续性的关键技术。
119 0
|
1月前
|
NoSQL 容灾 MongoDB
MongoDB主备副本集方案:两台服务器使用非对称部署的方式实现高可用与容灾备份
在资源受限的情况下,为了实现MongoDB的高可用性,本文探讨了两种在两台服务器上部署MongoDB的方案。方案一是通过主备身份轮换,即一台服务器作为主节点,另一台同时部署备节点和仲裁节点;方案二是利用`priority`设置实现自动主备切换。两者相比,方案二自动化程度更高,适合追求快速故障恢复的场景,而方案一则提供了更多的手动控制选项。文章最后对比了这两种方案与标准三节点副本集的优缺点,指出三节点方案在高可用性和数据一致性方面表现更佳。
|
2月前
|
存储 NoSQL MongoDB
MongoDB 复制(副本集)
10月更文挑战第17天
46 2
MongoDB 复制(副本集)
|
1月前
|
Kubernetes 关系型数据库 MySQL
Kubernetes入门:搭建高可用微服务架构
【10月更文挑战第25天】在快速发展的云计算时代,微服务架构因其灵活性和可扩展性备受青睐。本文通过一个案例分析,展示了如何使用Kubernetes将传统Java Web应用迁移到Kubernetes平台并改造成微服务架构。通过定义Kubernetes服务、创建MySQL的Deployment/RC、改造Web应用以及部署Web应用,最终实现了高可用的微服务架构。Kubernetes不仅提供了服务发现和负载均衡的能力,还通过各种资源管理工具,提升了系统的可扩展性和容错性。
122 3
|
1月前
|
存储 NoSQL MongoDB
【赵渝强老师】MongoDB复制集的体系架构
MongoDB的复制集是一种集群技术,由一个Primary节点和多个Secondary节点组成,实现数据的高可用性。Primary节点处理写入请求,Secondary节点同步数据。当Primary节点故障时,Secondary节点可通过选举成为新的Primary节点。视频讲解和示意图详见正文。
|
3月前
|
存储 NoSQL Shell
MongoDB复制(副本集)总结
这篇文章是关于MongoDB副本集的总结,包括复制原理、设置副本集、案例分析等内容。
50 1
|
2月前
|
NoSQL MongoDB Docker
求助,有没有大神可以找到arm64架构下mongodb的3.6.8版本的docker镜像?
在Docker Hub受限的情况下,寻求适用于ARM架构的docker镜像资源或拉取链接,以便在x86架构上获取;内网中的机器为ARM架构,因此优先请求适合ARM的Docker镜像或Dockerfile,非常感激您的帮助。
|
4月前
|
运维 监控 关系型数据库
【一文搞懂PGSQL】7. PostgreSQL + repmgr + witness 高可用架构
该文档介绍了如何构建基于PostgreSQL的高可用架构,利用repmgr进行集群管理和故障转移,并引入witness节点增强网络故障检测能力。repmgr是一款轻量级的开源工具,支持一键部署、自动故障转移及分布式节点管理。文档详细描述了环境搭建步骤,包括配置postgresql参数、安装与配置repmgr、注册集群节点以及配置witness节点等。此外,还提供了故障手动与自动切换的方法及常用命令,确保集群稳定运行。
|
4月前
|
数据挖掘 关系型数据库 MySQL
Serverless高可用架构的解决方案体验
Serverless高可用架构的解决方案体验
167 6