mysql错误日志

MySQL server has gone away

https://dev.mysql.com/doc/refman/5.7/en/gone-away.html

Lost connection to server during query

该MySQL server has gone away错误最常见的原因是服务器超时并关闭了连接。在这种情况下，您通常会收到以下错误代码之一（您收到的错误代码取决于操作系统）。

错误代码	描述
CR_SERVER_GONE_ERROR	客户端无法向服务器发送问题。
CR_SERVER_LOST	客户端在写入服务器时没有收到错误，但它没有得到问题的完整答案（或任何答案）。

默认情况下，如果没有发生任何事情，服务器会在八小时后关闭连接。wait_timeout 您可以通过在启动mysqld时设置变量来更改时间限制。

MySQL server has gone away该错误的 其他一些常见原因是：

• 您（或数据库管理员）已使用KILL 语句或mysqladmin kill命令杀死了正在运行的线程。

• 您尝试在关闭与服务器的连接后运行查询。这表明应用程序中存在需要纠正的逻辑错误。

• 在不同主机上运行的客户端应用程序没有从该主机连接到 MySQL 服务器的必要权限。

• 您从客户端的 TCP/IP 连接超时。如果您一直在使用以下命令，则可能会发生这种情况： mysql_options(..., MYSQL_OPT_READ_TIMEOUT,...)或 mysql_options(..., MYSQL_OPT_WRITE_TIMEOUT,...). 在这种情况下，增加超时可能有助于解决问题。

• 您在服务器端遇到了超时，并且客户端中的自动重新连接被禁用（结构中的 reconnect标志 MYSQL等于 0）。

• 您正在使用 Windows 客户端，并且服务器在 wait_timeout发出命令之前已断开连接（可能是因为已过期）。

  Windows 上的问题是，在某些情况下，MySQL 在写入与服务器的 TCP/IP 连接时不会从操作系统收到错误，而是在尝试从连接中读取答案时收到错误。

  对此的解决方案是， mysql_ping()如果自上次查询以来已经有很长时间（这是连接器/ODBC 所做的），或者 wait_timeout在 mysqld服务器上设置得如此之高，以至于实际上它永远不会超时，则要么在连接上进行操作。

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

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

• 如果主机名查找失败（例如，如果您的服务器或网络所依赖的 DNS 服务器出现故障），也可能会看到此错误。这是因为 MySQL 依赖于主机系统进行名称解析，但无法知道它是否在工作——从 MySQL 的角度来看，这个问题与任何其他网络超时没有区别。

  MySQL server has gone away如果 MySQL 在 skip_networking启用系统变量 的情况下启动， 您也可能会看到错误。

  如果 MySQL 端口（默认 3306）被防火墙阻止，则会出现另一个可能导致此错误的网络问题，从而完全阻止与 MySQL 服务器的任何连接。

• 您也可能在派生子进程的应用程序中遇到此错误，所有这些子进程都尝试使用与 MySQL 服务器的相同连接。这可以通过为每个子进程使用单独的连接来避免。

• 您遇到了服务器在执行查询时死机的错误。

您可以通过启动mysqld并将 系统变量设置为 3 来获取有关丢失连接的更多信息。这会在文件log_error_verbosity中记录一些断开连接消息。

Lost connection to MySQL server

https://dev.mysql.com/doc/refman/8.0/en/error-lost-connection.html

此错误消息有三个可能的原因。

通常它表示网络连接有问题，如果经常出现此错误，您应该检查网络状况。如果错误消息包括“during query” ，这可能是您遇到的情况。

有时，当作为一个或多个查询的一部分发送数百万行时，会出现“查询期间”形式。如果您知道这种情况正在发生，您应该尝试net_read_timeout 从默认的 30 秒增加到 60 秒或更长，这足以完成数据传输。

更罕见的是，当客户端尝试与服务器建立初始连接时，可能会发生这种情况。在这种情况下，如果您的 connect_timeout值设置为只有几秒钟，您可以通过将其增加到 10 秒来解决问题，如果您的距离很长或连接速度很慢，可能会更长。您可以使用 确定您是否遇到这种更不常见的原因 SHOW GLOBAL STATUS LIKE 'Aborted_connects'。对于服务器中止的每次初始连接尝试，它都会增加一。您可能会看到“读取授权数据包”作为错误消息的一部分；如果是这样，那也表明这是您需要的解决方案。

如果原因不是刚刚描述的那些，您可能会遇到 BLOB大于 的值的问题max_allowed_packet，这可能会导致某些客户端出现此错误。有时您可能会看到一个ER_NET_PACKET_TOO_LARGE 错误，这确认您需要增加 max_allowed_packet.

[Note] Aborted connection xxx to db: 'employees' user: 'josh'

如果客户端甚至无法连接，服务器会增加Aborted_connects状态变量。由于以下原因，可能会发生不成功的连接尝试：

• 客户端尝试访问数据库但没有权限。

• 客户端使用了错误的密码。

• 连接数据包不包含正确的信息。

• connect_timeout获取连接数据包需要几秒钟 以上的 时间。

如果发生此类事情，则可能表明有人试图闯入您的服务器！如果启用了通用查询日志，则会将此类问题的消息记录到其中。

如果客户端成功连接但后来不正确地断开连接或终止，则服务器增加 Aborted_clients状态变量，并将Aborted 连接消息记录到错误日志中。原因可能是以下任何一种：

• mysql_close()客户端程序在退出前 没有调用 。

• 客户端在没有向服务器发出任何请求的情况下 已经睡了超过 wait_timeout或 几秒钟。

• 客户端程序在数据传输过程中突然结束。

中止连接或中止客户端出现问题的其他原因：

• max_allowed_packet 变量值太小或查询需要的内存比您为 mysqld 分配 的更多。

• 在 Linux 中使用以太网协议，半双工和全双工。一些 Linux 以太网驱动程序有这个错误。您应该通过在客户端和服务器机器之间使用 FTP 传输一个巨大的文件来测试这个错误。如果传输进入burst-pause-burst-pause 模式，您将遇到Linux 双工综合症。将网卡和集线器/交换机的双工模式切换为全双工或半双工，并测试结果以确定最佳设置。

• 导致读取中断的线程库问题。

• 配置错误的 TCP/IP。

• 以太网、集线器、交换机、电缆等出现故障。只有更换硬件才能正确诊断。