在 Google Cloud SQL 中读取通信数据包时出错

Question

从 3 月 31 日开始，我在 Google Cloud SQL 中遇到以下错误：

读取通信数据包时出错。

我已经使用 Google Cloud SQL 2 年了，但从未遇到过这样的问题。我很担心。

这是详细的错误消息：

textPayload:  "2019-04-29T17:21:26.007574Z 203385 [Note] Aborted connection 203385 to db: {db_name} user: {db_username} host: 'cloudsqlproxy~{private ip}' (Got an error reading communication packets)"

Answer 1

虽然此错误消息确实经常在维护期后出现，但这不一定是值得关注的原因，因为这是 MySQL 的已知行为。

关于此问题发生原因的可能解释是：

1. 实例的连接请求大量增加，活跃连接数在短时间内不断增加。由于在很短的时间间隔内发生连接突发，也可能会发生实例的冻结/不可用。据观察，这种冻结总是随着连接请求的增加而发生。连接数的增加会导致实例过载，因此无法响应进一步的连接请求，直到连接数减少或实例稳定为止。
2. 服务器太忙而无法接受新连接。
3. 以前的连接未正确关闭的比例很高。
4. 客户端异常终止。
5. readTimeoutMySQL 驱动程序中的设置设置得太低。
6. 在文档的摘录中，指出：

连接尝试失败的原因有很多。网络通信永远无法保证，数据库可能暂时无法响应。确保您的应用程序能够妥善处理断开或不成功的连接。

7. 此外，低 Cloud SQL 代理版本也可能是此类事件问题的原因。可能升级到最新版本（v1.23.0）可以作为故障排除解决方案。
8. 您尝试连接的 IP 可能不会添加到 Cloud SQL 实例中的授权网络。

根据您的情况，此问题的一些可能的解决方法可能是以下之一：

1. 如果问题与高负载有关，您可以使用指数退避来重试连接，以防止同时发送太多连接请求。这里的最佳实践是以指数方式回退连接请求并添加随机回退以避免限制和潜在的实例过载。作为将来缓解此问题的一种方法，建议间隔连接请求以防止过载。不过，根据您连接到 Cloud SQL 的方式，某些 ORM 包默认情况下可能已使用指数退避。

2. 如果问题可能与长期运行的非活动连接的累积有关，您将能够使用show full processlist在数据库上查找高连接Time或连接在哪里Command来 知道这是否是您的情况Sleep。
   

   如果这是您的情况，您将有一些可能的选择：
   

   如果您没有使用连接池，您可以尝试更新客户端应用程序逻辑，以便在操作结束时立即正确关闭连接，或使用连接池来限制连接生命周期。特别是，使用连接池来管理连接计数是理想的。这样，未使用的连接将被回收，并且可以通过使用该参数来限制同时连接请求的数量maximum pool size。

   如果您使用连接池，则可以在操作结束时立即将空闲连接返回到池中，并通过调整wait_timeout或interactive_timeout标志值来设置更短的超时。将 CloudSQL wait_timeout标志设置为 600 秒以强制刷新连接。

3. 检查网络和端口连接一次 -

步骤 1. 使用 tcptraceroute 或 netcat 确认端口 3306 上的 TCP 连接。

步骤2.如果[步骤1]成功，则尝试检查使用mysql客户端检查超时/错误是否有任何错误。

4. 当客户端可能突然终止连接时，您可以检查：

   如果MySQL客户端或mysqld服务器接收到的数据包大于max_allowed_packet字节，或者客户端接收到数据包太大的消息，那么您可以发送较小的数据包或增加max_allowed_packet客户端和服务器上的标志值。如果存在未使用“开始”和“提交”正确提交的事务，则需要更新客户端应用程序逻辑以正确提交事务。

5. 如果您可以安装一些实用程序来在这些连接增加事件期间监视数据包，我认为这里有几个实用程序会很有帮助。mtrtcpdump

6. 强烈建议在数据库标志中启用general_log。另一个建议是还启用 Slow_query 数据库标志并输出到文件。另请查看此 GitHub 问题评论，并浏览此处针对此问题提出的其他解决方案列表