MySQL双主复制架构单主节点宕机后的运行及恢复规则咨询

你的推测只在「上层配置了自动流量切换、宕机期间无异常双写、节点元数据无损坏」的前提下成立，原生双主复制本身的实际运行逻辑分场景如下：

单节点宕机瞬间的集群原生行为 #

• 无额外高可用组件（VIP漂移、数据库中间件路由等）的裸双主架构，不会自动切换写入流量。原生复制只负责双向同步binlog，不做流量调度：
  • 若master1宕机，master2自身的读写服务完全正常，但master2上指向master1的复制IO线程会因连接失败进入重试状态，重试间隔由slave_connect_retry参数控制，默认60秒；此时如果业务端没有主动把写入地址切到master2，所有指向master1的写入、查询请求会直接报错，不会自动转发到master2。
  • 若master2宕机，master1的状态与上述一致，自身读写不受影响，指向master2的复制IO线程进入重试，不会主动接管master2的流量。
• 若你在上层配置了故障自动切换逻辑（比如Keepalived检测节点状态漂移VIP、ProxySQL自动摘除故障节点），流量会按照你配置的检测规则切到存活节点，这个切换动作是上层组件实现的，和双主复制本身无关。
• 复制模式对宕机期间存活节点的影响：
  • 默认异步复制模式下，存活节点的写入完全不受对端宕机影响，binlog正常记录、位点正常推进。
  • 半同步复制模式下，存活节点会等待对端返回binlog ACK，等待超时（由rpl_semi_sync_master_timeout控制，默认10秒）后会自动降级为异步复制，写入不会长期阻塞；除非你手动配置了强制半同步不降级策略，才会出现写入卡住的情况。

宕机节点恢复后的同步逻辑 #

• 正常宕机（进程崩溃、服务器硬重启，本地binlog、relay log、复制位点文件无损坏）的场景：
  节点拉起后复制线程会自动启动，首先读取本地存储的上次同步到的对端binlog位点，从存活节点拉取宕机期间产生的所有binlog事件，写入本地relay log后重放，追平与存活节点的数据差。当宕机节点追平数据后，存活节点上之前处于重试状态的复制IO线程也会成功重连，反向拉取该节点恢复后产生的新数据，双向同步会自动回到正常状态，这个过程不需要人工介入。
  如果你之前按照双主最佳实践配置了自增参数（两个节点分别设置不同的auto_increment_offset，auto_increment_increment设为2），且宕机期间所有写入都打到存活节点，同步过程不会出现主键、唯一键冲突。
• 以下场景不会自动完成同步，需要人工介入：
  • 宕机期间存在双写：比如部分业务端直连缓存了故障节点地址，节点恢复启动后立刻有写入进来，会导致两边数据都有增量，极易出现主键冲突、唯一键重复，复制线程会直接报错中断，不会自动修复冲突。
  • 宕机节点本地的复制元数据文件（master.info、relay-log.info）、binlog文件损坏，或者节点是重装后重新上线，会出现位点不匹配的问题，无法自动拉取缺失数据，需要先从存活节点做全量备份重建实例，再配置复制追平位点。

常见认知误区 #

• 不要把双主复制等同于高可用集群：双主本质是双向的主从复制，只解决数据多点写入的同步问题，本身没有故障探测、流量切换、冲突自动修复的能力，你推测里的自动切流必须依赖上层配套组件才能实现。
• 不要默认节点恢复就一定能自动补数据：自动同步的前提是无异常双写、文件无损坏、位点连续，只要复制线程报冲突或者位点错误，同步就会中断，需要人工处理。

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