MySQL如何在Linux上实现高可用

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

一、方案总览与选型建议

二、快速落地路径

• 路径A：通过主从复制和Keepalived来达成自动切换（这种方式比较适合读操作多而写操作少的情况）

  1. 主库配置
     • 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;
  2. 从库配置
     • 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。
  3. 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
  4. 应用侧将写库地址指向 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，即原生高可用方案）

  1. 三节点（建议奇数）安装同版本 MySQL（5.7+/8.0+）
  2. 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

  3. 引导组复制（首个节点）

     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;

  4. 其他节点加入

     CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='RplPass!'
       FOR CHANNEL 'group_replication_recovery';
     START GROUP_REPLICATION;

  5. 通过 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。
• 脑裂与仲裁
  • 主主或共享存储架构需引入仲裁与 fencing 策略，避免双主同时写入造成数据分裂。
• VIP 与网络
  • 确保 VIP 所在网段与实例网卡一致，跨网段漂移需路由支持；防火墙放行 VRRP/HAProxy/MySQL 端口。
• 版本与参数
  • 主从/组复制节点版本尽量一致；谨慎变更 binlog_format、gtid_mode 等全局参数，变更前在测试环境验证。