MySQL连接故障排查与高可用架构优化实践

1. 故障现象与初步排查

那天凌晨2点15分，我被刺耳的手机警报声惊醒。监控系统显示生产环境的订单服务全部报错，错误日志里清一色的"Could not create connection to database server"。作为负责数据库运维的老兵，我立刻意识到这是典型的MySQL连接故障。

第一反应是检查数据库服务器状态：

bash复制systemctl status mysql

结果显示服务是active (running)状态，这排除了MySQL进程崩溃的可能性。接着尝试本地连接：

bash复制mysql -uroot -p

输入密码后卡住，约30秒后返回"ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet'"。

关键提示：当MySQL服务进程存在但无法连接时，首先要区分是认证阶段还是连接建立阶段的问题。错误代码2013表明连接在初始握手阶段就已失败。

2. 网络层问题排查

2.1 基础网络连通性测试

使用telnet检查3306端口：

bash复制telnet 127.0.0.1 3306

发现连接被立即拒绝（Connection refused），这非常反常——如果端口未监听应该是超时，而拒绝连接通常意味着防火墙拦截。

检查iptables规则：

bash复制iptables -L -n

果然发现一条新增规则：

code复制REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

2.2 防火墙策略溯源

通过审计日志发现这条规则是安全团队在1小时前通过自动化工具推送的，本意是限制外部访问，但误将规则应用到了INPUT链而非特定的DOCKER链。临时解决方案：

bash复制iptables -D INPUT -j REJECT

立即恢复了连接，但这只是临时处置。真正的教训是：所有防火墙变更必须先在预发布环境验证，且要有自动回滚机制。

3. 连接数瓶颈分析

3.1 连接池爆满问题

虽然网络通了，但应用仍间歇性报"Too many connections"。查看最大连接数：

sql复制SHOW VARIABLES LIKE 'max_connections';

显示值为151，而监控显示峰值连接数达到149。这解释了为什么在业务高峰时会出现连接失败。

3.2 连接泄漏定位

使用processlist命令发现大量Sleep状态的连接：

sql复制SHOW PROCESSLIST;

结合应用日志分析，发现某服务在事务完成后没有正确关闭连接。临时调高参数：

sql复制SET GLOBAL max_connections=500;

并添加了连接池的validationQuery配置：

properties复制spring.datasource.validation-query=SELECT 1
spring.datasource.test-on-borrow=true

4. 高可用架构的隐藏风险

4.1 MHA切换后的连接残留

我们使用MHA（Master High Availability）实现MySQL高可用。故障切换后，原主库的连接状态没有完全清理，导致新连接被拒绝。通过添加以下配置解决：

ini复制[mysqld]
skip-name-resolve
wait_timeout=300
interactive_timeout=300

4.2 虚拟IP漂移延迟

MHA切换时VIP（Virtual IP）漂移耗时达到12秒，超过了应用连接池的超时设置。优化方案：

1. 使用keepalived替代MHA自带的VIP管理
2. 调整应用连接池参数：

yaml复制datasource:
  hikari:
    connection-timeout: 30000
    maximum-pool-size: 20
    idle-timeout: 600000

5. 深度防御措施实施

5.1 连接复用优化

引入ProxySQL实现连接池复用：

sql复制INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,'master-db',3306);
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;

5.2 全链路监控体系

部署了以下监控项：

1. MySQL可用性探针（每分钟执行SELECT 1）
2. 连接数时序监控（Graphana展示）
3. 慢查询实时告警（通过pt-query-digest）
4. 网络延迟热力图（基于Pingmesh）

6. 故障复盘与改进

这次事故暴露了三个关键问题：

1. 变更管理流程缺失防火墙规则测试环节
2. 连接数配置没有考虑业务增长趋势
3. 高可用切换的端到端测试不足

我们实施了以下改进：

• 建立数据库变更的灰度发布机制
• 每周进行连接压力测试
• 每月模拟MHA全自动切换演练
• 开发了连接泄漏检测工具，定期扫描未关闭的连接

这次故障让我深刻认识到：数据库连接问题从来不是单一技术点的问题，而是涉及网络、OS、中间件、应用代码、运维流程的系统工程。现在我们的监控看板上新增了一个黄金指标"端到端连接成功率"，必须保证99.99%的SLA。