当前位置：首页 > backend >正文

MySQL高可用架构

backend 2025/5/18 7:23:32

一、读写分离在高可用架构中的核心作用

1.读写分离与高可用的协同价值

在MySQL高可用架构中，读写分离不仅是性能优化的手段，更是提升系统容错能力的关键策略。通过将写操作（INSERT、UPDATE、DELETE） 集中到主节点，读操作（SELECT） 分散到多个从节点或双主节点，系统可实现以下目标：

负载均衡：避免单一节点因高并发读请求导致的性能瓶颈。
故障隔离：主节点故障时，读操作仍可由从节点继续处理，降低业务中断风险。
资源优化：充分利用从节点的计算资源，提升整体吞吐量。

2.读写分离在双主架构的实现特点

文档中的案例采用 MySQL双主复制（Master1 ↔ Master2） 架构，两节点互为主从，均支持读写操作。结合HAProxy的负载均衡能力，可通过以下方式实现读写分离：

静态分离：手动指定写操作路由到某一主节点，读操作均衡到双主节点。
动态分离：基于SQL类型自动路由请求（需HAProxy配置ACL规则）。

二、HAProxy在读写分离中的核心配置

1.HAProxy的负载均衡机制

HAProxy作为反向代理，通过监听客户端请求并将其分发至后端MySQL节点，支持多种负载均衡算法（如轮询、最少连接数）。在读写分离场景中，需通过配置区分写请求与读请求的路由逻辑

listen mysqlbind 0.0.0.0:3306mode tcpbalance leastconnserver mysql1 192.168.10.101:3306 check port 3306 maxconn 300server mysql2 192.168.10.102:3306 check port 3306 maxconn 300

当前配置的局限性：

默认将所有请求（包括读写）均衡分发到双主节点，未显式区分读写操作。

改进方向：

需通过ACL规则识别SQL类型，将写请求定向到指定主节点，读请求分发到所有节点。

2.实现读写分离的进阶配置

步骤1：定义前端规则区分读写请求

frontend mysql_frontendbind *:3306mode tcp# 定义ACL规则识别写请求（如包含INSERT/UPDATE/DELETE关键字）acl is_write payload(0,7) -m bin 494e53455254 555044415445 44454c455445# 路由写请求至主节点组use_backend master_group if is_write# 默认路由读请求至从节点组default_backend slave_group

步骤2：定义后端服务器组

backend master_groupmode tcpserver master1 192.168.10.101:3306 checkserver master2 192.168.10.102:3306 check backup  # 主节点故障时切换backend slave_groupmode tcpbalance roundrobinserver slave1 192.168.10.101:3306 checkserver slave2 192.168.10.102:3306 check

关键参数说明：
- acl is_write:通过二进制匹配SQL语句前7字节，识别常见写操作关键字（如INSERT的十六进制为494e53455254）。
- use_backend:根据ACL条件选择后端组。
- backup：标记备用节点，仅在主节点不可用时启用。

步骤3：启用HAProxy的日志与健康检查

globallog /dev/log local0log-tag HAProxy-MySQLdefaultslog globaloption tcplogtimeout client 30stimeout server 30stimeout connect 5s

三、双主架构下的数据一致性保障

1.双主复制的同步机制

双主架构中，数据同步依赖MySQL的二进制日志（Binlog）与GTID（全局事务标识），确保事务在双节点间有序执行：

基于行的复制：记录数据行的变更，避免因函数或随机值导致的主从不一致。
并行复制：从库的SQL线程多线程重放事件，减少同步延迟。

配置优化建议

# 在my.cnf中配置
binlog_format = ROW           # 使用行级复制
gtid_mode = ON                # 启用GTID
enforce_gtid_consistency = ON # 强制GTID一致性
slave_parallel_workers = 4    # 并行复制线程数

2.冲突检测与解决策略

双主架构可能因同时写入相同数据引发冲突，需通过以下方式规避：

业务层分片：按业务维度划分数据写入范围（如用户ID取模）。
自增ID偏移：设置不同的自增步长（如Master1自增ID为奇数，Master2为偶数）。

# Master1配置
auto_increment_increment = 2
auto_increment_offset = 1# Master2配置
auto_increment_increment = 2
auto_increment_offset = 2

四、Keepalived与HAProxy的高可用协同

1.keepalived的VIP漂移机制

Keepalived通过VRRP协议管理虚拟IP（VIP），监控HAProxy进程状态，实现故障自动转移：

健康检查脚本：定期检测HAProxy进程存活状态。
优化级策略：节点优先级决定VIP归属，主节点故障时备用节点接管。

文档中的Keepalived配置解析

vrrp_instance VI_1 {state BACKUPinterface ens33virtual_router_id 51priority 100  # Keepalived1优先级高于Keepalived2（99）virtual_ipaddress {192.168.10.100}track_script {chk_haproxy}
}

nopreempt:禁止优先级高的节点恢复后抢占VIP，避免频繁切换。
notify_backup/notify_fault：状态变更时触发HAProxy重启或停止，确保服务连贯性

2.读写分离与VIP的结合优化

写请求的VIP绑定：应用层通过VIP连接数据库，写请求自动路由至当前主节点。
读请求的负载均衡：HAProxy根据后端节点健康状态动态调整流量分配。

五、读写分离的验证与性能测试

1.功能性验证

步骤1：写入数据验证

-- 通过VIP执行写操作
INSERT INTO orders (user_id, amount) VALUES (1001, 150.00);

验证点：数据应同步至双主节点，通过SHOW SLAVE STATUS确认复制状态。

步骤2：读请求分发验证

-- 多次执行读操作
SELECT * FROM orders WHERE user_id = 1001;

验证点：通过HAProxy日志或SHOW PROCESSLIST确认请求分发至不同节点。

2.性能压测工具与指标

工具选择：
- SysBench：模拟OLTP读写混合场景。
- JMeter：定制化SQL请求压测。
关键指标：
- 吞吐量（TPS）：单位时间处理的读写请求数。
- 平时延迟（Latency）：请求从发起到响应的平均耗时。
- 错误率：失败请求占比，反映系统稳定性。

# SysBench读写混合测试
sysbench oltp_read_write \
--mysql-host=192.168.10.100 \
--mysql-port=3306 \
--mysql-user=test \
--mysql-password=123456 \
--mysql-db=test \
--tables=10 \
--table-size=100000 \
--threads=32 \
--time=300 \
--report-interval=10 \
run