PyMySQL连接远程MySQL服务器出现2003超时错误排查求助

我遇到一个棘手问题，耗时数日仍未解决，寻求排查方向：

• GCP上部署两台运行MySQL 8的Debian虚拟机：Processing Server和History Server
• Processing Server每日处理约100万条消息，通过Python+PyMySQL将每条消息插入History Server的约6000张表中
• 系统正常运行近1个月后，突然每隔0-30分钟就收到History Server的连接超时错误：

  OperationalError(2003, "Can't connect to MySQL server on 'history.server' (timed out)")
  

已完成的排查动作 #

• 用PMM工具监控MySQL指标与日志，未发现MySQL相关异常，无明显资源峰值或低谷
• 排查MySQL及所有系统日志，未找到异常记录；虚拟机无配置变更，CPU、内存、磁盘资源无异常波动
• 测试脚本验证：循环执行触发超时的查询，可在0-10分钟内复现问题；仅打开/关闭MySQL连接不执行存储过程，仅出现短暂卡顿，不会触发超时

系统配置信息 #

History Server #

• OS：Debian GNU/Linux 11 (bullseye)
• RAM：12GB
• CPU：2vCPU，2线程/核心
• 磁盘：750GB 平衡型持久化磁盘
  • 单实例读IOPS：3000
  • 单实例写IOPS：3000
  • 单实例读吞吐量：140
  • 单实例写吞吐量：140
• 宿主：GCP Compute Engine

Processing Server #

• OS：Debian GNU/Linux 10 (buster)
• RAM：32GB
• CPU：8vCPU，2线程/核心
• 磁盘：1000GB SSD持久化磁盘
  • 单实例读IOPS：15000
  • 单实例写IOPS：9000
  • 单实例读吞吐量：240
  • 单实例写吞吐量：204
• 宿主：GCP Compute Engine

排查方向建议 #

网络层面（优先排查，因仅执行查询时触发超时） #

• GCP网络诊断
  • 在Processing Server上用mtr history.server -p 3306持续探测MySQL端口，记录丢包、延迟波动，重点核对超时时段的指标
  • 检查GCP VPC防火墙规则，确认3306端口入站规则无临时限流、会话数限制
  • 启用并分析GCP VPC Flow Logs，过滤两台实例间的流量，排查是否存在数据包丢弃、会话中断记录
• TCP连接参数
  • 在History Server上用tcpdump -i any port 3306抓包，超时发生时分析是否存在SYN包无响应、连接重置等异常
  • 检查两台实例的TCP参数：net.ipv4.tcp_tw_reuse、net.ipv4.tcp_fin_timeout、net.core.somaxconn，排查连接队列溢出或TIME_WAIT堆积问题

MySQL连接与查询层面 #

• 连接池与会话管理
  • 检查PyMySQL连接池配置（若使用），是否存在连接泄漏、池耗尽；尝试调整连接池大小、超时时间
  • 核对History Server的max_connections、wait_timeout、interactive_timeout参数，确认是否达到连接上限，或连接被回收时的异常
• 查询执行影响
  • 分析触发超时的查询/存储过程，是否存在长时间执行导致线程阻塞，进而占满连接资源（监控无峰值但可能存在瞬时阻塞）
  • 检查History Server的back_log参数，确认是否能应对批量插入场景的突发连接请求

系统隐性问题 #

• GCP宿主机层面
  • 尝试将History Server迁移到不同可用区或节点，排查宿主机资源竞争导致的网络响应延迟
  • 检查系统日志（/var/log/syslog），排查是否有网络接口重启、DNS解析异常记录
• 磁盘IO隐性延迟
  • 用iostat -x 1持续监控History Server磁盘的%util、await指标，确认批量插入6000张表时是否出现瞬时IO延迟突增，进而影响MySQL响应

内容的提问来源于stack exchange，提问作者Nagilum