在 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

此错误消息表明存在连接问题，可能是因为您的应用程序没有正确终止连接，也可能是因为网络问题。

按照 GCP 文档中针对 MySQL 或 PostgreSQL 实例的这些故障排除步骤中的建议，您可以通过检查您是否关注 best practices for managing database connections 来开始调试。

Answer 2

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

关于为什么会发生此问题的可能解释是：

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

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

1. Cloud SQL 代理版本低也可能是导致这种情况的原因 事件问题。可能升级到最新版本（v1.23.0） 可以作为故障排除解决方案。
2. 您尝试连接的 IP 可能未添加到 Cloud SQL 实例中的授权网络。

针对此问题的一些可能的解决方法，取决于您的情况，可能是以下之一：

1. 如果问题与高负载有关，您可以 重试连接，使用exponential backoff 防止 发送过多的同时连接请求。最好的 这里的做法是以指数方式回退您的连接请求 并添加randomized backoffs以避免节流，并可能 重载实例。作为缓解这一问题的一种方式 未来，建议连接请求应该是 间隔，以防止过载。虽然，取决于你如何 正在连接到 Cloud SQL，指数退避可能已经存在 默认情况下与某些 ORM 包一起使用。

2. 如果问题可能与 accumulation of long-running inactive connections 有关，您将能够知道是否是您的情况 在您的数据库上使用show full processlist寻找 高Time 的连接或Command 的连接 Sleep。
   

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

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

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

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

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

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

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

   如果 MySQL 客户端或 mysqld 服务器正在接收更大的数据包 大于max_allowed_packet 字节，或者客户端接收到数据包 消息太大，如果这样您可以发送较小的数据包或 增加两个客户端上的 max_allowed_packet 标志值 和服务器。如果有交易不正常 同时使用“begin”和“commit”提交，需要 更新客户端应用程序逻辑以正确提交 交易。

5. 我认为这里有several utilities 会有所帮助， 如果您可以安装 mtr 和 tcpdump 实用程序到 在这些连接增加事件期间监视数据包。

6. 强烈建议在 数据库标志。另一个建议是也启用 slow_query 数据库标志并输出到文件。也看看这个 GitHub issue comment 并浏览其他列表 针对这个问题提出的解决方案here