昨天（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实例

实现步骤

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：

---

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

部署拓扑结构

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

• 服务器A（主服务器）：Primary节点，配置较高的priority
• 服务器B（备用服务器）：Secondary节点，配置较低的priority，并包含一个Arbiter节点

实现步骤

1. 配置优先级

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

2. 故障恢复与抢占

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

数据一致性影响

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

客户端连接

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

方案对比

比较项	方案一：手动主备切换	方案二：基于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")