只有两台机器的副本集有意义吗？

Question

很多 MongoDB 教程在谈到副本集时，都给出了两台机器的示例：一台最初初始化为主要机器，另一台最初创建为辅助机器。

据我了解：

• 如果主要成员意外死亡，次要成员无论如何都不会选举自己成为新的主要成员，因为它不会拥有多数（两台机器的副本集中的两个）。

• 如果主成员不可用，即使使用read_preference=ReadPreference.SECONDARY.

• 重新创建主成员无论如何都行不通：它不能添加到现有的副本集中，因为它缺少主成员；它也不能rs.initiate();，因为它将创建具有不同 ID 的不同副本集。

因此，在现实生活中，复制集中只有两个成员是否有意义？或者这种情况只是理论上的，在实践中人们会期望在每个副本集中看到至少三个成员？

Answer 1

如果主要成员意外死亡，次要成员无论如何都不会选举自己成为新的主要成员，因为它不会拥有多数（两台机器的副本集中的两个）。

这是对的。为了选举（和维持）一个初选，需要有大多数投票成员。

如果主成员不可用，即使 read_preference=ReadPreference.SECONDARY 也不可能从数据库中读取数据。

这是不正确的。无主，你不能写一个副本集，但读取仍然是可能使用非主读的喜好，如secondary，primaryPreferred，secondaryPreferred，或nearest。默认读取首选项是primary，它提供强一致性（相对于从辅助读取时的最终一致性）。的primaryPreferred读取优先从主如果可用读取，否则从辅助。

重新创建主成员无论如何都行不通：它不能添加到现有的副本集中，因为它缺少主成员；它不能 rs.initiate(); 或者，因为它将创建一个具有不同 ID 的不同副本集。

如果丢失了双节点副本集中的成员之一，则可以强制将幸存的成员重新配置为单节点副本集，然后添加新成员。您只需要rs.initiate()在副本集的生命周期中运行一次。

因此，在现实生活中，复制集中只有两个成员是否有意义？或者这种情况只是理论上的，在实践中人们会期望在每个副本集中看到至少三个成员？

一般来说，大多数副本集部署有足够的成员来允许自动故障转移（即最少三个成员）。如果不考虑高可用性（或者您更喜欢手动干预），则不允许使用两个成员的副本集。但是，允许故障转移的更典型选项是将第三个仅投票成员（又名仲裁者）添加到您的副本集。

仲裁器是一个轻量级的仅投票成员，如果您的两个数据承载成员之一在三成员配置中不可用，它将提供多数票所需的额外投票。仲裁器有助于可用性，但它是对第三个数据承载成员的妥协。当带有仲裁器的三成员副本集处于降级状态（即您的一个承载数据的成员不可用）时，您仍将拥有一个主副本，但不再具有数据冗余或复制。仲裁器还将阻止您的应用程序能够依靠majority写关注来确保将数据提交给大多数副本集成员。

我个人的建议是至少为生产副本集部署三个数据承载成员，但是对于开发或非关键部署，可以考虑更少的数据承载成员。