MySQL如何在Linux上实现高可用 - 问答

在 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

[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。

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 实现一主多从的自动故障转移（适合需要自动选主的场景）
1. 架构：一主两从 + MHA Manager 节点
2. 主从复制按路径 A 配置；确保开启 GTID 或记录准确位点
3. 在 MHA Manager 节点安装与配置：定义节点、复制用户、SSH 免密、候选主等
4. 启动监控：masterha_manager --conf=/etc/mha/app1.cnf
5. 故障切换后执行 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。
脑裂与仲裁
- 主主或共享存储架构需引入仲裁与 fencing 策略，避免双主同时写入造成数据分裂。
VIP 与网络
- 确保 VIP 所在网段与实例网卡一致，跨网段漂移需路由支持；防火墙放行 VRRP/HAProxy/MySQL 端口。
版本与参数
- 主从/组复制节点版本尽量一致；谨慎变更 binlog_format、gtid_mode 等全局参数，变更前在测试环境验证。

0 赞

0 踩