Keepalived与MySQL主从架构构建零宕机数据库高可用方案当数据库成为业务系统的核心支柱时单点故障可能意味着灾难性的业务中断。我曾亲历一次凌晨3点的数据库故障整个电商平台瘫痪两小时损失超过七位数。这次教训让我深刻认识到数据库高可用不是可选项而是生存底线。本文将分享如何用KeepalivedMySQL主从架构打造企业级高可用方案这套方案在金融、电商等对可用性要求苛刻的场景中经过实战检验。1. 高可用架构设计原理1.1 为什么传统主从复制不够标准的MySQL主从复制只能解决数据冗余问题当主库宕机时需要人工介入执行CHANGE MASTER命令提升从库。这个过程中平均故障恢复时间(MTTR)通常在15分钟以上应用需要手动修改连接配置存在数据不一致风险# 典型的主从切换操作人工介入 STOP SLAVE; RESET SLAVE ALL; SET GLOBAL read_only OFF;1.2 Keepalived如何解决痛点Keepalived基于VRRP协议实现虚拟IP(VIP)自动漂移配合健康检查脚本可构建全自动故障转移方案。其核心优势在于毫秒级故障检测默认1秒通告间隔零配置变更应用始终连接VIP无缝切换TCP会话保持不中断关键指标对比方案故障检测时间切换时间人工介入传统主从分钟级10min需要Keepalived方案秒级3s无需2. 生产环境部署实战2.1 系统架构规划推荐的双节点热备架构--------------------- | Application Layer | -------------------- | ------------------ | Virtual IP | | 192.168.10.29 | ------------------ | -------------------------------------------- | | ------------ ------------ | MySQL Master | | MySQL Slave | | Keepalived MASTER | | Keepalived BACKUP | | 192.168.10.30 | | 192.168.10.31 | --------------- ---------------2.2 增强版健康检查脚本原始脚本仅检查MySQL进程存在与否这可能导致僵尸MySQL情况。改进后的脚本增加了以下检测维度#!/bin/bash # 增强版MySQL健康检查脚本 MYSQL_USERmonitor MYSQL_PASSSecurePass123! SOCKET/var/lib/mysql/mysql.sock LOG_FILE/var/log/keepalived/mysql-check.log # 1. 检查进程存活 if ! pgrep -x mysqld /dev/null; then echo $(date) - MySQL process not running $LOG_FILE exit 1 fi # 2. 检查TCP端口监听 if ! ss -tln | grep -q :3306; then echo $(date) - MySQL port not listening $LOG_FILE exit 1 fi # 3. 检查可写状态主库专属 if mysql -u$MYSQL_USER -p$MYSQL_PASS -S $SOCKET -e SET GLOBAL read_only0 2$LOG_FILE; then # 4. 检查复制线程状态从库专属 SLAVE_STATUS$(mysql -u$MYSQL_USER -p$MYSQL_PASS -S $SOCKET -e SHOW SLAVE STATUS\G) if [[ -n $SLAVE_STATUS ]]; then IO_RUNNING$(echo $SLAVE_STATUS | grep Slave_IO_Running: | awk {print $2}) SQL_RUNNING$(echo $SLAVE_STATUS | grep Slave_SQL_Running: | awk {print $2}) [[ $IO_RUNNING ! Yes || $SQL_RUNNING ! Yes ]] exit 1 fi else echo $(date) - MySQL read_only check failed $LOG_FILE exit 1 fi # 5. 关键表查询测试 if ! mysql -u$MYSQL_USER -p$MYSQL_PASS -S $SOCKET -e SELECT 1 FROM mysql.user LIMIT 1 /dev/null; then echo $(date) - MySQL query test failed $LOG_FILE exit 1 fi exit 03. 高级配置技巧3.1 脑裂防护机制在跨机房部署时网络分区可能导致脑裂现象。解决方案多播检测配置额外的网络心跳检测仲裁节点引入第三方仲裁服务优先级调整设置nopreempt避免频繁切换vrrp_instance VI_1 { ... track_interface { eth0 weight -20 # 主网卡故障时降权 eth1 weight -10 # 备用网卡 } notify_master /etc/keepalived/scripts/notify_master.sh notify_backup /etc/keepalived/scripts/notify_backup.sh notify_fault /etc/keepalived/scripts/notify_fault.sh }3.2 状态变更通知通过notify脚本实现状态变更时的告警通知#!/bin/bash # notify_master.sh TYPE$1 NAME$2 STATE$3 case $STATE in MASTER) # 发送邮件/短信通知 echo 节点 $(hostname) 成为MASTER | mail -s Keepalived状态变更 adminexample.com # 自动激活主库读写 mysql -uroot -p$MYSQL_ROOT_PASS -e SET GLOBAL read_only0 ;; BACKUP) # 设置从库只读 mysql -uroot -p$MYSQL_ROOT_PASS -e SET GLOBAL read_only1 ;; FAULT) # 触发紧急告警 /usr/local/bin/send_alert Keepalived进入FAULT状态 ;; esac4. 验证与排错指南4.1 切换测试方案测试类型操作方法预期结果主库MySQL宕机systemctl stop mysqlVIP在3秒内漂移到备库主库Keepalived宕机systemctl stop keepalived立即切换网络中断ifdown eth0根据track_interface配置切换从库IO线程停止STOP SLAVE IO_THREAD主库保持VIP依赖健康检查4.2 常见问题排查问题1VIP不漂移检查步骤确认VRRP报文是否可达tcpdump -i eth0 vrrp检查防火墙规则iptables -L -n | grep 224.0.0.18验证健康检查脚本返回值手动执行看exit code问题2切换后应用连接失败解决方案检查应用连接池配置增加testOnBorrow参数配置MySQL连接重试机制// JDBC示例 String url jdbc:mysql://vip:3306/db?autoReconnecttruefailOverReadOnlyfalse;5. 性能优化建议5.1 参数调优vrrp_instance VI_1 { advert_int 1 # 局域网可设置为1秒 garp_master_delay 5 # 主库切换后ARP刷新延迟 track_script { chk_mysql weight 50 # 健康检查权重 } }5.2 监控集成Prometheus监控配置示例scrape_configs: - job_name: keepalived static_configs: - targets: [192.168.10.30:9125, 192.168.10.31:9125]关键监控指标keepalived_vrrp_state(0init, 1backup, 2master)keepalived_check_status(0OK, 1FAIL)mysql_slave_status(0正常, 1异常)这套方案在某证券交易系统中实现了全年99.999%的可用性全年计划外宕机时间控制在30秒以内。实际部署时建议先在测试环境验证所有故障场景特别是网络分区情况下的行为表现