作者回复: 日志： 这个是一个比较通用的概念，可以包括你说的所有（journal,oplog,以及server日志）。 具体一点来说， journal日志是数据库的crash recovery手段。通常的做法是把数据库内的数据块修改，提前用文件顺序写方式刷到盘上，然后再去真正的提交数据的修改。这样的目的是在服务器宕机的时候，内存中被丢失的数据可以在恢复过程中从journal 日志文件中读回来。 Oplog也是记录的数据库的操作日志，但是记的是逻辑操作命令。主要的目的是用于节点之间复制数据，而不是上面journal主要是用来recover crash。 还有一种就是mongod.log，这个就是一个文本文件，记录数据库系统的正常运行和错误信息等等。

作者回复: 服务器端无法配置。 你可以在Connection String上设置，这个一般是全局统一的设置。 例子： mongodb://db0.example.com,db1.example.com,db2.example.com/?replicaSet=myRepl&w=majority&wtimeoutMS=5000 详细文档： https://docs.mongodb.com/manual/reference/connection-string/

作者回复: 这个问题我已经提交给原厂了，暂时还没有回复。

作者回复: j:1 表示Journal 日志刷盘，所以就是要写文件到硬盘。 正常数据只是写到内存的Cache（不是操作系统的cache，而是WiredTiger自己管理的Cache），然后异步刷盘。

作者回复: 有点绕。但是“刚刚写的那条数据是在它监听之前写入新的主节点的日志的，那么这个从节点不就丢失了这条写的数据了” 我只能说，这个从节点不会丢失。 最后一个从节点通过比较自己的oplog和新主的oplog来确定是否要同步新数据。两者的oplog肯定会差一条（新的数据），就会从新主那里复制。

作者回复: 这个是需要用reconfig命令才能生效的。

作者回复: 默认是read uncommitted。正常情况都不会有问题，除了发生宕机的时候，这个可能会有问题 - 你读到的一条数据可能会在宕机的时候被回滚掉。这种事情概率很小，发生了可能问题也不算特别严重，很多场景可以接受。如果要求比较高，那么需要用 readConcern: majority 来提高隔离级别。

作者回复: 如果你使用majority write concern的话，不一定非得需要j:true。因为即使在主节点crash场景下，这条数据也已经在另一个节点上有了。

作者回复: oplog和就是一个MongoDB的collection ，都是存储在磁盘上的。 对oplog的操作只是顺序追加写入，所以效率相对来说会高不少，相比于普通collection 的随机读写。 每一次增删改都会记录相应的oplog，并且对oplog的操作和数据表的写入是同一个原子事务的。

作者回复: 按照mongodb复制集选举规则，有最新数据的会第一优先被选为主节点