在 Linux 上实现 MySQL 高可用的主流方案与落地步骤

一、方案总览与选型建议
二、快速落地路径
路径A:通过主从复制和Keepalived来达成自动切换(这种方式比较适合读操作多而写操作少的情况)
- 主库配置
- my.cnf
[mysqld]
server-id=1
log-bin=mysql-bin
binlog_format=ROW - 创建复制用户
CREATE USER 'repl'@'%' IDENTIFIED BY 'ReplPass!';
GRANT REPLICATION SLA VE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES; - 记录位点:
SHOW MASTER STATUS;
- my.cnf
- 从库配置
- my.cnf
[mysqld]
server-id=2
relay-log=mysql-relay-bin
read-only=1 - 建立复制
CHANGE MASTER TO
MASTER_HOST='主库IP',
MASTER_USER='repl',
MASTER_PASSWORD='ReplPass!',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;
START SLA VE; - 检查:
SHOW SLA VE STATUSG,确保 Sla ve_IO_Running/Sla ve_SQL_Running=Yes。
- my.cnf
- Keepalived 提供 VIP 与故障切换
- 安装:
sudo apt-get install keepalived(或 yum) - 健康检查脚本(示例):
/usr/bin/mysqladmin ping,失败阈值与权重调整实现主备切换 - 配置要点(示例)
vrrp_script check_mysql {
script "/usr/bin/mysqladmin ping"
interval 2
weight -1
fall 3
rise 2
}
vrrp_instance VI_1 {
interface eth0
state BACKUP
virtual_router_id 51
priority 100
advert_int 1
authentication { auth_type PASS; auth_pass StrongPass; }
virtual_ipaddress { 192.168.1.100/24 }
track_script { check_mysql }
} - 启动:
systemctl start keepalived
- 安装:
- 应用侧将写库地址指向 VIP(如 192.168.1.100),读库可配置多个从库或配合中间件读写分离。
- 主库配置
路径 B:MHA 实现一主多从的自动故障转移(适合需要自动选主的场景)
- 架构:一主两从 + MHA Manager 节点
- 主从复制按路径 A 配置;确保开启 GTID 或记录准确位点
- 在 MHA Manager 节点安装与配置:定义节点、复制用户、SSH 免密、候选主等
- 启动监控:
masterha_manager --conf=/etc/mha/app1.cnf - 故障切换后执行
masterha_master_switch --master_state=dead等命令完成切换与回切策略。
路径C:InnoDB Cluster/Group Replication(MGR,即原生高可用方案)
- 三节点(建议奇数)安装同版本 MySQL(5.7+/8.0+)
- my.cnf 关键参数
[mysqld]
server-id=1
log-bin=mysql-bin
binlog_format=ROW
gtid-mode=ON
enforce_gtid_consistency=ON
disabled_storage_engines=MyISAM,BLACKHOLE - 引导组复制(首个节点)
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'RplPass!';
GRANT REPLICATION SLA VE ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='RplPass!'
FOR CHANNEL 'group_replication_recovery';
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF; - 其他节点加入
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='RplPass!'
FOR CHANNEL 'group_replication_recovery';
START GROUP_REPLICATION; - 通过 MySQL Shell 创建集群、添加实例、检查状态:
dba.createCluster(...)、cluster.addInstance(...)、cluster.status()。
三、关键配置与最佳实践
- 复制与一致性
- 启用 GTID 简化切换与恢复;使用 ROW 格式减少不确定性。
- 半同步复制可提升故障切换时的数据安全性(需安装 semisync 插件并配置
rpl_semi_sync_master_enabled/rpl_semi_sync_sla ve_enabled)。
- 主主冲突避免
- 双主场景设置
auto_increment_offset/auto_increment_increment,确保自增主键不冲突;严格限制仅单点写入或使用分布式 ID。
- 双主场景设置
- 数据与切换安全
- 定期物理/逻辑备份(如 Percona XtraBackup),切换前确保从库追平或采用无损切换流程。
- 为应用提供 连接重试 与 熔断 机制,避免短时间抖动放大。
- 监控与告警
- 监控复制延迟(
Seconds_Behind_Master)、主从 IO/SQL 线程状态、VIP 漂移、连接数、慢查询等;关键指标阈值告警。
- 监控复制延迟(
四、常见陷阱与排查要点
- 复制中断常见原因
- 主从 server-id 冲突、DDL 不兼容、大事务/无主键导致 SQL 线程卡顿、网络抖动;优先检查
SHOW SLA VE STATUSG的 Last_Error/Exec_Master_Log_Pos。
- 主从 server-id 冲突、DDL 不兼容、大事务/无主键导致 SQL 线程卡顿、网络抖动;优先检查
- 脑裂与仲裁
- 主主或共享存储架构需引入仲裁与 fencing 策略,避免双主同时写入造成数据分裂。
- VIP 与网络
- 确保 VIP 所在网段与实例网卡一致,跨网段漂移需路由支持;防火墙放行 VRRP/HAProxy/MySQL 端口。
- 版本与参数
- 主从/组复制节点版本尽量一致;谨慎变更
binlog_format、gtid_mode等全局参数,变更前在测试环境验证。
- 主从/组复制节点版本尽量一致;谨慎变更