我会先确认影响范围，同时控制故障继续放大。能否描述主库写 Binlog、副本拉取并回放的基本过程。 是否理解复制默认通常是异步的，提交成功不等于副本已经应用。 能否区分复制延迟的网络、生成、传输和应用瓶颈。 是否知道读写分离会引入读己之写问题。 能否说明高可用不只是“有一个从库”，还需要探活、选主、防脑裂和数据校验。

止损之后，我会按请求链路建立证据，而不是凭经验猜。沿着「主库提交事务 → 生成并发送 binlog → 副本接收 relay log → 并行重放事务 → 故障检测后切换流量」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 主库提交事务 主库提交成功的持久化级别由 redo 与 binlog 刷盘参数决定，复制承诺从这里开始。 生成并发送 binlog dump 线程或协议把 binlog 发送给副本；异步、半同步决定主库等待到什么确认点。 performanceschema.replicationapplierstatusbyworker：并行回放与错误。 SHOW REPLICA STATUS：接收/执行位点与 GTID。

定位时我最关注这些参数、指标和容量关系。注入主库宕机、网络分区和大事务，记录副本 GTID 差、选主、fencing 与业务恢复时间。

找到根因后先做最小修复，再用同样的流量验证。控制面无法访问旧主就直接晋升副本，但旧主仍服务部分客户端，形成两个写入源。增加租约或 STONITH fencing、单写入口和旧主只读校验后，切换才不会只解决可用性却破坏一致性。 只看 SecondsBehindMaster 判断延迟：复制字节与应用位置差距：先 fencing 旧主。 切换未 fencing 旧主：事务重放延迟：按 GTID/健康选副本。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「GTID 差」为主基线，记录值应满足「切换候选为 0」；同时保存 复制字节与应用位置差距、事务重放延迟，使后续变化能够回到同一时间轴比较。

恢复阶段要逐步放量，最后把监控和边界补齐。方案：更适合的场景：主要收益：代价与边界。 异步复制：允许少量 RPO 且延迟敏感：主库提交快：主故障可能丢未复制事务。 半同步复制：希望降低数据丢失窗口：至少一个副本收到日志：副本或网络慢会影响提交。 组复制/共识方案：自动成员管理与更强单主约束：故障转移集成度高：运维复杂、写延迟与限制更多。 选型至少带上 数据规模、选择性、读写比、事务长度和峰值并发，并用上面的量化基线验证；未知数据应明确为待测假设。