MySQL高可用方案需主从复制+自动切换（如MHA）、读写分离双保险、多中心异步容灾、元数据集中管理及定期故障演练，覆盖监控告警与全链路验证。
主从复制 + 多节点故障自动切换
MySQL 单点故障最常见于主库宕机导致写入中断。解决核心是构建可自动接管的主从集群。推荐采用 MHA（Master High Availability） 或 Orchestrator 工具，它们能实时监控主库状态，一旦检测到主库不可达（如心跳超时、SSH 失联、MySQL 进程退出），在 10–30 秒内完成从库提升、VIP 漂移、应用连接重定向。注意：所有从库需开启 log_slave_updates，确保级联复制可用；GTID 必须启用，避免位置点不一致引发切换失败。
读写分离 + 应用层路由兜底
单纯依赖中间件（如 ProxySQL、MaxScale）做读写分离存在中间件自身单点风险。建议采用“中间件 + 客户端双保险”策略：中间件负责常规流量分发，同时在应用配置中内置备用读库列表和简单健康探测（如执行 SELECT 1）。当 ProxySQL 不可用时，应用可降级直连从库继续提供只读服务。写请求则必须经由主库或强一致性中间件，不可绕行。
多中心部署 + 数据同步容灾
同城双机房或异地多活场景下，避免跨中心主从强同步（如半同步+长距离网络），易因延迟触发超时回退。推荐：
• 同城双中心：主库与一个高优先级从库部署在 A 中心，另一个从库部署在 B 中心，使用异步复制 + 延迟监控告警（如 Seconds_Behind_Master > 60）；
• 异地容灾：采用基于 GTID 的逻辑复制工具（如 Mydumper/Myloader 定时快照 + Canal 实时解析 binlog）构建最终一致性备库，不参与实时读写，仅用于故障重建或报表查询。
元数据与配置集中管理
集群拓扑、账号权限、备份策略等信息若分散在各节点或人工维护，极易因配置不一致引发故障扩散。应统一使用配置中心（如 Consul、Etcd）管理：
• MySQL 实例启动时拉取当前主库地址与角色标签；
• 权限变更通过自动化脚本+审批流程同步至所有节点；
• 备份任务由调度系统（如 Airflow）统一触发，并将备份集元数据（时间、校验码、位置）写入数据库表，便于恢复时快速定位有效备份。
定期演练 + 监控覆盖全链路
再完善的架构不验证就是纸面方案。每月至少执行一次真实故障注入：
• 主动 kill -9 主库 mysqld 进程；
• 拔掉主库网线模拟网络分区；
• 清空从库 relay log 模拟复制中断。观察切换是否触发、应用是否自动重连、数据是否丢失、监控告警是否及时。关键监控项必须覆盖：
• 主从延迟（Seconds_Behind_Master）、
• 复制 IO/SQL 线程状态、
• 连接数使用率（Threads_connected / max_connections）、
• binlog 日志增长速率与磁盘剩余空间联动告警。
