考虑我有一个包含 3 个节点（2 个数据节点和一个仲裁器 (PSA)）的副本集。当由于某种原因我的一个数据节点出现故障并将其带回来时，在与主节点同步期间，它处于 state STARTUP2。在他那个时候，我会失去我的change stream，因为我的副本集有 2 个数据节点，但我没有大部分节点可以读取。
我该如何处理这个问题？
我还阅读了这个 MongoDB 文档。是否可以将主节点priority值设置为高于辅助节点（即与主节点同步）？即使我的辅助节点处于STARTUP2状态，我也可以通过这样做获得多数吗？
从技术上讲，有两种类型的多数。正如我所说，他们是“选举多数”和“数据多数”。
仲裁者应该帮助“选举多数”，如果 S 出现故障，它有助于维持 PSA 架构中的主要可用性。但是，它们不是“数据多数”的一部分。
相比之下，“数据多数”既用于投票也用于确认多数读取和多数写入。
根据设计，变更流将返回提交给投票节点“数据多数”的文档。这是因为传播给他们的写入不会被回滚。如果变更流声明文档已写入，然后回滚，然后必须发出“不等待，从头开始，写入没有发生”，这将是令人困惑的。
因此，就其本质而言，仲裁器与多数读取和多数写入场景（例如变更流或事务）不兼容。但是，只要您知道对它们有什么期望，仲裁器仍然在副本集中占有一席之地。
请参阅哪个版本的默认 mongod 写入关注点是什么？更完整地解释写问题和仲裁的影响。
次要输入STARTUP2还不是次要的。它可能会在选举中投票，但它不会承认多数写入，因为它仍在启动中。
就变更流而言，由于在 PSA 架构中，“数据多数”实际上只是 PSA 的 PS 部分，因此没有一个数据承载节点可以离线以维护多数读写。
最好的解决方案是用一个实际的数据承载节点替换仲裁器。这样，您可以进行多数写入、多数读取，并且可以在一个节点关闭的情况下仍保持多数。