1. 为什么需要MySQL从库负载均衡在数据库架构设计中MySQL主从复制是常见的读写分离方案。但随着业务增长单一的从库往往难以承受所有读请求的压力。我曾经管理过一个电商系统在促销活动期间从库的CPU利用率长期保持在90%以上导致查询响应时间从平时的50ms飙升到800ms。这就是典型的从库性能瓶颈问题。LVSLinux Virtual Server配合Keepalived实现的负载均衡方案能够将读请求均匀分发到多个从库节点。这种架构带来三个核心优势横向扩展能力通过添加从库节点即可线性提升读性能我们曾经通过增加2个从库实例将QPS从5k提升到15k高可用保障当某个从库故障时LVS会自动剔除故障节点确保服务连续性透明访问应用层只需连接虚拟IP无需感知后端从库的增减变化2. LVSKeepalived架构解析2.1 核心组件分工在这个方案中各组件扮演着不同角色LVS作为四层负载均衡器工作在TCP层根据配置的调度算法如wrr将MySQL连接请求分发到后端Real ServerKeepalived实现高可用的关键通过VRRP协议维护VIP的漂移并在Director Server故障时自动切换Real Server实际的MySQL从库实例需要在本地回环接口绑定VIP2.2 DR模式的工作原理我们选择DRDirect Routing模式主要基于其性能优势。与NAT模式相比DR模式的数据包流向具有显著特点请求路径客户端 → Director ServerLVS→ Real ServerDirector Server只修改目标MAC地址不改变IP包内容响应路径Real Server → 客户端直接返回不经过Director Server这种非对称路径使得Director Server不会成为带宽瓶颈。在实际压力测试中DR模式比NAT模式的吞吐量高出3倍以上。3. 环境准备与配置细节3.1 基础环境规划建议使用以下服务器配置角色数量推荐配置网络要求LVS Director22C4G同一网段开启IP转发MySQL Real Server≥2根据负载需求确定绑定VIP到lo接口关闭ARP响应3.2 关键配置步骤3.2.1 Real Server配置每个MySQL从库需要执行以下配置# 创建Real Server启动脚本 cat /etc/init.d/realserver EOF #!/bin/bash VIP182.148.15.239 case $1 in start) echo 1 /proc/sys/net/ipv4/conf/lo/arp_ignore echo 2 /proc/sys/net/ipv4/conf/lo/arp_announce ifconfig lo:0 $VIP netmask 255.255.255.255 up route add -host $VIP dev lo:0 ;; stop) ifconfig lo:0 down route del $VIP /dev/null 21 ;; *) echo Usage: $0 {start|stop} exit 1 esac EOF # 设置权限并启动 chmod x /etc/init.d/realserver /etc/init.d/realserver start echo /etc/init.d/realserver start /etc/rc.local关键参数说明arp_ignore1只响应目标IP配置在接收网卡上的ARP请求arp_announce2始终使用网卡的最合适本地地址作为ARP源地址3.2.2 Director Server配置主备Director都需要安装ipvsadm和keepalived# 安装依赖 yum install -y ipvsadm keepalived # 开启IP转发 echo net.ipv4.ip_forward 1 /etc/sysctl.conf sysctl -pKeepalived配置示例主节点cat /etc/keepalived/keepalived.conf EOF ! Configuration File for keepalived global_defs { router_id LVS_MASTER } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 182.148.15.239 } } virtual_server 182.148.15.239 3306 { delay_loop 6 lb_algo wrr lb_kind DR persistence_timeout 50 protocol TCP real_server 192.168.1.101 3306 { weight 3 TCP_CHECK { connect_timeout 3 connect_port 3306 } } real_server 192.168.1.102 3306 { weight 2 TCP_CHECK { connect_timeout 3 connect_port 3306 } } } EOF4. 生产环境优化建议4.1 健康检查优化默认的TCP_CHECK只能检测端口可用性建议改用MYSQL_CHECKreal_server 192.168.1.101 3306 { weight 3 MYSQL_CHECK { connect_timeout 3 user monitor passwd password database test } }需要先在MySQL创建监控账号CREATE USER monitor% IDENTIFIED BY password; GRANT USAGE ON *.* TO monitor%;4.2 会话保持配置对于需要会话一致性的应用调整persistence_timeoutvirtual_server 182.148.15.239 3306 { persistence_timeout 300 # 5分钟会话保持 persistence_granularity 255.255.255.255 }4.3 监控指标采集建议监控以下关键指标LVS层面# 查看连接分布 ipvsadm -ln --stats # 查看每秒请求数 ipvsadm -ln --rateMySQL层面SHOW STATUS LIKE Threads_connected; SHOW STATUS LIKE Queries;5. 常见问题排查5.1 VIP无法访问排查步骤检查Director Server是否绑定了VIPip addr show验证Real Server的lo接口配置ifconfig lo:0测试基础网络连通性telnet VIP 33065.2 负载不均衡可能原因及解决方案权重设置不合理根据服务器配置调整weight参数会话保持时间过长适当减小persistence_timeout调度算法不合适对于短连接场景建议使用lc算法5.3 故障切换延迟优化建议减小advert_int值最低可设到1秒配置更敏感的健康检查超时TCP_CHECK { connect_timeout 2 retry 2 delay_before_retry 1 }6. 性能压测数据参考在我们的测试环境中使用3台MySQL从库16C32G配合LVS DR模式得到以下数据并发连接数平均QPS平均延迟CPU利用率50012,00045ms60%100028,00038ms75%200052,00042ms85%当单个从库故障时系统自动切换时间在3-5秒内完成期间仅有少量连接会报错。