商城首页欢迎来到中国正版软件门户

您的位置: 首页 > 文章列表 > 系统应用 > MySQL如何在Linux上实现高可用

MySQL如何在Linux上实现高可用

  发布于2026-08-22 阅读(0)

扫一扫,手机访问

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

MySQL如何在Linux上实现高可用

一、方案总览与选型建议

方案架构要点自动故障切换一致性典型场景复杂度主从复制 + 虚拟 IP(Keepalived/HAProxy)一主一备或一主多从,应用通过 VIP 访问写库,读可扩展从库是(Keepalived 检测与漂移)最终一致(异步复制)读写分离、读多写少中主主复制 + Keepalived双主互为主从,配合 auto_increment_offset/increment 避免主键冲突,单点写入是(配合脚本/仲裁)最终一致(需谨慎冲突处理)双活写、就近写入中高MHA(Master High A vailability)一主多从,管理节点检测主库故障并提升新主,支持半同步是强一致倾向(配合半同步)高可用且需自动切换中InnoDB Cluster / Group Replication(MGR)多节点组复制,多数派提交,内置故障转移是强一致(多数派)原生高可用、云原生友好中高PXC(Percona XtraDB Cluster)/ Galera多主多写,基于认证的复制,几乎同步是强一致(几乎同步)多写、强一致需求高共享存储(Heartbeat + SAN/DRBD)共享块/存储,主备切换是强一致(取决于共享存储)传统企业环境高(成本与复杂度)上述方案各有取舍,选型时优先考虑业务对一致性写入并发运维复杂度成本的权衡。

二、快速落地路径

  • 路径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 STATUSGLast_Error/Exec_Master_Log_Pos
  • 脑裂与仲裁
    • 主主或共享存储架构需引入仲裁与 fencing 策略,避免双主同时写入造成数据分裂。
  • VIP 与网络
    • 确保 VIP 所在网段与实例网卡一致,跨网段漂移需路由支持;防火墙放行 VRRP/HAProxy/MySQL 端口。
  • 版本与参数
    • 主从/组复制节点版本尽量一致;谨慎变更 binlog_formatgtid_mode 等全局参数,变更前在测试环境验证。
本文转载于:https://www.yisu.com/ask/51923317.html 如有侵犯,请联系zhengruancom@outlook.com删除。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。

产品推荐