我的应用程序本质上是一堆跨Node.js实例部署的微服务。一个服务可能会写入一些数据，而另一服务会读取这些更新。 （特定示例，我正在使用处理管道来处理解决方案中入站的数据。第1阶段对同一数据执行某些操作，第2阶段对其他数据执行其他操作，等等。这是一种相当常见的模式）
所以，我有一个很大的数据集（现在约250GB，我读过，一旦数据库变得比这个大小大得多，就不可能将分片引入数据库，至少，除非没有一些主要的限制，跳跃）。我想拥有一个高度可用的数据库，所以我正在计划一个至少有一个辅助服务器和一个仲裁器的副本集。
我仍在研究我的“分片”选项，但是我认为我可以通过其所属的“客户端”对数据进行分片，因此我认为有3个分片是有意义的。
第一个问题，如果我是对的，如果我有3个分片，并且我的副本集是Primary / Secondary / Arbiter（其中Arbiter在Primary上运行），我将有6个MongoDB实例在运行。将有三个主要仲裁机构和三个次要仲裁机构（每个主要仲裁机构都运行仲裁程序）。这是正确的吗？
第二个问题。我已经阅读了有关“多数”的含义的冲突信息...如果我有主节点和辅助节点，而我正在使用“多数”写确认进行书写，那么当主节点或辅助节点出现故障时会发生什么？如果仲裁者仍在那儿，选举就可以举行，而我仍然会有一名初选者。但是，多数是否引用复制集的成员？还是去中学？因此，如果我只有小学班级，并且尝试使用“多数”选项写作，我会得到承认吗？如果只有一个主数据库，则“多数”将意味着仅对主数据库的写入会触发确认。或者，这会一直阻塞直到达到我的超时时间，然后我会收到错误消息吗？
第三个问题...我假设只要我确实写有“多数”确认并且从所有基本知识中读取内容，我就不必担心因果一致的数据了吗？我已经读过，从“次要”节点进行读取是不值得的。如果从辅助服务器读取数据，则必须担心“最终一致性”，并且由于写入已同步，因此辅助服务器实质上会看到与主服务器相同的流量。因此，阅读中学课程没有任何好处。如果是这种情况，我可以从“原语”中进行所有读取（使用“多数”读取关注），并确保我始终获取一致的数据，并且正在执行的分片操作使我可以从分配负载到其他方面获得一些好处碎片。这是正确的吗？
第四个（也是最后一个）问题...因果一致的会话何时值得？如果我理解正确，但不确定这样做，那么我认为是在这样的情况下，例如一个典型的Web应用程序（不是某些分布式应用程序，如我的当前应用程序），其中只有一个（或两个） ）节点进行读写操作。在这种情况下，我将使用因果一致的会话，并对主服务器进行写入，并从辅助服务器进行读取。但是，在那种情况下，无论如何，从中学读书的好处是什么？我想念什么？因果一致会话的用例是什么？
答案 0 :(得分：0)
如果我有3个分片并且我的副本集是Primary / Secondary / Arbiter（其中Arbiter在Primary上运行），那么我将有6个MongoDB实例在运行。将有三个主要仲裁机构和三个次要仲裁机构（每个主要仲裁机构都运行仲裁程序）。这是正确的吗？
A replica set Arbiter仍然是mongod的实例。只是仲裁者没有数据的副本并且不能成为主要仲裁者。每个分片应具有3个实例，这意味着总共9个实例。
由于您提到要进行高可用性的数据库部署，因此请注意，建议用于生产部署的最小副本集成员为具有两个辅助数据库的主数据库。
如果我有一个小学和中学，并且我正在使用“多数”写确认进行书写，那么当小学或中学出现故障时会发生什么？
当主要服务器或次要服务器都不可用时，w:majority写入将是：
这是因为仲裁器不携带任何数据，也无法确认写入，但仍被视为voting member。另请参见Write Concern for Replica sets。
我可以从“基本信息”中读取所有内容（使用“多数”阅读关注），并确保我始终获取一致的数据，并且正在执行的分片为我在分片上分配负载提供了一些好处< / p>
正确，MongoDB Sharding用于水平缩放以在各个分片之间分配负载。 MongoDB Replication是为了提供高可用性。
如果您仅从主数据库读取并且还指定了readConcern:majority，则应用程序将读取大多数副本集成员已确认的数据。如果发生分区（即不回滚），则该数据是持久的。另请参见Read Concern 'majority'。
如果应用程序要求某个操作在逻辑上取决于先前的操作（因果关系），则使用因果一致会话的用例是什么？
Causal Consistency。例如，基于指定条件删除所有文档的写入操作和验证删除操作的后续读取操作具有因果关系。这在分片群集环境中尤其重要，在分片群集环境中，写操作可能进入不同的副本集。