考虑到我有一个副本集，其中包含3个节点（2个数据节点和一个仲裁器（PSA））。当由于某种原因我的一个数据节点出现故障并在与主节点同步时将其恢复为状态STARTUP2。在他的时候，我会丢失change stream，因为我的副本集有2个数据节点，但是我没有要读取的大多数节点。
我该如何处理这个问题？
我也读了this MongoDB doc。是否可以将主要节点priority的值设置为高于次要节点（即与主要节点同步）？即使我的辅助节点处于STARTUP2状态，我也可以这样做吗？
从技术上讲，有两种类型的多数。正如我所说的那样，它们是“选举多数”和“数据多数”。
仲裁员应该帮助“多数派”，如果S垮台，仲裁员将帮助维持PSA架构的主要可用性。但是，它们不属于“数据多数”的一部分。
相反，“数据多数”既用于投票，又用于确认majority-read和majority-write。
根据设计，变更流将返回提交给投票节点的“数据多数”的文档。这是因为传播到它们的写操作将不会是rolled back。如果changestream声明已编写文档，然后回滚，则必须发出“不等待，抓紧时间，写没有发生”，这将令人困惑。
因此，仲裁程序与变更流或事务之类的多数读取和多数写入方案不兼容。 但是
仲裁器在副本集中仍然占有一席之地，只要您知道对他们有什么期望。请参阅What is the default mongod write concern in which version?，以更完整地说明写问题以及拥有仲裁程序的效果。
STARTUP2中的辅助设备还不是辅助设备。它可能会在选举中投票，但由于它仍在启动，因此不会承认多数派的支持。
就变更流而言，由于在PSA体系结构中，“数据多数”实际上只是PSA的PS部分，没有数据承载节点可以脱机以维护多数读取和写入。
最佳解决方案是将仲裁器替换为实际的数据承载节点。这样，您就可以拥有多数写入，多数读取的功能，并且可以关闭一个节点并仍然保持多数状态。