MongoDB主备副本集方案:两台服务器使用非对称部署的方式实现高可用与容灾备份

server/2024/11/24 4:21:42/

昨天(2024/11/18)碰到这么个问题,因为要控制成本,公司只愿意出两台服务器(很小的盒子)部署业务,采用传统的主备模式。这其中就包括Mongodb数据库,最稳固的方法当然是采用官方推荐的最低3台。但没办法,只能是模拟部署了。

选举机制踩坑-必须获得超过半数票

一开始冒出来的想法是各部署两个mongodb节点**(2+2)**,这样挂掉还有一半,但是实测不会进行选举,集群会卡住不可用!

后来我想,是不是因为偶数的原因,试了下**(3+3)**,结果还是不可用。因为我问gpt说是获得的票数是 votes > ceil(total/2),被个ceil给坑了。因为按照这个设定,我以为是>=,不然3个节点挂一个就应该不可用。

实际上只要超过半数就可以,奇数的不会出现对等,所以更好控制!
另外三节点,挂掉一个后,rs.status() 会出现错误 : Error: Invalid UTF-8 string in BSON document

方案一:主备身份轮换

部署拓扑结构

在方案一中,我们使用两台服务器,部署一个主实例(Primary)和一个备用实例(Secondary),并额外配置一个投票节点(Arbiter)来保证选举的有效性。

服务器A - MongoDB Primary
服务器B - MongoDB Secondary
服务器B - Arbiter

实现步骤

  1. 初始配置

    • 服务器A上的MongoDB实例被设置为Primary节点。
    • 服务器B上的MongoDB实例被配置为Secondary,并在服务器B上额外部署一个Arbiter实例,用于选举。
    • 副本集初始化完成后,服务器A作为Primary处理所有写操作,服务器B作为Secondary提供读操作(如果配置为允许读操作)。
  2. 故障切换与维护流程

    • 故障切换:当Primary节点(服务器A)发生故障时,备用服务器B发起选举,获得自身和Arbiter的投票,从而成为新的Primary。
    • 维护切换:在需要手动切换主备角色时,可以先停止服务器A,将服务器B设置为Primary并确保其稳定运行,随后启动服务器A作为新的Secondary节点,并重新配置副本集。

数据一致性影响

  • 在此方案中,主备切换可能存在短暂的写入中断,特别是在Primary节点发生故障时,需要等待选举完成。
  • 若在Secondary节点成为新的Primary期间,未及时同步的数据可能会导致数据一致性风险,具体取决于复制滞后的程度和写入操作量。

客户端连接

客户端连接时需要使用副本集连接字符串,确保在Primary节点切换时能够自动连接新的Primary:

客户端
服务器A - MongoDB Primary
服务器B - MongoDB Secondary

方案二:基于priority的自动主备切换

部署拓扑结构

与方案一类似,方案二也依赖于两台服务器,但通过设置不同的priority来实现自动化的主备角色管理。

服务器A - MongoDB Primary, Priority高
服务器B - MongoDB Secondary, Priority低
服务器B - Arbiter

实现步骤

  1. 配置优先级

    • 服务器A的priority值设置较高,确保在正常运行时始终担任Primary节点。
    • 服务器B的priority值设置较低,通常作为Secondary节点,但在Primary发生故障时会自动升级为Primary。
  2. 故障恢复与抢占

    • 服务器A发生故障,备用服务器B会自动成为Primary节点,继续处理写入请求。
    • 服务器A恢复并重新加入副本集后,由于其priority值较高,会自动抢占Primary角色,恢复为主服务器

数据一致性影响

  • 通过自动优先级切换,方案二能够更快响应主备角色的变化,减少切换过程中的写入中断。
  • 若发生网络分区或短暂故障,可能会导致短暂的"脑裂"风险。通过配置Arbiter节点,该风险可以得到一定程度的缓解。
  • 自动抢占可能引发短暂的切换过程,尤其是在较高负载下时,需要注意数据的一致性和写入冲突的处理。

客户端连接

客户端连接时也应使用副本集连接字符串,确保自动连接当前的Primary节点:

客户端
服务器A - MongoDB Primary, Priority高
服务器B - MongoDB Secondary, Priority低

方案对比

比较项方案一:手动主备切换方案二:基于priority的自动主备切换
实现复杂度较高,需要手动干预和配置较低,配置完成后自动处理
主备切换响应速度需要一定的手动干预时间自动响应,通常较快
灵活性较高,可以控制主备角色转换的时机灵活性相对较低,但自动化程度高
维护成本需要手动操作和关注角色切换自动维护成本较低
适用场景需要较强的角色控制时,例如关键业务维护期间适用于高可用和快速故障切换的场景

与三台设备组成的副本集对比

在标准的三节点副本集架构中,通常由一个Primary节点和两个Secondary节点组成,无需额外的Arbiter来参与投票,具备更好的高可用性和数据一致性保障。

三节点副本集的优势

  1. 更高的数据一致性

    • 数据在三节点中分布复制,出现节点故障时,仍能确保数据存在于至少两个节点上,从而减少数据丢失的风险。
    • 不同于两节点加Arbiter的方案,三节点架构能够更好地应对网络分区问题,降低“脑裂”风险。
  2. 自动化程度更高

    • 无需额外配置投票节点,节点之间的选举更加自然。
    • 主备切换流程中断更短,因三个节点始终存在一个备用Secondary作为下一任Primary候选。
  3. 扩展性更好

    • 在需要进一步扩展时,三节点副本集更容易增加节点,提升整体性能和可靠性。

两节点方案的局限性

  • 高可用性略低:由于仅有一个Secondary节点,任意节点故障都会显著影响集群的可用性。
  • 选举机制更复杂:需要通过Arbiter来确保选举票数多数,不如三节点架构直接稳定。
  • 维护复杂度更高:在进行角色切换时,需要手动操作或依赖于不同的priority配置,增加维护成本。

结论

  • 方案一适合需要更严格控制主备切换时机的场景,能够手动调整和维护,但维护成本较高。
  • 方案二通过priority实现自动切换,适合追求高可用性和快速故障响应的场景,但需要额外注意抢占过程中可能出现的临时一致性问题。
  • 相比于标准的三节点副本集,两节点方案具备一定的局限性和风险,适用于资源有限但需要基本高可用性的环境。三节点方案更为稳健,推荐在资源充足的情况下使用。

通过合理选择和配置,可以实现符合业务需求的MongoDB副本集方案,提高数据库系统的容灾能力和高可用性。

附录 - 启动脚本

说明: mongodb7.0 + windows 环境测试

副本集创建

简单的把数据放在三个目录去

.\mongod.exe --port 27017 --dbpath G:/mongo/node1/data --logpath G:/mongo/node1/log/mongo.log --replSet rs .\mongod.exe  --port 27018 --dbpath G:/mongo/node2/data --logpath G:/mongo/node2/log/mongo.log --replSet rs.\mongod.exe  --port 27019 --dbpath G:/mongo/node3/data --logpath G:/mongo/node3/log/mongo.log --replSet rs

副本集初始化

rs.initiate({_id: "rs",members: [{ _id: 0, host: "localhost:27017" },{ _id: 1, host: "localhost:27019" }]
})

一定概率不让直接加投票节点,需要配置默认writeConcern

db.adminCommand({"setDefaultRWConcern" : 1,"defaultWriteConcern" : {"w" : 1}
})

添加投票节点

rs.addArb("localhost:27018")

http://www.ppmy.cn/server/144433.html

相关文章

网络协议之FTP

一、背景介绍 FTP,全称为文件传输协议(File Transfer Protocol),是一种用于在网络上进行文件传输的协议。它是互联网上最早出现的文件传输标准之一,使用广泛且成熟稳定。FTP协议通过客户端和服务器之间的交互&#xf…

.net6 使用 FreeSpire.XLS 实现 excel 转 pdf - docker 部署

FreeSpire.XLS && Aspose.Cells包都可以实现。实现过程中发现如下问题: 本地测试通过, docker部署服务器后报错: The type initializer for Spire.Xls.Core.Spreadsheet.XlsPageSetupBase threw an exception. 由于缺少依赖&#xf…

区块链安全常见的攻击——不安全的 Delegatecall 漏洞(Unsafe Delegatecall Vulnerability)【3】

区块链安全常见的攻击合约和简单复现,附带详细分析——不安全的 Delegatecall 漏洞(Unsafe Delegatecall Vulnerability)【3】 1、不安全的 Delegatecall 漏洞(Unsafe Delegatecall Vulnerability) 1.1 漏洞合约 co…

aws配置飞书告警通知

serverless 创建应用 在 SAR 中搜索 Feishu-notifier 查到本应用(注意因为本项目会创建 EventBridge 到 SNS Publish 权限,按下图进行勾选 Eventbridge 规则 cloudwatch 告警 {"detail-type": ["CloudWatch Alarm State Change"],…

Unity 事件处理的几种方式

//Unity 事件处理的几种方式 //1 通过编辑器绑定方式 //2:addlistener //3:实现接口 //4:自定义框架 using System; using System.Collections.Generic; using UnityEngine; using UnityEngine.EventSystems;nam…

【人工智能】深入理解PyTorch:从0开始完整教程!全文注解

在当今人工智能和深度学习的浪潮中,PyTorch作为一个灵活且强大的深度学习框架,正受到越来越多开发者和研究者的青睐。无论你是初学者还是经验丰富的开发者,这篇文章将带你深入理解PyTorch,从基础概念到高级应用,帮助你…

Python深度学习环境配置(Pytorch、CUDA、cuDNN),包括Anaconda搭配Pycharm的环境搭建以及基础使用教程(保姆级教程,适合小白、深度学习零基础入门)

全流程导览 一、前言二、基本介绍2.1全过程软件基本介绍2.1.1 Pytorch2.1.2 Anaconda2.1.3 Pycharm2.1.4 显卡GPU及其相关概念2.1.5 CUDA和cuDNN 2.2 各部分相互间的联系和安装逻辑关系 三、Anaconda安装3.1安装Anaconda3.2配置环境变量3.3检验是否安装成功 四、Pycharm安装五、…

网络传输:网卡、IP、网关、子网掩码、MAC、ARP、路由器、NAT、交换机

目录 网卡IP网络地址主机地址子网子网掩码网关默认网关 MACARPARP抓包分析 路由器NATNAPT 交换机 网卡 网卡(Network Interface Card,简称NIC),也称网络适配器。 OSI模型: 1、网卡工作在OSI模型的最后两层,物理层和数据链路层。物…