我一直在阅读文档，根据我的理解，我可以看到一种可能仍会发生回滚的情况：
这种情况是否合理？
答案 0 :(得分：3)
如果在获取命令并写入磁盘的其他成员之间断电，这可能是回滚的合理案例。
在这种情况下，正如您所指出的那样，主服务器无法启动备份，因此，一旦备份，就会包含其他服务无法验证导致回滚的操作。
值得注意的是，作为一个曲线球，如果主 没有下降，那么它将返回一个成功的写入，应用程序将不再是该集合已经消失的更明智的down并且他们的{w: majority}没有写入磁盘。当然，这是一个边缘案例。
答案 1 :(得分：1)
不要认为它会发生在MongoDB 3.2+中，就像在here中一样，你看到：
在版本3.2中更改：使用j：true，MongoDB仅在。之后返回 请求的成员数量，包括主要成员，已写入 日记。以前j：仅在副本集中写入真正的写入问题 无论w如何，都要求主要人员写入日记： 写关注。
答案 2 :(得分：0)
根据文档，我的理解是，如果你设置j = 1，那么w＆gt; 1没关系。您的应用程序将只有一次（并且一旦）主要已将写入提交给其自己的日志。写入副本将会发生但不会影响您的写作问题。
鉴于此，“可以主要提交日志，启动写入，让群集在辅助节点提交到日志之前关闭，然后在辅助节点恢复为主节点时回滚主节点” “比原始问题所暗示的更有可能（但可能性非常低）。
来自文档：
Requiring journaled write concern in a replica set only requires a journal commit of the write
operation to the primary of the set regardless of the level of replica acknowledged write concern.