我有一个奇怪的，我花了几天没有任何运气。来这里是希望有人能给我指个方向或者看到类似的东西。
所以，我在GCP上有两个运行MySQL 8的Debian虚拟机，分别称为“处理服务器”和“历史服务器”。Processing Server每天处理约100万条消息，并将每条消息插入到History Server上约6000个表中的一个表中（使用python w/ pyMySQL）。这已经运行了近一个月的罚款w/o一个问题，然后突然每0-30分钟我得到连接超时从历史服务器
OperationalError（2003，“无法连接到'history.server'上的MySQL服务器（超时）”）。
我正在使用PMM，并在这段时间里挖掘了我所有的指标/日志，没有发现任何与MySQL相关的东西（没有任何明显的奇怪的峰值或下降，没有这个或那个的峰值...）。
在挖掘了MySQL和所有可用的日志，寻找任何相关性，我认为这是与网络或服务器的问题，但我不知道在哪里寻找。我使用的是运行Debian的GCP虚拟机，我不认为在这个问题发生的时候有什么变化。我在VM上查看的各种日志中也没有看到任何明显的问题。我没有看到任何资源峰值（磁盘、RAM、CPU）。这很奇怪，因为我的python连接器似乎只是偶尔无法连接到服务器。我知道这是一个很长的机会，但有人有一个方向，他们可能会看看？很高兴提供更多可能有用的信息。
我在“处理服务器”上创建了一个测试脚本，该脚本使用失败的相同查询命中历史服务器，我可以在0-10分钟内给予此超时连接错误，只是在循环中发送查询。如果我让同一个程序打开和关闭一个到mysql的连接，而不执行存储过程，我会看到它停留了几秒钟，但通常不会长到触发相同的超时。
不知道该去哪里找。我希望在MySQL中有一个地方，我可以看到被拒绝/失败的连接，并试图将其与任何东西关联起来。没有任何图表或日志，我有我似乎显示任何有意义的模式。

系统数据：

历史记录服务器

- OS
    - Debian GNU/Linux 11 (bullseye)
- RAM
    - 12GB
- Cores
    - 2vCPU
    - 2 Threads/Core
- DISK
    - 750GB "Balanced persistent disk"
    - Read IOPS per instance       : 3,000
    - Write IOPS per instance      : 3,000
    - Read throughput per instance : 140
    - Write throughput per instance: 140
- Host Server
    - GCP Compute Engine
- Data Dumps:
    - Table Info: https://justpaste.it/3qapn
    - Global Status: https://justpaste.it/dfm6j
    - Global Variables: https://justpaste.it/87sl8
    - Process List: https://justpaste.it/3xh3f
    - Status: https://justpaste.it/1oka4
    - Innodb Status: https://justpaste.it/3wdck

字符串

处理服务器

- OS
    - Debian GNU/Linux 10 (buster)
- RAM
    - 32GB
- Cores
    - 8vCPU
    - 2 Threads/Core
- DISK
    - 1,000GB "SSD persistent disk"
    - Read IOPS per instance       : 15,000
    - Write IOPS per instance      : 9,000
    - Read throughput per instance : 240
    - Write throughput per instance: 204
- Host Server
    - GCP Compute Engine
- Data Dumps:
    - Table Info: https://justpaste.it/8o85k
    - Global Status: https://justpaste.it/7eukf
    - Global Variables: https://justpaste.it/df3z4
    - Process List: https://justpaste.it/bl4u2
    - Status: https://justpaste.it/4b0dj
    - Innodb Status: https://justpaste.it/91z2g

型
我已经翻阅了所有可用的系统和MySQL日志，使用Percona的管理和监控工具来寻找峰值或低谷、最大值或最小值，并使用“top”以及GCP的云计算监控来查看资源，所有这些都没有运气。我发现查询超时的时间戳与这些来源中的任何重要内容之间没有关联。并没有明显的规律。超时之间的计时也没有模式（超时之间的时间在0到30分钟之间，但没有一致的时间）。