MySQL主库宕机时如何达成数据共识？主从故障处理咨询

首先明确核心差异：ETCD基于Raft协议实现的强一致容灾，本质是所有写请求必须得到多数节点确认才会提交成功，不会出现「主节点提交成功但其他节点没有日志」的情况；而传统MySQL主从架构默认用异步复制，半同步复制如果没开无损模式也存在提交后日志没发出去的窗口，你描述的就是这类架构下的典型事务丢失场景。

问题1：是否会引发业务混乱，是否需要运维介入 #

• 必然会引发业务故障，且属于需要人工介入的资损级问题：你描述的场景里，用户支付成功的状态只存在于已宕机的旧主库上，新选的主库没有这条更新，用户发起取消操作时，系统会判定订单处于未支付状态，直接执行取消逻辑——最终会出现用户已完成扣款、但订单被关闭的资损问题，后续还可能连带触发库存错误回滚、优惠券错误退回、对账流水不平等等连锁问题。
• 这类问题无法靠数据库自动机制修复，必须第一时间人工介入：运维和业务研发需要先从旧主库留存的binlog、第三方支付渠道的回调记录、业务侧支付日志中捞取所有丢失的已提交事务，逐笔做对账修复，根据实际情况给用户补单或者走退款流程，故障暴露越晚，脏数据扩散范围越大，修复成本越高。

问题2：原主库恢复上线后的节点协作逻辑 #

主流MySQL高可用调度组件（MHA、Orchestrator、云数据库高可用模块）在主从切换完成、旧主库恢复上线后，会按固定逻辑处理节点关系，不会放任两个节点各自持有不一致数据对外提供服务：

• 第一步会先对恢复的旧主库做隔离：直接设置全局只读、甚至切断业务访问路径，避免旧主库接收写请求产生双写脑裂。
• 第二步会做日志对齐：基于GTID或者binlog位点做差异对比，找到旧主库上那些没同步到集群其他节点、只在本地提交的孤本事务（也就是你说的那条支付状态更新事务），直接回滚这部分事务，再把旧主库作为新主库的从库挂载，从新主库拉取增量日志同步数据。
• 最终集群所有节点的数据会和新主库保持一致，也就是订单状态会同步为「未支付->已取消」，旧主库上那条已经提交的支付记录不会被同步到新主，反而会被回滚清除。

注：如果要从架构层面彻底避免这类问题，需要采用和Raft逻辑一致的多数派提交方案，比如开启MySQL无损半同步复制（事务提交前必须收到至少一个从库的日志落盘确认）、部署MGR组复制集群，这类架构下不会出现主库提交成功但日志未同步到多数节点的情况，容灾能力和ETCD对齐。

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