ProxySQL中SSL错误导致客户端连接中断问题分析

问题背景

在使用ProxySQL 2.5.5版本(Percona打包)与MySQL 5.7.42-46(Percona)的环境中，多个客户端报告间歇性遇到"Lost connection to MySQL server during query"错误。这些客户端连接同时使用了加密和明文方式，而ProxySQL到MySQL服务器的连接则全部使用加密传输。

问题现象

当客户端向ProxySQL发送SELECT查询时，ProxySQL会突然关闭连接，导致客户端收到连接中断错误。通过tcpdump抓包分析发现，ProxySQL在收到客户端查询后会向MySQL服务器发送RST重置包，然后主动关闭前端连接。

深入分析

通过内核的tcp重置跟踪点和用户空间探针，我们发现问题的根源在于加密层错误处理不当：

1. 当出现加密错误时，ma_tls_async_check_result()函数返回SSL_ERROR_SSL错误
2. 这个错误会触发end_server()函数调用，导致连接被强制关闭
3. 进一步分析发现，加密库错误队列中记录了SSL_R_SHUTDOWN_WHILE_IN_INIT(407)错误
4. 这个错误来自SSL_shutdown()函数，当加密连接仍在初始化阶段时尝试关闭会触发此错误

问题根源

问题的核心在于ProxySQL没有正确处理加密错误队列。当某个客户端连接出现加密错误(如提供无效证书)时：

1. 加密库错误队列会被污染
2. 后续其他正常连接的加密操作会错误地获取到之前遗留的错误
3. 导致ProxySQL误判这些连接有问题而关闭它们
4. 这种错误会持续影响后续连接，需要多次重试才能恢复正常

解决方案

修复方案主要涉及三个关键点：

1. 在MySQL_Data_Stream析构函数中添加加密错误队列检查
2. 在MySQL_Data_Stream::shut_hard方法中添加加密错误处理
3. 在ma_tls_close函数中完善错误处理逻辑

这些修改确保在加密操作前后正确检查和清理错误队列，避免错误状态污染其他连接。

技术启示

这个案例揭示了几个重要的技术要点：

1. 加密库错误队列是全局性的，需要谨慎处理
2. 在加密操作前后应该检查并清理错误队列
3. 一个客户端的加密错误可能影响整个服务进程的其他连接
4. 网络中间件需要特别注意资源隔离和错误隔离

总结

ProxySQL的这个加密错误处理问题展示了中间件开发中资源隔离的重要性。通过修复加密错误队列的处理逻辑，可以有效防止单个问题客户端影响整个服务的稳定性。这也提醒开发者在实现加密功能时需要特别注意错误状态的清理和隔离。