让我来逐个拆解你这两个MongoDB同步复制模式下的场景疑问，都是生产环境里挺常见的故障场景，得把底层逻辑理清楚：

场景1：主节点写入请求后、同步至从节点前宕机 #

首先得纠正一个认知：路由（mongos）并不负责选取新主节点，这个故障转移的核心逻辑是MongoDB复制集自身通过内部选举机制完成的，路由只是负责将请求转发到当前可用的主节点而已。

回到你的场景：如果写请求已经成功写入主节点，但主节点还没来得及把这个操作同步到任何从节点就宕机了，这里的结果要分两种情况看：

• 如果你设置的是严格的同步复制（w:majority写关注）：这种情况下主节点根本不会给路由返回写入成功的响应——因为w:majority要求主节点必须等待复制集内多数节点确认收到并写入这个操作后，才会返回成功。所以你说的“请求已写入主节点但未同步到从节点”的情况，在w:majority模式下根本不会发生，主节点宕机时路由会收到写入失败的响应，之后会自动重试请求到新选举出来的主节点。
• 如果你设置的是宽松的写关注（比如默认的w:1，即主节点写入就返回成功）：这时候主节点宕机后，复制集会选举一个最新的从节点作为新主节点，而这个新主节点里并没有那个未同步的写请求。等旧主节点恢复后，复制集会发现它的oplog（操作日志）比新主节点超前，这时候旧主节点会自动回滚那个未被多数节点确认的写操作，再同步新主节点的数据。也就是说，这个写请求会丢失，路由不会主动把它同步到新主节点——除非你的应用层自己做了重试逻辑。

场景2：主节点与单个从节点网络链路中断 #

同样先明确：只要主节点本身是正常运行的，复制集就不会触发新主节点的选举，路由也不会去“选取另一个从节点当主节点”——选举只有在主节点不可用（宕机、网络分区导致多数节点无法连接它）的时候才会触发。

在同步复制模式下，这种单节点网络中断的影响取决于你的写关注设置：

• 如果是w:majority：假设你的复制集有3个节点（1主2从），多数节点是2个。现在一个从节点断了，主节点还能和另一个从节点正常通信，那么主节点会等待这个可用的从节点确认写入，之后正常给路由返回成功响应，业务不会受影响。如果是5节点的复制集，断1个节点完全不影响多数节点的确认，业务毫无感知。
• 如果是w:1：主节点写入后直接返回成功，那个断连的从节点等网络恢复后，会自动从主节点同步遗漏的操作日志，补全数据，整个过程对路由和应用层都是透明的。

内容的提问来源于stack exchange，提问作者emilly