转 Warning:MongoDB Replica Sets配置注意事项

最新推荐文章于 2025-08-22 11:10:38 发布

weixin_30826095

最新推荐文章于 2025-08-22 11:10:38 发布

阅读量101

点赞数

CC 4.0 BY-SA版权

文章标签：数据库

原文链接：http://www.cnblogs.com/sidesky/p/3235049.html

本文详细阐述了MongoDB在集群中Secondary节点宕机时Primary节点的行为及其背后的选举策略，解释了为何会发生Primary立即变为Secondary的情况，并提出了添加更多节点或引入arbiter节点作为改进措施，以确保集群的稳定性和Primary选举的高效性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

我们知道，MongoDB不提供单机的数据安全性，取而代之的是提供了Replica Sets的高可用方案。官方文档中提到的案例是三个节点组成的Replica Sets，这样在其中任何一个节点宕机后都会自动选举出新的Primary提供写操作。而下面要提到的是一个大家可能忽略的问题。

配置方法

两个节点的Replica Sets，启动后一个选举成为Primary，一个成为Secondary。

问题

这时候如果Secondary宕机，那么Primary会怎么样呢？Primary会立刻变成Secondary！这时候集群里没有Primary了！为什么会出现这样的情况呢。

原因

这是和MongoDB的Primary选举策略有关的，试想如果情况不是Secondary宕机，而是网络断开，那么两个节点都会选取自己为Primary，因为他们能连接上的只有自己这一个节点。而这样的情况在网络恢复后就需要处理复杂的一致性问题。而且断开的时间越长，时间越复杂。所以MongoDB选择的策略是如果集群中只有自己一个节点，那么不选取自己为Primary。

解决方法

所以正确的做法应该是添加两个以上的节点，或者添加arbiter，当然最好也最方便的做法是添加arbiter，aribiter节点只参与选举，几乎不会有压力，所以你可以在各种闲置机器上启动arbiter节点，这不仅会避免上面说到的无法选举Primary的情况，更会让选取更快速的进行。（因为如果是三台数据节点，一个节点宕机，另外两个节点很可能会各自选举自己为Primary，从而导致很长时间才能得出选举结果）

转载于:https://www.cnblogs.com/sidesky/p/3235049.html