我知道我们无法写入MongoDB中的辅助节点。但我无法找到任何技术原因。在我的情况下，如果有轻微的延迟，我真的不在乎，但写入辅助可能会更快。如果可以，请提供一些参考。谢谢！
答案 0 :(得分：3)
您无法写入辅助服务器的原因是复制的工作方式：
辅助节点连接到主节点上的特殊集合，称为oplog。此oplog包含通过查询优化器运行的操作。基本上，oplog是一个上限集合，辅助文件使用一个tailable游标来访问它的条目并从最旧到最新处理它。
当主要进行选举时，由于主要进入/退出，具有最新oplog条目的辅助选举被选为主要选举。辅助节点连接到新的主节点，查询尚未处理的oplog条目，并且群集处于同步状态。
这个程序非常简单。现在想象一个人可以写一个辅助。集群中的所有节点都必须在集群的所有其他节点上都有一个可用的游标，并且在一台机器发生故障时保持一致的状态会导致非常复杂，并且即使在比赛中出现故障条件依赖的事情。实际上，即使最终的一致性也不能得到保证。这或多或少是一场赌博。
话虽如此：副本集不用于负载平衡。副本集的目的是增强数据的可用性和持久性。因为从辅助数据库中读取是一种非风险的事情，MongoDB根据他们的教条提供了可能性，即他们提供了最大可能的功能而不会影响可扩展性（如果可以写入辅助服务器会严重受阻）。
但是MongoDB 提供了负载均衡功能：sharding。选择正确的分片键，您可以根据需要分配读取和写入负载（几乎）。更不用说在分片时你可以以合理的价格提供更多珍贵的RAM。
答案 1 :(得分：3)
有一个单线答案：
多主复制是一个毛球。
如果你被允许写入辅助文件，MongoDB将不得不使用milti-master复制来实现这个工作：http://en.wikipedia.org/wiki/Multi-master_replication其中，基本上evey节点互相复制他们收到的OP（操作），并以某种方式进行不会丢失数据。
这种复制形式有许多需要克服的障碍。
一个是吞吐量;请记住，OP需要在整个网络中传输，因此在添加一致性问题时可能会丢失吞吐量。因此，获得更好的吞吐量将是一个问题。它有很多次要的，接受所有的初选OP，然后它自己的复制出站，然后要求它做另一份工作。
在像这样的分布式集合中添加一致性也是危险的，一个主要的问题是，当询问成员是否关闭或者是：＃34;是真的失败还是刚刚不可用时，MongoDB会出错？＆＃34;。几乎不可能在这样的分布式集合中确保真正的一致性，至少是棘手的。
这些只是两个问题。
基本上，总而言之，MongoDB还没有拥有mlti-master复制。它可以在将来但我不会喜欢跳跃，如果有的话，我很可能会忽略这样的功能，ACID和非ACID数据库中的正常复制和分片都会导致足够的血压。