一、核心认知：MySQL高可用集群的意义

MySQL单节点架构存在单点故障风险，一旦节点宕机，会导致业务中断、数据丢失，尤其在电商、金融等对服务连续性要求极高的场景，高可用集群是刚性需求。本次笔记聚焦「MySQL主主复制+Keepalived虚拟IP漂移+HAProxy负载均衡」的经典架构，通过组件协同实现“故障自动切换、流量负载均衡、数据冗余一致”，核心目标是实现服务零停机、数据零丢失，保障业务连续性。

核心组件分工：

• MySQL主主复制：实现双节点数据双向同步，提供数据冗余，避免单节点数据丢失，同时支持双节点读写扩展；

• Keepalived：基于VRRP协议管理虚拟IP（VIP），监控集群节点状态，故障时实现VIP自动漂移，保证业务访问地址不变；

• HAProxy：作为负载均衡器，分发客户端请求至MySQL节点，实现读写分离（可选），同时进行节点健康检查，自动剔除故障节点。

二、MySQL主主复制（Master-Master）搭建与原理

2.1 主主复制核心原理

主主复制本质是两台MySQL实例互为主从，双向同步数据——节点A既是节点B的主库，也是节点B的从库；节点B同理。所有数据变更会在两个节点间相互同步，既解决了单节点故障的数据冗余问题，也支持双节点并发读写（需规避数据冲突）。

核心依赖组件：

• 二进制日志（binlog）：主节点将所有数据变更操作以“事件”形式写入binlog，是复制的数据源；

• I/O线程：从节点通过I/O线程连接主节点，读取主节点的binlog，写入本地中继日志（relay log）；

• SQL线程：从节点通过SQL线程读取中继日志，执行其中的SQL事件，实现与主节点数据一致；

• GTID模式：推荐开启，通过全局事务ID确保复制的一致性和可追溯性，简化故障切换时的同步配置。

2.2 主主复制搭建步骤（以MySQL 8.0为例）

2.2.1 环境准备

准备两台配置相同的服务器，确保：

• 两台服务器安装相同版本的MySQL（推荐5.7+或8.0+）；

• 网络互通（能ping通，且3306端口开放）；

• 关闭防火墙/SELinux（或放行3306端口）；

• 两台服务器的server-id必须不同（核心要求，用于区分节点）。

假设服务器信息：

• 假设服务器信息如下：服务器A的IP地址为192.168.1.100，角色为Master1/Slave2，server-id设为1；服务器B的IP地址为192.168.1.101，角色为Master2/Slave1，server-id设为2。两台服务器配置保持一致，仅通过server-id区分节点身份，为后续主主复制配置奠定基础。

2.2.2 配置MySQL配置文件（my.cnf）

MySQL配置文件通常在/etc/my.cnf（CentOS/RHEL）或/etc/mysql/my.cnf（Ubuntu/Debian），两台服务器分别配置如下：

服务器A（192.168.1.100）配置：

• server-id=1 # 唯一标识，不可与另一节点重复 auto_increment_offset=1 # 自增ID起始值 auto_increment_increment=2 # 每次自增步长，避免双节点写入主键冲突 log-bin = mysql-bin # 开启二进制日志，主库必须开启 max_binlog_size=1024M # binlog单文件最大值 log_slave_updates = ON # 必须开启，确保互备时事务日志传递 binlog_format = ROW # 推荐ROW模式，复制更安全 gtid_mode = ON # 启用GTID模式 enforce_gtid_consistency = ON # 强制GTID一致性检查 slave-skip-errors=all # 跳过复制过程中的错误（生产环境需谨慎） # 可选：指定同步/忽略的数据库/表 replicate-do-db=test_db # 仅同步test_db数据库 replicate-ignore-table=test_db.sys_log # 忽略test_db库的sys_log表

服务器B（192.168.1.101）配置：

• server-id=2 # 唯一标识，与服务器A不同 auto_increment_offset=2 # 自增ID起始值，与服务器A错开 auto_increment_increment=2 # 自增步长，与服务器A一致 log-bin = mysql-bin max_binlog_size=1024M log_slave_updates = ON binlog_format = ROW gtid_mode = ON enforce_gtid_consistency = ON slave-skip-errors=all replicate-do-db=test_db replicate-ignore-table=test_db.sys_log

配置完成后，重启两台服务器的MySQL服务：

• # CentOS/RHEL 7+ systemctl restart mysqld # Ubuntu/Debian systemctl restart mysql

2.2.3 创建复制专用账号

在两台服务器上分别创建用于复制的账号（遵循权限最小化原则，仅授予复制权限）：

服务器A上执行（给服务器B授权）：

• CREATE USER 'repl'@'192.168.1.101' IDENTIFIED BY 'Repl@123456'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.101'; FLUSH PRIVILEGES; SHOW MASTER STATUS; # 记录File（binlog文件名）和Position（偏移量），后续配置用

服务器B上执行（给服务器A授权）：

• CREATE USER 'repl'@'192.168.1.100' IDENTIFIED BY 'Repl@123456'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.100'; FLUSH PRIVILEGES; SHOW MASTER STATUS; # 同样记录File和Position

2.2.4 配置互为从库

先删除两台服务器上的旧日志文件（从当前开始同步，避免旧日志干扰）：

• rm -rf mysql-bin.* rm -rf localhost-relay-bin.*

然后分别配置两台服务器互为从库：

服务器A上配置（将服务器B设为主库）：

• RESET MASTER; CHANGE MASTER TO MASTER_HOST='192.168.1.101', MASTER_USER='repl', MASTER_PASSWORD='Repl@123456', MASTER_AUTO_POSITION=1; # 开启GTID自动定位，无需手动输入File和Position START SLAVE;

服务器B上配置（将服务器A设为主库）：

• RESET MASTER; CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_USER='repl', MASTER_PASSWORD='Repl@123456', MASTER_AUTO_POSITION=1; START SLAVE;

2.2.5 验证主主复制

在两台服务器上分别执行以下命令，检查复制状态：

• SHOW SLAVE STATUS\G;

关键检查项：确保 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes，说明复制正常。可在其中一台服务器创建表、插入数据，查看另一台服务器是否同步成功，验证双向复制有效性。

三、Keepalived虚拟IP（VIP）漂移配置与原理

3.1 Keepalived核心原理

Keepalived是一款开源高可用工具，核心基于VRRP（虚拟路由冗余协议）实现VIP的自动故障转移。其核心思想是将多台服务器组成一个虚拟路由器组，对外暴露一个VIP，客户端仅感知VIP，无需关心具体物理节点的切换，从而避免单点故障（如HAProxy节点宕机）导致的服务中断。

核心角色与机制：

• Master（主节点）：优先级最高，实际持有VIP，负责处理所有流量，定期发送心跳报文（默认1秒/次）告知Backup节点自身存活；

• Backup（备份节点）：监控Master节点的心跳，若超时（默认3秒）未收到心跳，判定Master故障，自动选举为新Master，接管VIP；

• VRRP实例：定义参与高可用的节点组，关联VIP，配置节点优先级、心跳间隔、认证信息等核心参数；

• 健康检查：支持应用层健康检查（如检查MySQL、HAProxy状态），若服务异常，自动降低节点优先级，触发故障切换。

3.2 Keepalived安装与配置（两台HAProxy节点）

假设HAProxy节点信息（与MySQL主主节点可复用，也可独立部署）：

HAProxy节点具体信息如下：HAProxy1的IP地址为192.168.1.102，角色为Keepalived Master，优先级设为100；HAProxy2的IP地址为192.168.1.103，角色为Keepalived Backup，优先级设为80。这两台HAProxy节点可与MySQL主主节点复用服务器，也可独立部署，共同配合Keepalived实现VIP漂移和负载均衡高可用。

VIP地址：192.168.1.200（对外提供统一访问入口）

3.2.1 安装Keepalived

• # CentOS/RHEL yum install keepalived -y # Ubuntu/Debian apt install keepalived -y

3.2.2 配置Keepalived（主节点HAProxy1）

编辑配置文件 /etc/keepalived/keepalived.conf：

• ! Configuration File for keepalived global_defs { router_id LVS_MYSQL # 全局唯一标识，可自定义 vrrp_skip_check_adv_addr vrrp_garp_interval 1 vrrp_gna_interval 1 } # 配置VRRP实例，关联VIP vrrp_instance VI_1 { state MASTER # 主节点设为MASTER，备节点设为BACKUP interface eth0 # 绑定的网络接口（需根据实际服务器修改） virtual_router_id 51 # VRRP组ID，主备节点必须一致 priority 100 # 优先级，主节点高于备节点 advert_int 1 # 心跳间隔（1秒） # 认证配置，主备节点需一致 authentication { auth_type PASS auth_pass 1111 # 认证密码，自定义 } # 虚拟IP地址（VIP） virtual_ipaddress { 192.168.1.200/24 dev eth0 label eth0:0 # 绑定VIP到网卡 } # 可选：健康检查脚本（检查HAProxy是否存活） track_script { check_haproxy } } # 健康检查脚本定义 vrrp_script check_haproxy { script "/etc/keepalived/check_haproxy.sh" # 脚本路径 interval 2 # 检查间隔（2秒） weight -20 # 检查失败，优先级降低20 }

3.2.3 配置Keepalived（备节点HAProxy2）

与主节点配置基本一致，仅修改state和priority：

• ! Configuration File for keepalived global_defs { router_id LVS_MYSQL vrrp_skip_check_adv_addr vrrp_garp_interval 1 vrrp_gna_interval 1 } vrrp_instance VI_1 { state BACKUP # 备节点设为BACKUP interface eth0 virtual_router_id 51 # 与主节点一致 priority 80 # 优先级低于主节点 advert_int 1 authentication { auth_type PASS auth_pass 1111 # 与主节点一致 } virtual_ipaddress { 192.168.1.200/24 dev eth0 label eth0:0 } track_script { check_haproxy } } vrrp_script check_haproxy { script "/etc/keepalived/check_haproxy.sh" interval 2 weight -20 }

3.2.4 编写健康检查脚本（两台节点均执行）

• vim /etc/keepalived/check_haproxy.sh # 脚本内容 #!/bin/bash # 检查HAProxy进程是否存活 if ! ps -ef | grep -v grep | grep haproxy > /dev/null; then # HAProxy未存活，停止Keepalived，触发VIP漂移 systemctl stop keepalived fi # 给脚本添加执行权限 chmod +x /etc/keepalived/check_haproxy.sh

3.2.5 启动Keepalived并验证

• # 启动并设置开机自启 systemctl start keepalived systemctl enable keepalived # 查看VIP绑定情况（主节点执行） ip a | grep 192.168.1.200

验证VIP漂移：停止主节点（HAProxy1）的Keepalived服务（systemctl stop keepalived），在备节点（HAProxy2）执行ip a命令，查看VIP是否漂移至192.168.1.103；恢复主节点服务后，VIP会自动漂移回主节点（默认抢占模式，可配置nopreempt关闭抢占）。

四、HAProxy负载均衡配置与原理

4.1 HAProxy核心原理

HAProxy是一款高性能的开源负载均衡器，支持TCP（四层）和HTTP（七层）代理，适用于MySQL等TCP协议服务。其核心作用是将客户端请求分发至后端MySQL节点，实现负载均衡，同时通过健康检查剔除故障节点，确保流量仅路由至正常节点，配合Keepalived实现负载均衡器的高可用。

MySQL集群中HAProxy的核心功能：

• 负载均衡：支持轮询、权重、最少连接等策略，分发读/写请求至两台MySQL主节点；

• 健康检查：定期检测MySQL节点的3306端口和服务状态，自动剔除故障节点，故障恢复后自动重新加入集群；

• 读写分离（可选）：将写请求路由至其中一台主节点，读请求分发至两台主节点，提升集群读写性能；

• 透明代理：客户端仅需连接HAProxy的VIP，无需关心后端MySQL节点的具体IP，降低运维复杂度。

4.2 HAProxy安装与配置（两台HAProxy节点均执行）

4.2.1 安装HAProxy

• # CentOS/RHEL yum install haproxy -y # Ubuntu/Debian apt install haproxy -y

4.2.2 配置HAProxy（核心配置）

编辑配置文件 /etc/haproxy/haproxy.cfg，替换原有内容为以下配置（适配MySQL负载均衡）：

• global log 127.0.0.1 local0 info maxconn 1000 # 最大并发连接数 user haproxy group haproxy daemon # 后台运行 defaults log global mode tcp # MySQL使用TCP模式 option tcplog option dontlognull retries 3 # 连接失败重试次数 timeout connect 5000ms # 连接超时时间 timeout client 50000ms # 客户端超时时间 timeout server 50000ms # 服务器超时时间 # 配置MySQL负载均衡集群 listen mysql_cluster bind 0.0.0.0:3306 # 监听3306端口（与MySQL端口一致） mode tcp balance roundrobin # 负载均衡策略：轮询（可选leastconn、source等） option mysql-check user haproxy_check # 健康检查用户（需在MySQL创建） # 后端MySQL节点（主主复制的两台节点） server mysql1 192.168.1.100:3306 check port 3306 inter 2000 rise 2 fall 3 server mysql2 192.168.1.101:3306 check port 3306 inter 2000 rise 2 fall 3 # 可选：配置HAProxy管理页面（查看集群状态） listen stats bind 0.0.0.0:8080 # 管理页面端口 mode http stats enable stats uri /haproxy_stats # 管理页面路径 stats auth admin:admin # 管理页面账号密码

4.2.3 创建HAProxy健康检查用户（MySQL节点执行）

在两台MySQL主节点上分别创建健康检查专用用户（无需实际权限，仅用于HAProxy检测）：

• CREATE USER 'haproxy_check'@'%' IDENTIFIED BY ''; # 无密码，仅用于健康检查 FLUSH PRIVILEGES;

4.2.4 启动HAProxy并验证

• # 检测配置文件正确性 haproxy -c -f /etc/haproxy/haproxy.cfg # 启动并设置开机自启 systemctl start haproxy systemctl enable haproxy # 验证：通过VIP连接MySQL（客户端执行） mysql -u root -p -h 192.168.1.200 -P 3306

若能成功登录，说明HAProxy配置生效，可通过HAProxy管理页面（http://192.168.1.200:8080/haproxy_stats）查看集群状态、节点健康情况和请求分发情况。

五、四大组件协同机制

「MySQL主主复制+Keepalived+HAProxy」的协同核心是“数据冗余+故障自动切换+流量负载均衡”，四者分工明确、联动配合，确保集群高可用，完整协同流程如下：

5.1 正常运行状态下的协同

• 数据同步：MySQL主主复制正常运行，两台MySQL节点（192.168.1.100、192.168.1.101）双向同步数据，确保数据一致，互为冗余；

• VIP绑定：Keepalived主节点（HAProxy1，192.168.1.102）持有VIP（192.168.1.200），定期向备节点（HAProxy2）发送心跳，告知自身存活；

• 流量分发：客户端通过VIP（192.168.1.200:3306）连接集群，HAProxy接收请求后，根据轮询策略将请求分发至两台MySQL节点，实现负载均衡；

• 健康检查：HAProxy定期检测两台MySQL节点的3306端口状态，Keepalived定期检测HAProxy服务状态，确保所有组件正常运行。

5.2 故障场景下的协同（核心流程）

场景1：其中一台MySQL节点故障（如192.168.1.100宕机）

• HAProxy通过健康检查（定期检测3306端口）发现MySQL1节点故障，立即将其从负载列表中剔除，不再向其分发请求；

• 所有客户端请求通过HAProxy自动分发至正常的MySQL2节点（192.168.1.101），业务不受影响；

• MySQL主主复制暂停（故障节点无法同步数据），待MySQL1节点恢复后，重新启动MySQL服务，主主复制自动恢复，同步故障期间MySQL2节点的数据，恢复后HAProxy自动将其重新加入负载列表。

场景2：HAProxy主节点故障（如HAProxy1，192.168.1.102宕机）

• Keepalived备节点（HAProxy2）超时未收到主节点的心跳报文，判定主节点故障，自动切换为新Master；

• VIP（192.168.1.200）自动漂移至HAProxy2节点（192.168.1.103），客户端无需修改连接地址，仍通过VIP访问集群；

• HAProxy2继续履行负载均衡职责，将请求分发至正常的MySQL节点，业务不受中断；

• 待HAProxy1节点恢复后，重启Keepalived和HAProxy服务，自动成为Keepalived备节点，VIP漂移回HAProxy1（默认抢占模式），恢复正常运行状态。

场景3：MySQL双节点同时故障（极端场景）

此时集群无法提供服务，需立即恢复至少一台MySQL节点，重启后通过主主复制同步数据，HAProxy和Keepalived自动恢复正常，客户端重新通过VIP访问。（实际生产中可增加MySQL节点数量，降低双节点同时故障的概率）

5.3 协同核心要点

• 主主复制是基础：确保数据冗余，避免单节点故障导致数据丢失，是故障切换的前提；

• Keepalived保障入口高可用：通过VIP漂移，确保HAProxy节点故障时，客户端访问地址不变，实现“无缝切换”；

• HAProxy实现流量分发：避免单台MySQL节点负载过高，同时自动剔除故障节点，减少人工干预；

• 健康检查是关键：Keepalived检查HAProxy状态，HAProxy检查MySQL状态，双重检查确保集群组件均处于正常运行状态，快速响应故障。

六、常见问题与注意事项

• 主主复制冲突：避免两台MySQL节点同时写入同一行数据，可通过分库分表、自增ID偏移（auto_increment_offset/auto_increment_increment）规避；

• VIP漂移失败：检查Keepalived配置（virtual_router_id、认证密码、网络接口），确保主备节点网络互通，心跳正常；

• HAProxy健康检查失败：确认MySQL健康检查用户创建正确，3306端口开放，MySQL服务正常运行；

• 数据一致性：开启GTID模式，确保复制的一致性，故障切换后避免数据丢失；生产环境建议开启半同步复制，平衡性能与数据一致性；

• 权限控制：复制专用用户、健康检查用户仅授予必要权限，避免权限过高导致安全风险。

七、总结

本次笔记覆盖MySQL高可用集群的核心组件（主主复制、Keepalived、HAProxy）的搭建、原理及协同机制，该架构基于开源工具，无厂商锁定，部署成本低、运维友好，可实现秒级故障切换、零业务中断，适用于中小至中大型企业的核心业务需求。

核心逻辑：主主复制做数据冗余，HAProxy做流量分发，Keepalived做VIP漂移，三者协同形成“数据-流量-入口”的全链路高可用，解决MySQL单节点故障的痛点，保障业务连续性和数据安全性。