核心概念
高可用（High Availability，HA）的核心目标是保障MySQL服务持续可用，最大限度减少停机时间、降低数据丢失风险，核心衡量指标有两个
MySQL高可用的本质的是解决三大核心问题：故障检测（快速发现主库异常）、自动切换（无需人工干预完成主从角色切换）、数据同步（确保从库与主库数据一致），避免单点故障导致业务停摆或数据丢失
MySQL高可用基础
所有高可用方案均依赖MySQL的数据复制功能，核心是通过日志同步实现主从节点数据一致，主要分为三种复制模式
复制核心原理
无论哪种复制模式，核心流程均为"三步联动"，类似"快递传递"逻辑
-
主库写入：主库执行写操作（INSERT/UPDATE/DELETE）后，将操作记录到Binlog（二进制日志，相当于"操作日记"）
-
从库拉取：从库启动IO线程，连接主库并实时读取Binlog，下载到本地保存为Relay Log（中继日志，相当于"快递包裹"）
-
从库重放：从库启动SQL线程，读取Relay Log并逐条执行其中的SQL语句，将数据同步到自身数据库，完成主从数据一致
三种复制模式对比
| 复制模式 | 核心特点 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 异步复制（默认） | 主库写完Binlog即返回，不等待从库确认 | 主库性能高，无额外延迟 | 主库故障时，未同步的Binlog数据会丢失 | 对数据一致性要求不高的中小业务 |
| 半同步复制 | 主库等待至少1个从库确认接收Binlog后再返回 | 数据丢失风险低，兼顾性能与可靠性 | 主库写入性能略有损耗（需等待确认） | 多数企业核心业务，平衡性能与数据安全 |
| 全同步复制 | 主库等待所有从库确认接收并执行Binlog后再返回 | 数据零丢失，一致性最强 | 主库性能损耗极大，延迟高 | 金融、支付等高敏感场景 |
主流MySQL高可用方案详解
MySQL高可用方案主要分为两类：基于主从复制的外部工具方案、基于集群协议的原生方案，以下是6种主流方案的核心解析，重点掌握MGR和主从+Keepalived两种高频方案。
主从/主主 + Keepalived
核心架构
1主1从（或双主互备）架构，主从节点部署Keepalived工具，通过虚拟IP（VIP）对外提供服务，依赖主从复制实现数据同步，Keepalived负责故障检测和VIP漂移
核心原理
Keepalived通过定时执行脚本检测MySQL服务状态（如mysqladmin ping），主库正常时持有VIP；当主库故障（宕机、网络中断），心跳超时后，从库抢占VIP，成为新主库，业务通过VIP访问，无需修改连接地址
优缺点
-
优点：部署简单、成本低，仅需2个节点；无复杂选主逻辑，切换速度快（1-3秒）；依赖MySQL原生功能，兼容性好
-
缺点：异步复制可能丢数据；一主多从架构切换后，其他从库需手动重新配置主库连接；云环境不支持VIP漂移；可能出现脑裂（主从均持有VIP）
高可用核心问题与解决方案
复制延迟
原因分析
主库写压力大、从库配置过低、大事务（如批量更新）、Binlog格式不合理、网络延迟等
解决措施
-
优化主库：拆分大事务，避免批量操作集中执行；开启Binlog压缩，减少日志传输量
-
提升从库性能：配置与主库相当的硬件，开启从库并行复制（MySQL 5.7+支持）
-
业务优化：读写分离时，对实时性要求高的读请求（如用户修改密码后）强制读主库；使用wait_for_executed_gtid函数等待复制完成
主库误删数据恢复
紧急处理流程：停止主库写操作 → 利用从库备份（如Percona XtraBackup）恢复数据 → 重新配置主从复制 → 验证数据一致性后恢复业务
高可用实践要点
监控与告警
核心监控指标：QPS/TPS、复制延迟（Seconds_Behind_Master）、连接数、InnoDB缓冲池使用率、Binlog同步状态
常用工具：Percona Monitoring Plugins（MySQL专用监控插件）、Prometheus+Grafana、Alertmanager（设置阈值告警，如复制延迟>10秒触发报警）
备份与容灾
-
物理备份：使用Percona XtraBackup进行热备份，定期备份到异地存储，支持增量备份，恢复速度快
-
逻辑备份：通过mysqldump备份核心数据表，用于误操作后的精准恢复
-
灾备演练：定期进行主从切换演练，验证故障恢复流程的可靠性，避免突发故障时手忙脚乱
性能调优
-
连接池优化：使用HikariCP、Druid等连接池限制并发连接数，避免主库被压垮
-
缓存优化：引入Redis缓存热点数据，减少数据库读压力
-
SQL优化：开启slow_query_log分析慢查询，优化索引，避免锁竞争