昨天（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）和一个Arbiter实例
graph LR A[服务器A - MongoDB Primary] --> B[服务器B - MongoDB Secondary] B --> C[服务器B - Arbiter]AI 代码解读
实现步骤
初始配置
- 服务器A上的MongoDB实例被设置为Primary节点。
- 服务器B上的MongoDB实例被配置为Secondary，并在服务器B上额外部署一个Arbiter实例，用于选举。
- 副本集初始化完成后，服务器A作为Primary处理所有写操作，服务器B作为Secondary提供读操作（如果配置为允许读操作）。
故障切换与维护流程
- 故障切换：当Primary节点（服务器A）发生故障时，备用服务器B发起选举，获得自身和Arbiter的投票，从而成为新的Primary。
- 维护切换：在需要手动切换主备角色时，可以先停止服务器A，将服务器B设置为Primary并确保其稳定运行，随后启动服务器A作为新的Secondary节点，并重新配置副本集。
数据一致性影响
- 在此方案中，主备切换可能存在短暂的写入中断，特别是在Primary节点发生故障时，需要等待选举完成。
- 若在Secondary节点成为新的Primary期间，未及时同步的数据可能会导致数据一致性风险，具体取决于复制滞后的程度和写入操作量。
客户端连接
客户端连接时需要使用副本集连接字符串，确保在Primary节点切换时能够自动连接新的Primary：
graph LR Client[客户端] --> A[服务器A - MongoDB Primary] Client --> B[服务器B - MongoDB Secondary]AI 代码解读
方案二：基于priority的自动主备切换
部署拓扑结构
与方案一类似，方案二也依赖于两台服务器，但通过设置不同的priority来实现自动化的主备角色管理。
- 服务器A（主服务器）：Primary节点，配置较高的
priority - 服务器B（备用服务器）：Secondary节点，配置较低的
priority，并包含一个Arbiter节点
graph LR A[服务器A - MongoDB Primary, Priority高] --> B[服务器B - MongoDB Secondary, Priority低] B --> C[服务器B - Arbiter]AI 代码解读
实现步骤
配置优先级
- 服务器A的
priority值设置较高，确保在正常运行时始终担任Primary节点。 - 服务器B的
priority值设置较低，通常作为Secondary节点，但在Primary发生故障时会自动升级为Primary。
- 服务器A的
故障恢复与抢占
- 当服务器A发生故障，备用服务器B会自动成为Primary节点，继续处理写入请求。
- 服务器A恢复并重新加入副本集后，由于其
priority值较高，会自动抢占Primary角色，恢复为主服务器。
数据一致性影响
- 通过自动优先级切换，方案二能够更快响应主备角色的变化，减少切换过程中的写入中断。
- 若发生网络分区或短暂故障，可能会导致短暂的"脑裂"风险。通过配置Arbiter节点，该风险可以得到一定程度的缓解。
- 自动抢占可能引发短暂的切换过程，尤其是在较高负载下时，需要注意数据的一致性和写入冲突的处理。
客户端连接
客户端连接时也应使用副本集连接字符串，确保自动连接当前的Primary节点：
graph LR Client[客户端] --> A[服务器A - MongoDB Primary, Priority高] Client --> B[服务器B - MongoDB Secondary, Priority低]AI 代码解读
方案对比
| 比较项 | 方案一：手动主备切换 | 方案二：基于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
AI 代码解读
副本集初始化
rs.initiate({
_id: "rs",
members: [
{ _id: 0, host: "localhost:27017" },
{ _id: 1, host: "localhost:27019" }
]
})
AI 代码解读
一定概率不让直接加投票节点，需要配置默认writeConcern
db.adminCommand({
"setDefaultRWConcern" : 1,
"defaultWriteConcern" : {
"w" : 1
}
})
AI 代码解读
添加投票节点
rs.addArb("localhost:27018")
AI 代码解读
