MySQL常见错误：“Got an error reading communication packet”

MySQL常见错误：“Got an error reading communication packet”

根据数据库引擎网站 ，MySQL是排在Oracle之后的世界上第二大著名数据库。MySQL之所以出名，可能是因为它是一个非常快速、可靠和灵活的数据库管理系统。MySQL也是ClusterControl 支持的数据库之一。 您可以使用ClusterControl轻松地部署、扩展、监视数据库和执行许多数据库操作。

今天我们不打算讨论这些问题，但我们将讨论MySQL的一个常见错误和可能的故障排除技巧。在处理票据时，很多时候当我们检查错误报告或日志时，我们经常看到这行““Got an error reading communication packet”。 我们认为，如果我们写一篇关于这个错误的博客，不仅对我们的客户，而且对其他读者，都是有益的。

MySQL客户端/服务器协议

首先，我们需要了解MySQL在客户端和服务器之间的通信方式。客户端和服务器都使用MySQL协议，该协议由连接器、MySQL代理以及主复制服务器和从复制服务器之间的通信实现。MySQL协议支持通过SSL进行透明加密、透明压缩、连接阶段以及命令阶段等功能。

整数和字符串都是贯穿MySQL协议的基本数据类型。每当MySQL客户端和服务器想要相互通信或发送数据时，它都会将数据划分为最大大小为16MB的数据包，并且还会在每个数据块之前添加一个数据包头。在每个数据包中，都有一个有效负载，数据类型（整数/字符串）在其中发挥作用。

考虑CLIENT_PROTOCOL_41 已启用，对于客户端发送给服务器的几乎每个命令，服务器都会响应以下任何数据包：

包类型	描述
OK_Packet	这是每个成功命令的信号
ERR_Packet	该信号指示数据包有错误
EOF_Packet	此数据包包含警告或状态标志

如何诊断问题

通常，有两种类型的连接问题，即通信错误或中断连接。无论何时发生这些连接问题，以下信息来源都是故障排除和分析的良好起点：

• 错误日志
• 一般查询日志
• Aborted_xxx和Connection_errors_xxx状态变量
• 主机缓存

连接错误和可能的原因

如果发生任何连接错误，根据错误的不同，它将增加状态变量中Aborted_clients或Aborted_connects的状态计数器。根据MySQL文档，Aborted_clients 表示由于客户端未正确关闭连接而终止的连接数。至于 Aborted_connects ，表示尝试连接MySQL服务器失败的次数。

如果使用 –log warnings 选项启动MySQL服务器，则很可能会在错误日志中看到以下消息的示例。正如您所注意到的，消息明确指出它与中止连接有关，因此状态变量中的Aborted_connects状态计数器将递增：

[Warning] Aborted connection 154669 to db: ‘wordpress’ user: ‘wpuser’ host: ‘hostname’ (Got an error reading communication packets)

通常，由于以下原因，可能会发生不成功的连接尝试。当您注意到这一点时，它可能表示未经授权的人即将破坏数据库，您可能希望尽快查看：

• 客户端没有访问数据库的权限。
• 使用了错误的凭证。
• 包含错误信息的连接数据包。
• 由于connect_timeout已达到连接限制。

如果客户端试图连接，但以不正确的方式断开连接或终止，则服务器将增加Aborted_clients的状态变量。除此之外，服务器还将在错误日志中记录一条Aborted connection消息。对于此类错误，通常可能是由于以下原因造成的：

• 客户端在退出之前没有正确关闭连接（没有调用mysql_close()）。
• 客户端已超过 wait_timeout 或 interactive_timeout 秒。
• 客户端程序或应用程序在数据传输过程中突然终止。

除了前面的原因外，中止连接和中止客户端问题的其他可能原因可能与以下任何一项有关：

• TCP/IP配置出错。
• 变量值对于max_allowed_packet太小。
• 用于查询的内存分配不足。
• 以太网、交换机、电缆等硬件故障。
• 线程库问题。
• 双工综合症问题，即传输进入突发-暂停-突发-暂停模式（如果在Linux中使用以太网协议，则为半双工和全双工）。

如何修复MySQL通信错误

现在，我们了解了导致MySQL连接错误的许多潜在因素。根据我们的经验，大多数情况下，这个问题与防火墙或网络问题有关。平心而论，诊断这种问题并不容易。尽管如此，以下解决方案可能有助于您解决此错误：

• 如果应用程序依赖wait_timeout来关闭连接，那么有必要更改应用程序逻辑，以便在任何操作结束时正确关闭。
• 确保max_allowed_packet的值在可接受的范围内，以便客户端不会收到任何与“packet too large”相关的错误。
• 对于可能由DNS引起的连接延迟问题，应检查是否启用了跳过名称解析。
• 如果您正在使用PHP应用程序或任何其他编程，最好是确保它不会中止通常设置为 max_execution_time的连接。
• 如果您注意到netstat报告大量TIME_WAIT，那么有必要确认应用程序端的连接管理是否良好。
• 如果您使用的是Linux，并且怀疑问题是由于网络造成的，那么最好使用ifconfig-a命令检查网卡，并检查MySQL服务器上的输出是否有错误。
• 对于ClusterControl 用户，可以 Cluster -> Security -> Audit Log 启用审审计。通过启用此功能，它可以帮助您缩小查找罪魁祸首的范围。
• 网络工具，如 tcpdump 和 Wireshark 可能有助于识别MySQL的潜在网络问题、超时和资源问题。
• 定期检查硬件，确保没有故障设备，尤其是以太网卡、集线器、交换机、电缆等。更换故障设备以确保连接始终良好是值得的。

结论

有很多原因可能会导致MySQL连接数据包问题。无论何时发生此问题，它肯定会影响业务和日常运营。尽管这种类型的问题不容易诊断，而且大多数情况下是由于网络或防火墙造成的，但为了解决问题，还是值得考虑前面建议的所有步骤。我们真的希望这篇博客文章能在某些方面有所帮助，尤其是当你面对这个问题时。