我创建了一个 3 成员副本集，因此我可以使用其中一个成员进行读取操作，而不会干扰主数据库性能。
为了实现这一点，主数据库系统被配置为主要数据库系统，另一个是优先级为 0 的辅助数据库系统，以便在发生中断时不会接管主要角色，第三个是仲裁器，以帮助打破每个数据库的平局MongoDB对成员数量为奇数的要求。
在玩这个设置时，我注意到如果我杀死了仲裁者和我的次要成员，则主要成员将成为次要成员。这将影响主数据库的读写访问，因为它的角色已经改变。要解决此问题，我必须重新启动主数据库并将其从副本集中删除，直到我的辅助数据库和/或仲裁器重新上线。
虽然两个系统发生故障或出现网络问题的可能性很低，但我已将此漏洞引入到主数据库中。有没有办法避免这个问题。我想到的一个想法是在另一台机器上添加另一个仲裁器，但是我不确定这是否可行并且会使集合相等。
最佳答案
当辅助副本和仲裁副本被终止时，主副本将成为辅助副本，因为它没有获得大多数选票(在本例中只有 1/3，低于 50%)才能成为主副本。目的是防止网络中断期间多个副本成为主副本，以保持数据一致性。
在这种情况下添加另一个仲裁者并没有帮助，因为您只有 2/4 票，不超过 50%。这就是为什么我们不需要偶数个副本集的原因。在这种情况下，您可以添加两个仲裁器以形成奇数。
如果您确实不希望辅助节点成为主节点(例如，辅助节点是只读的)并阻止主节点成为辅助节点，则可以将辅助节点和仲裁节点的投票数设置为 0(请参阅 http://docs.mongodb.org/manual/reference/replica-configuration/#local.system.replset.members[n].votes )。在这种情况下，您可以删除仲裁器，因为它变得无用。
cfg = rs.conf()
cfg.members[0].votes = 1 // the primary (by default votes = 1)
cfg.members[1].votes = 0 // the secondary
cfg.members[2].votes = 0 // the arbiter
rs.reconfig(cfg)
另一个解决方案是您可以给初选投票 3 票。那么总票数为 5，初选总是以至少 3/5 的票数赢得选举。但自 2.6 版本以来，此功能已被弃用，该版本不允许投票高于 1。
cfg = rs.conf()
cfg.members[0].votes = 3 // the primary
cfg.members[1].votes = 1 // the secondary
cfg.members[2].votes = 1 // the arbiter
rs.reconfig(cfg)
关于MongoDB、副本集以及防止主节点成为辅助节点，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26167440/