MySQL高可用基于主从复制，核心是binlog异步/半同步重放；关键配置包括ROW格式、GTID开启、sync_binlog与innodb_flush_log_at_trx_commit设为1、从库read_only=ON；主流架构有MHA、Orchestrator、InnoDB Cluster和ProxySQL组合，选型需权衡一致性、运维成本与团队能力；故障切换须精准判断心跳、GTID同步状态及延迟，灾备需结合延迟从库与分层备份验证。
主从复制原理与关键配置
MySQL 高可用的基础是主从复制（Replication），其本质是基于 binlog 的异步/半同步日志重放。主库写入事务后生成 binlog，从库的 I/O 线程拉取并存入 relay log，SQL 线程再按序执行 relay log 中的事件。
必须掌握的关键点：
- binlog_format 推荐使用 ROW，避免语句级复制在非确定性函数、时间函数、自增主键等场景下的数据不一致
- gtid_mode=ON 是高可用方案（如 MHA、Orchestrator）的前提，确保故障切换时能精准定位复制位置，避免位点错乱
- sync_binlog=1 & innodb_flush_log_at_trx_commit=1 组合可最大限度保证主库崩溃后 binlog 不丢失（需权衡性能）
- 从库应设置 read_only=ON，防止误写；配合 super_read_only=ON（MySQL 5.7+）进一步阻断 SUPER 权限用户的写入
常见高可用架构对比与选型逻辑
没有“银弹”架构，选型取决于业务容忍度、团队能力、运维成本和扩展需求。
主流方案核心差异：
- MHA（Master High Availability）：Perl 编写，成熟稳定，支持自动故障转移和主从切换，但依赖 SSH 和 VIP，已停止维护，适合存量中小集群
- Orchestrator：Go 实现，可视化强，支持拓扑发现、自动修复、手动编排，原生支持 GTID，社区活跃，推荐新项目首选
- MySQL InnoDB Cluster（Group Replication + MySQL Shell + Router）：官方方案，基于 Paxos 协议实现多节点强一致性，支持单主/多主模式，但对网络延迟敏感，要求 MySQL 5.7.17+，适合强一致性优先场景
- Proxy 层方案（如 ProxySQL + MHA/Orchestrator）：ProxySQL 可做读写分离、故障自动摘除、慢查询拦截，与底层复制解耦，提升整体弹性
故障检测与切换的核心机制
高可用不是“有切换”，而是“切得准、切得稳、切得快”。重点不在脚本是否运行，而在判断依据是否可靠。
关键实践要点：
- 心跳检测不能只 ping IP 或端口，必须执行
SELECT 1并校验返回结果，避免中间件存活但 MySQL 实际 hang 住 - 主库宕机判定需满足“超时 + 多节点交叉验证”，避免脑裂（如 Orchestrator 默认需至少两个探针失败才触发）
- 切换前必须确认从库 Seconds_Behind_Master = 0 且 Retrieved_Gtid_Set == Executed_Gtid_Set，否则可能丢数据
- 切换后需自动更新 ProxySQL 或 DNS 的路由映射，并通知应用层（如通过回调脚本触发配置热重载）
数据一致性保障与灾备延伸
高可用解决的是单点故障，但不等于数据安全。一致性是底线，灾备是兜底。
不可忽略的动作：
- 定期用 pt-table-checksum 校验主从数据一致性，结合 pt-table-sync 修复（务必先备份再同步）
- 开启 relay_log_purge=ON 防止 relay log 积压占满磁盘；设置 relay_log_recovery=ON 让从库崩溃重启后自动清理损坏 relay log 并重建
- 异地灾备建议采用 异步复制 + 延迟从库（MASTER_DELAY），例如设置 3600 秒延迟，可挽救误删、逻辑错误等人为事故
- 备份策略需分层：物理备份（xtrabackup）用于快速恢复，逻辑备份（mysqldump）用于跨版本或小表回档，备份需验证可恢复性（定期 restore 测试）
