mongodb写入问题：所有副本成员是否都是动态的？

是否可以将

WriteConcern

设置为类似all的值，这意味着只有在所有“当前可用”（操作时）副本成员确认操作时，插入/更新才会返回

作为

“多数”的设置使一些成员下落不明

如果我们指定一个数值，那么如果我们将

WriteConcern

设置为“成员总数”，并且任何副本成员由于任何原因都会下降，则插入/更新可能会无限期挂起

如果我们使用标签集，如官方文件中所述，我们仍然需要为每个标签提供一个数字值，如果我们在总成员数和任何成员数下降时指定数字值，结果将与第二点相同

我们要考虑的是，是否存在

WriteConcern

的设置，该设置动态地表示插入/更新时副本成员的总数

提前谢谢

是否可以将WriteConcern设置为类似于all的值，这意味着只有在所有“当前可用”（操作时）副本成员确认操作时，插入/更新才会返回

建议您的用例需要强大的一致性存在逻辑上的矛盾，除非这是不可能的。存在复制延迟、维护或故障（以及后续恢复）等预期情形，其中一个或多个副本集辅助副本可能处于联机状态，但落后于当前主副本集

如果您的用例需要强大的一致性，那么您应该始终从主设备而不是从辅助设备读取数据，并使用多数/副本安全的写问题，以确保在发生故障转移时，数据已充分复制以实现高可用性

默认情况下，将读取定向到主服务器以实现一致性。MongoDB副本集中的二级副本通常旨在支持高可用性，而不是读扩展（少数例外情况如跨多个数据中心分发）。有关更详细的解释，请参见：

“多数”的设置使一些成员下落不明

多数写入关注点与在选择复制集时选择主对象所需的多数匹配。副本集包括确保一个新的主副本（参与选择的节点）中的最新操作是最新的

如果我们指定一个数字值，那么如果我们将WriteConcern设置为“成员总数”，并且任何副本成员由于任何原因而停止，则插入/更新可能会无限期挂起

这是预期的默认行为，但是有一个写关注点选项，它设置了一个时间限制（以毫秒为单位），这样写操作就不会无限期地阻塞，等待确认得到满足

使用超时的注意事项非常重要，并且提供的结果更不确定：

wtimeout

导致写入操作在指定限制之后返回错误，即使所需的写入问题最终会成功。当这些写入操作返回时，MongoDB不会撤消在写入问题超过

wtimeout

时间限制之前执行的成功数据修改

写入问题超时与副本集成员的当前运行状况（即，他们是在线还是离线，并且可能能够确认写入问题）或最终结果没有直接关系——它只是应用程序在返回前等待响应的时间上的一个急停

如果我们使用标签集，如官方文件中所述，我们仍然需要为每个标签提供一个数字值，如果我们在总成员数和任何成员数下降时指定数字值，结果将与第二点相同

---

正确。

这方面存在许多问题，我的意思是，在确保获得集合中的所有成员的同时，如何判断max up成员的完整数量？与底层成员打交道怎么样？你能分享这个请求背后的用例吗？也许有更好的处理方法。嗯，我们正在进行一个项目，其中一部分涉及将短信保存到数据库中。消息的数量是巨大的，我们正在考虑使用MongoDB，而不是传统的RDBMS来实现这个组件。用户将不断生成我们将放入数据库的消息。大约20%的操作是“插入”，约5%是“更新”，其余是“读取”。我们不介意“插入”或“更新”是否缓慢，但我们需要确保读取MongoDB任何二级副本的每个客户端始终与主副本的最新插入/更新保持一致……我也有同样的问题。有什么解决办法吗？很好，这回答了我的问题。对我来说，关键的一句话是：

MongoDB副本集中的二级副本通常旨在支持高可用性，而不是读扩展

。这对我理解MongoDB的工作原理有很大帮助。谢谢：-）。不幸的是，我不能将你的回答标记为接受（因为这不是我的问题），但我会尽快向你提供奖金。谢谢你的详细解释！在我看来，我们的团队对MongoDB的设计有一些错误的概念，我们将根据您的建议进行进一步调查。再次感谢。