昨天(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)来保证选举的有效性。
实现步骤
-
初始配置
-
故障切换与维护流程
数据一致性影响
- 在此方案中,主备切换可能存在短暂的写入中断,特别是在Primary节点发生故障时,需要等待选举完成。
- 若在Secondary节点成为新的Primary期间,未及时同步的数据可能会导致数据一致性风险,具体取决于复制滞后的程度和写入操作量。
客户端连接
客户端连接时需要使用副本集连接字符串,确保在Primary节点切换时能够自动连接新的Primary:
方案二:基于priority
的自动主备切换
部署拓扑结构
与方案一类似,方案二也依赖于两台服务器,但通过设置不同的priority
来实现自动化的主备角色管理。
实现步骤
-
配置优先级
-
故障恢复与抢占
数据一致性影响
- 通过自动优先级切换,方案二能够更快响应主备角色的变化,减少切换过程中的写入中断。
- 若发生网络分区或短暂故障,可能会导致短暂的"脑裂"风险。通过配置Arbiter节点,该风险可以得到一定程度的缓解。
- 自动抢占可能引发短暂的切换过程,尤其是在较高负载下时,需要注意数据的一致性和写入冲突的处理。
客户端连接
客户端连接时也应使用副本集连接字符串,确保自动连接当前的Primary节点:
方案对比
比较项 | 方案一:手动主备切换 | 方案二:基于priority 的自动主备切换 |
---|---|---|
实现复杂度 | 较高,需要手动干预和配置 | 较低,配置完成后自动处理 |
主备切换响应速度 | 需要一定的手动干预时间 | 自动响应,通常较快 |
灵活性 | 较高,可以控制主备角色转换的时机 | 灵活性相对较低,但自动化程度高 |
维护成本 | 需要手动操作和关注角色切换 | 自动维护成本较低 |
适用场景 | 需要较强的角色控制时,例如关键业务维护期间 | 适用于高可用和快速故障切换的场景 |
与三台设备组成的副本集对比
在标准的三节点副本集架构中,通常由一个Primary节点和两个Secondary节点组成,无需额外的Arbiter来参与投票,具备更好的高可用性和数据一致性保障。
三节点副本集的优势
-
更高的数据一致性
- 数据在三节点中分布复制,出现节点故障时,仍能确保数据存在于至少两个节点上,从而减少数据丢失的风险。
- 不同于两节点加Arbiter的方案,三节点架构能够更好地应对网络分区问题,降低“脑裂”风险。
-
自动化程度更高
- 无需额外配置投票节点,节点之间的选举更加自然。
- 主备切换流程中断更短,因三个节点始终存在一个备用Secondary作为下一任Primary候选。
-
扩展性更好
- 在需要进一步扩展时,三节点副本集更容易增加节点,提升整体性能和可靠性。
两节点方案的局限性
- 高可用性略低:由于仅有一个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")