主页 / dba / 问题 / 19135
Accepted
KM.
Asked: 2012-06-13 09:40:25 +0800 CST

MySQL读取通讯包报错

  • 772

在 MySQL 错误日志中，我看到了一些类似这样的警告：

120611 16:12:30 [Warning] Aborted connection 2619503 to db: 'db_name' user: 'user_name' host: 'webapp_hostname' (Got an error reading communication packets)

没有注意到任何数据本身的丢失，所以我想知道这个警告是什么意思，或者是什么原因造成的，以及是否可以解决导致这些问题的问题。这是在 RHEL 6.1 和 MySQL Enterprise 5.5 上。

mysql mysql-5.5

7 个回答

  1. Best Answer

    MySQL 连接的沉默杀手之一是 MySQL 数据包。

    首先，让我们弄清楚 MySQL Packet 是什么。

    根据"Understanding MySQL Internals" (ISBN 0-596-00957-7) 的第 99 页，这里是解释 MySQL 数据包的第 1-3 段：

    MySQL 网络通信代码是在查询总是相当短的假设下编写的，因此可以以一个块的形式发送到服务器并由服务器处理，在 MySQL 术语中称为数据包。服务器为临时缓冲区分配内存来存储数据包，并请求足够的内存以完全容纳它。这种架构需要采取预防措施来避免服务器内存不足——这个选项可以实现数据包大小的上限。

    与此选项相关的代码可在 sql/net_serv.cc中找到。查看my_net_read()，然后按照对my_real_read()的调用并特别注意 net_realloc()。

    此变量还限制了许多字符串函数的结果的长度。有关详细信息，请参阅sql/field.cc和 sql/intem_strfunc.cc。

    了解有关 MySQL 数据包的这一点后，开发人员/DBA 可以调整它们的大小以在一个数据包中容纳多个 BLOB，即使它们大得令人讨厌。当然，一个太小的数据包会在这方面导致打开连接的问题。

    根据MySQL 文档

    • 如果您向服务器发送不正确或太大的查询，您也可能会收到这些错误。如果 mysqld 收到一个太大或乱序的数据包，它会假定客户端出现问题并关闭连接。如果您需要大查询（例如，如果您使用大 BLOB 列），您可以通过设置服务器的 max_allowed_pa​​cket 变量来增加查询限制，该变量的默认值为 1MB。您可能还需要增加客户端的最大数据包大小。有关设置数据包大小的更多信息，请参见第 C.5.2.10 节，“数据包太大”。

    • 插入大量行的 INSERT 或 REPLACE 语句也可能导致这类错误。无论要插入的行数如何，这些语句中的任何一个都向服务器发送单个请求；因此，您通常可以通过减少每次 INSERT 或 REPLACE 发送的行数来避免错误。

    推荐

    尝试将max_allowed_pa​​cket提高到更大的数字，因为默认值为 1M。我建议您在当前数据集中拥有的最大 TEXT 或 BLOB 字段大约是 10 倍。

    要将 max_allowed_pa​​cket 设置为 256M，可以将其添加到 /etc/my.cnf 或 my.ini

    [mysqld]
max_allowed_packet=256M

    以涵盖 mysqld 的未来重新启动。要立即在服务器上安装该值，请运行以下命令：

    SET GLOBAL max_allowed_packet = 1024 * 1024 * 256;

    试试看 ！！！

    • 80

  2. 大多数情况下默认max_connections为 100。尝试将配置参数增加到max_connections=400.

    在重新启动服务器后设置my.cnf，或者您可以动态设置它：

    set @@global.max_connections = 400;

    只需尝试上述建议以避免此警告消息，并确保您的网络没有丢包。

    • 8

  3. 我最近从 MySQL Enterprise 5.1.x迁移到5.7.x后遇到了这个问题，没有对应用程序进行任何重大的代码更改，“注释”开始出现。

    在我的情况下，出现“ note ”的根本原因是程序退出时连接仍然打开。未关闭连接的情况涉及更多，与 MySQL 无关，而是与 ACE、线程和 TSS 相关。

    • 4

  4. 这里没有提到，所以我包括了这个问题的另一个原因。就我而言，在使用 mysql 命令行客户端时，错误是由 30 秒的低值引起的interactive_timeout：
    https ://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html #sysvar_interactive_timeout
    这将在会话之间持续存在，但不会在服务器重新启动时持续存在。

    SET GLOBAL interactive_timeout=6000;
    • 0

  5. 我在 MariaDB 10.3.24 中遇到了同样的问题。

    似乎警告可能由于此处提到的所有其他原因而发生，然后是一些原因。

    在我的情况下，这是由于其中一个数据库表中的记录具有一个字段的空字典值。

    +----+--------+
| id | config |
+----+--------+
|  3 | {}     |
+----+--------+

    作为测试，我将其更改{}为()并停止了消息。以防万一它帮助某人。

    • 0

  6. 我通过执行返回多行的查询得到了同样的错误，然后使用 rows.Next()（在 Golang 中）处理这些行，并且由于不相关的错误而提前退出而不调用 rows.Close()。令人困惑的部分是它在前几次工作，但最终失败，表明一些资源（连接？）正在被用完。

    我能够利用 Golang 的 defer 语句，然后做

    推迟行。关闭（）

    在调用 rows.Next() 之前，但在每次提前退出 rows.Next() 循环之前调用 rows.Close() 也可以。

    • 0

  7. 这个 my.ini 行临时解决了我的问题：

    log_error_verbosity=1

    参考这个链接

    • -3

相关问题