【发布时间】：2018-06-27 21:56:00
【问题描述】：
我的应用程序本质上是一组跨 Node.js 实例部署的微服务。一项服务可能会写入一些数据，而另一项服务将读取这些更新。 （具体示例，我正在使用处理管道处理入站到我的解决方案的数据。阶段 1 执行某些操作，阶段 2 对相同数据执行其他操作，等等。这是一种相当常见的模式）
所以，我有一个很大的数据集（现在约 250GB，而且我已经读到，一旦数据库变得比这个大小大得多，就不可能在数据库中引入分片，至少，不是没有一些主要的箍跳跃）。我想要一个高可用的数据库，所以我计划使用至少一个辅助节点和一个仲裁器的副本集。
我仍在研究我的“分片”选项，但我认为我可以通过它所属的“客户端”对我的数据进行分片，因此我认为拥有 3 个分片对我来说是有意义的。
第一个问题，如果我是正确的，如果我有 3 个分片并且我的副本集是 Primary/Secondary/Arbiter（Arbiter 在 Primary 上运行），我将运行 6 个 MongoDB 实例。将有三个主节点和三个辅助节点（仲裁器在每个主节点上运行）。这是正确的吗？
第二个问题。我已经阅读了有关“多数”含义的相互矛盾的信息......如果我有一个主要和次要并且我正在使用“多数”写入确认进行写入，那么当主要或次要发生故障时会发生什么？如果仲裁器仍然存在，则可以进行选举，并且我仍然会有一个主节点。但是，多数是指复制集的成员吗？还是给二线？所以，如果我只有一个 Primary 并且我尝试使用“majority”选项来写作，我会得到确认吗？如果只有一个主节点，那么“多数”意味着仅对主节点的写入会触发确认。或者，这会一直阻塞，直到我达到超时，然后我会得到一个错误？
第三个问题...我假设只要我使用“多数”确认进行写入并从所有初选进行读取，我就不需要担心因果一致的数据？我读过从“辅助”节点进行读取是不值得的。如果从辅助节点读取，您必须担心“最终一致性”，并且由于写入正在同步，辅助节点基本上看到与主节点相同的流量。因此，从辅助节点中读取没有任何好处。如果是这种情况，我可以从 Primaries 进行所有读取（使用“多数”读取问题），并确保我始终获得一致的数据，并且我正在做的分片让我通过将负载分配给我一些好处碎片。这是正确的吗？
第四个（也是最后一个）问题... 因果一致的会话何时值得？如果我理解正确，并且我不确定我是否理解，那么我认为这是当我有一个典型的网络应用程序（不是一些分布式应用程序，比如我现在的应用程序）时，只有一个（或两个) 节点进行读写。在这种情况下，我会使用因果一致的会话并写入主节点并从辅助节点读取。但是，在那种情况下，从辅助节点那里阅读有什么好处呢？我错过了什么？因果一致会话的用例是什么？
【问题讨论】：
-
永远不要在数据承载节点上运行仲裁器如果该节点发生故障，您将失去法定人数并且您的副本集将变得不可用。
-
@MarkusWMahlberg 感谢您的评论。我已经读过，我认为即使在 Mongo 文档中，也建议在主节点上运行仲裁程序。我的整体困惑的一部分是 Mongo 文档缺少一定数量的“上下文”，这使得特定细节变得有用。你可以从我对因果一致会话的困惑中看出......总的来说，这个概念是有道理的。但是，我不确定我为什么在乎？
标签： mongodb mongodb-query