MySQL如何在Linux上实现高可用
导读:在 Linux 上实现 MySQL 高可用的主流方案与落地步骤 一、方案总览与选型建议 方案 架构要点 自动故障切换 一致性 典型场景 复杂度 主从复制 + 虚拟 IP(Keepalived/HAProxy) 一主一备或一主...
在 Linux 上实现 MySQL 高可用的主流方案与落地步骤
一、方案总览与选型建议
| 方案 | 架构要点 | 自动故障切换 | 一致性 | 典型场景 | 复杂度 |
|---|---|---|---|---|---|
| 主从复制 + 虚拟 IP(Keepalived/HAProxy) | 一主一备或一主多从,应用通过 VIP 访问写库,读可扩展从库 | 是(Keepalived 检测与漂移) | 最终一致(异步复制) | 读写分离、读多写少 | 中 |
| 主主复制 + Keepalived | 双主互为主从,配合 auto_increment_offset/increment 避免主键冲突,单点写入 | 是(配合脚本/仲裁) | 最终一致(需谨慎冲突处理) | 双活写、就近写入 | 中高 |
| MHA(Master High Availability) | 一主多从,管理节点检测主库故障并提升新主,支持半同步 | 是 | 强一致倾向(配合半同步) | 高可用且需自动切换 | 中 |
| InnoDB Cluster / Group Replication(MGR) | 多节点组复制,多数派提交,内置故障转移 | 是 | 强一致(多数派) | 原生高可用、云原生友好 | 中高 |
| PXC(Percona XtraDB Cluster)/ Galera | 多主多写,基于认证的复制,几乎同步 | 是 | 强一致(几乎同步) | 多写、强一致需求 | 高 |
| 共享存储(Heartbeat + SAN/DRBD) | 共享块/存储,主备切换 | 是 | 强一致(取决于共享存储) | 传统企业环境 | 高(成本与复杂度) |
| 上述方案各有取舍,选型时优先考虑业务对一致性、写入并发、运维复杂度与成本的权衡。 |
二、快速落地路径
-
路径 A:主从复制 + Keepalived 实现自动切换(适合读多写少)
- 主库配置
- my.cnf
[mysqld] server-id=1 log-bin=mysql-bin binlog_format=ROW - 创建复制用户
CREATE USER 'repl'@'%' IDENTIFIED BY 'ReplPass!'; GRANT REPLICATION SLAVE 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 SLAVE; - 检查:
SHOW SLAVE STATUS\G,确保 Slave_IO_Running/Slave_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 SLAVE 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_slave_enabled)。
- 主主冲突避免
- 双主场景设置
auto_increment_offset/auto_increment_increment,确保自增主键不冲突;严格限制仅单点写入或使用分布式 ID。
- 双主场景设置
- 数据与切换安全
- 定期物理/逻辑备份(如 Percona XtraBackup),切换前确保从库追平或采用无损切换流程。
- 为应用提供 连接重试 与 熔断 机制,避免短时间抖动放大。
- 监控与告警
- 监控复制延迟(
Seconds_Behind_Master)、主从 IO/SQL 线程状态、VIP 漂移、连接数、慢查询等;关键指标阈值告警。
- 监控复制延迟(
四、常见陷阱与排查要点
- 复制中断常见原因
- 主从 server-id 冲突、DDL 不兼容、大事务/无主键导致 SQL 线程卡顿、网络抖动;优先检查
SHOW SLAVE STATUS\G的 Last_Error/Exec_Master_Log_Pos。
- 主从 server-id 冲突、DDL 不兼容、大事务/无主键导致 SQL 线程卡顿、网络抖动;优先检查
- 脑裂与仲裁
- 主主或共享存储架构需引入仲裁与 fencing 策略,避免双主同时写入造成数据分裂。
- VIP 与网络
- 确保 VIP 所在网段与实例网卡一致,跨网段漂移需路由支持;防火墙放行 VRRP/HAProxy/MySQL 端口。
- 版本与参数
- 主从/组复制节点版本尽量一致;谨慎变更
binlog_format、gtid_mode等全局参数,变更前在测试环境验证。
- 主从/组复制节点版本尽量一致;谨慎变更
声明:本文内容由网友自发贡献,本站不承担相应法律责任。对本内容有异议或投诉,请联系2913721942#qq.com核实处理,我们将尽快回复您,谢谢合作!
若转载请注明出处: MySQL如何在Linux上实现高可用
本文地址: https://pptw.com/jishu/768116.html
