MongoDB主副服务器工作原理及两类故障场景问题咨询

嘿，先给你理清楚主副节点的核心分工：

• 主节点（Primary）：是集群里的“写入一把手”，所有客户端的写入、更新、删除操作都得交给它处理。同时它会把每一次操作都记录到oplog（操作日志）里，这个日志就像它的“工作台账”，用来同步给副节点。
• 副节点（Secondary）：主要做两件事——一是从主节点拉取oplog，然后在自己的数据集上“复刻”这些操作，保证和主节点数据完全同步；二是可以处理读请求（默认需要配置读偏好，比如secondaryPreferred）。另外，副节点还有个关键作用：当主节点挂了，它们会参与选举，选出新的主节点来接管集群。

咱们一步步看：

1. P1下线时：集群会立刻检测到主节点不可用，这时剩下的7台副节点会触发选举——MongoDB会从符合条件的副节点里选新主（条件包括：数据和原主节点最同步、能和集群里多数节点通信、优先级设置达标等），选出的新主会立刻接管所有写入操作。
2. P1重新上线时：它不会自动夺回主节点身份！因为此时集群已经有了正常工作的新主，P1重新加入后会自动切换成副节点身份。然后它会从当前的主节点拉取自己离线期间所有的oplog，一步步重放这些操作，把自己的数据补全到集群最新状态，这个过程是自动完成的，不用你手动干预。
3. 离线期间的变更处理：P1离线时，新主处理的所有写入都会被记录在自己的oplog里，P1上线后作为副节点，会同步这些日志，最终和集群数据完全一致，不会有数据丢失（前提是集群选举时新主的数据是完整的）。

这种情况就轻松多了：

• 首先，集群会标记S4为不可用，但因为主节点P1还在正常工作，而且当前可用节点数（1主+6副）超过了集群总节点数的一半（8台的话，多数是5台），所以集群的写入和读操作完全不受影响——写入依然由P1处理，读请求如果配置了分发到副节点，会自动跳过S4，分给其他可用的副节点。
• 等S4重新上线后，它会自动连接集群，从主节点（或者其他同步进度更快的副节点）拉取自己离线期间的oplog，重放操作同步数据，最终和集群保持一致，整个过程也是自动的。

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