主从复制不等于高可用，需依赖外部组件实现故障检测与自动切换；GTID模式下须严控gtid_purged一致性；半同步复制需合理设置超时以避免写入阻塞；切换后必须重置从库复制起点并确保log_slave_updates开启。
主从复制本身不等于高可用，必须叠加故障检测与自动切换
MySQL 主从复制只是单向数据同步机制，START SLAVE 启动后，它不会主动感知主库宕机，也不会自动把从库提为新主。所谓“高可用”，本质是「主库挂了，业务无感切到新主」，这需要额外组件介入——比如 Orchestrator、MHA 或基于 ProxySQL + Consul 的自建方案。只配好 CHANGE MASTER TO 和 relay_log，同步再稳，也做不到高可用。
避免 GTID 模式下因 gtid_purged 不一致导致的复制中断
启用 GTID 后，从库重启或重搭时若 gtid_purged 与主库缺失 binlog 区间不匹配，START SLAVE 会直接报错 Cannot replicate because the master purged required binary logs。实际操作中容易忽略两点：
- 主库执行
RESET MASTER后，必须手动导出并注入当前gtid_executed到从库（用SET GLOBAL gtid_purged = '...'） - 从库做
mysqldump --set-gtid-purged=ON备份时，要确认主库 binlog 未被expire_logs_days清理掉对应部分 - 跨版本升级（如 5.7 → 8.0）时，
gtid_mode必须分步开启（OFF → OFF_PERMISSIVE → ON_PERMISSIVE → ON），否则从库无法识别新格式 GTID
半同步复制不是银弹，rpl_semi_sync_master_timeout 设置不当反而拖垮写入
开启 rpl_semi_sync_master_enabled = ON 后，若超时参数 rpl_semi_sync_master_timeout 设得过大（比如默认 10000ms），主库在等从库 ACK 时会长时间阻塞事务提交，导致应用端 INSERT/UPDATE 延迟飙升。真实生产环境建议：
- 设为
1000（1 秒），超时即退化为异步，保障主库可用性优先 - 配合监控
Rpl_semi_sync_master_yes_tx与Rpl_semi_sync_master_no_tx状态变量，及时发现从库长期失联 - 不要在所有从库上都强制半同步——可指定 1 台核心从库启用，其余保持异步，兼顾可靠性与吞吐
切换后的从库需重置复制起点，否则可能重复执行或跳过事务
主库故障后，人工或工具将某台从库提升为主库（例如执行 STOP SLAVE; RESET SLAVE ALL;），此时它已不再是“从库”角色。但若其他剩余从库仍按旧主的 binlog 位置继续拉取，就会出问题：
- 原主已不可达，
CHANGE MASTER TO MASTER_HOST='old_ip'必然失败 - 即使指向新主，若未用
CHANGE MASTER TO MASTER_AUTO_POSITION = 1（GTID 模式）或未手动校准MASTER_LOG_FILE/MASTER_LOG_POS，大概率出现Could not execute Write_rows_v1 event类冲突 - 更稳妥做法：提升新主后，对其他从库统一执行
CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1，并确保新主已开启log_slave_updates
真正难的不是同步数据，而是让所有节点对“谁是主、从哪开始同步”达成一致——这个一致性边界，MySQL 自己不管，得靠外部协调器或严格的操作流程兜底。
