MySQL主从自动切换必须依赖外部工具，核心是检测主库故障→选最优从库→安全提升为新主→重配其余从库→更新访问入口；推荐MHA、Orchestrator、Keepalived+脚本或ProxySQL组合，需前置开启GTID、半同步复制、时间同步及SSH免密。
选一个靠谱的自动化方案
生产环境不建议手写轮询脚本，推荐以下成熟组合：
- MHA（Master High Availability）：Perl 编写，老牌稳定，全自动选主、提升、重配从库、VIP 漂移、邮件告警；需部署 Manager 节点 + 所有 MySQL 节点装 Node，依赖 SSH 免密和半同步复制
- Orchestrator：Go 开发，带 Web 界面，支持拓扑自动发现、GTID 智能分析、人工干预开关、Consul 集成；切换前会校验延迟、SQL 线程状态、版本兼容性
-
Keepalived + 自定义脚本：Keepalived 只管 VIP 漂移（毫秒级），但不碰 MySQL 复制逻辑；需配合 shell/Python 脚本在 VIP 切换后执行
STOP SLAVE; RESET SLAVE ALL; SET GLOBAL read_only=OFF;等操作 - ProxySQL + 监控事件驱动：用 ProxySQL 的 hostgroup 权重与健康检查识别主库失效，再由外部脚本调用其 Admin 接口切换读写组，并触发 MySQL 角色变更
切换前必须满足的关键条件
无论用哪种方案，以下基础必须到位，否则自动切换等于制造事故：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 所有节点开启 GTID（
gtid_mode=ON+enforce_gtid_consistency=ON），避免位点计算错误 - 主库启用 半同步复制（
rpl_semi_sync_master_enabled=1），确保至少一个从库已收到最新事务 - 所有 MySQL 实例时间同步（
chronyd或ntpd），防止心跳误判 - 各节点间配置 SSH 免密登录（MHA/Orchestrator 需远程执行命令）
- 从库
read_only=ON且super_read_only=ON（防止意外写入）
切换中真正关键的操作动作
工具只是载体，底层仍是标准 SQL 和系统操作。自动切换流程实际执行这些步骤：
- 在候选从库上执行：
STOP SLAVE;→RESET SLAVE ALL;→SET GLOBAL read_only=OFF;→SET GLOBAL super_read_only=OFF; - 确认该库已无
Master_Host字段（SHOW SLAVE STATUS\G输出为空） - 检查
SHOW MASTER STATUS;获取新主库 binlog 文件名与 position，供其他从库重新接入使用 - 对其他从库批量执行：
CHANGE MASTER TO MASTER_HOST='新主IP', MASTER_AUTO_POSITION=1;（GTID 模式下无需指定 file/pos） - 启动复制：
START SLAVE;并验证Slave_IO_Running和Slave_SQL_Running均为Yes
原主库恢复后怎么处理
自动切换只解决“谁来顶上”，不解决“旧主怎么归队”。恢复后必须人工介入：
- 先不要直接启动 MySQL，应检查其 binlog 是否有新写入（如有，极可能已脑裂）
- 安全做法：以新主库为基准，用
mysqldump --single-transaction --master-data=2重搭旧主为从库 - 若确认旧主宕机期间零写入，可尝试基于 GTID 追平：
CHANGE MASTER TO MASTER_HOST='新主IP', MASTER_AUTO_POSITION=1; - 切换完成后，务必运行
pt-table-checksum校验主从数据一致性
