错误2006（HY000）：MySQL服务器已消失

当我尝试来源大型SQL文件（大型INSERT查询）时出现此错误。

mysql>  source file.sql
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    2
Current database: *** NONE ***

ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    3
Current database: *** NONE ***

表中的任何内容均未更新。我尝试删除和取消删除表/数据库，以及重新启动MySQL。这些都不是解决问题的方法。

这是我的最大数据包大小：

+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+

这是文件大小：

$ ls -s file.sql 
79512 file.sql

当我尝试其他方法时...

$ ./mysql -u root -p my_db < file.sql
Enter password: 
ERROR 2006 (HY000) at line 1: MySQL server has gone away

max_allowed_packet=64M

将此行添加到 my.cnf文件中解决了我的问题。

当列的值较大会导致问题时，此功能很有用，您可以在此处找到说明。

在Windows上，此文件位于：“ C：\ ProgramData \ MySQL \ MySQL Server 5.6”

在Linux（Ubuntu）上：/ etc / mysql

您可以增加最大允许数据包

SET GLOBAL max_allowed_packet=1073741824;

http://dev.mysql.com/doc/refman/5.5/zh-CN/server-system-variables.html#sysvar_max_allowed_pa​​cket

出于某种原因，全局更新和my.cnf设置对我不起作用。将max_allowed_packet值直接传递给客户的方法在这里起作用：

mysql -h <hostname> -u username -p --max_allowed_packet=1073741824 <databasename> < db.sql

一般来说，错误：

错误：2006（CR_SERVER_GONE_ERROR）-MySQL服务器已消失

表示客户端无法向服务器发送问题。

mysql 进口

在您的特定情况下，通过导入数据库文件 mysql，这很可能意味着SQL文件中的某些查询太大而无法导入，因此无法在服务器上执行，因此客户端在第一个发生的错误上失败。

因此，您具有以下可能性：

• 添加强制选项（-f），mysql以继续执行其余查询。

  如果数据库具有一些与缓存相关的大查询，而这些查询无论如何都不相关，则这很有用。

• 增加max_allowed_packet并wait_timeout在您的服务器配置中（例如~/.my.cnf）。

• 使用--skip-extended-insert选项转储数据库以分解大型查询。然后再次导入。

• 尝试为申请--max-allowed-packet选项mysql。

常见原因

通常，此错误可能意味着几件事，例如：

• 对服务器的查询不正确或太大，

  解决方案：增加max_allowed_packet变量。

  • 确保变量位于[mysqld]部分（而不是部分）下[mysql]。

  • 不要害怕使用大量数字进行测试（例如1G）。

  • 不要忘记重启MySQL / MariaDB服务器。

  • 仔细检查该值是否通过以下方式正确设置：

    mysql -sve "SELECT @@max_allowed_packet" # or:
    mysql -sve "SHOW VARIABLES LIKE 'max_allowed_packet'"

• 您从客户端的TCP / IP连接中收到了超时。

  解决方案：增加wait_timeout变量。

• 您尝试关闭服务器的连接后运行查询。

  解决方案：应纠正应用程序中的逻辑错误。

• 主机名查找失败（例如DNS服务器问题），或者已使用--skip-networking选项启动了服务器。

  另一种可能是您的防火墙阻止了MySQL端口（例如，默认情况下为3306）。

• 正在运行的线程已被杀死，因此请重试。

• 您遇到了一个错误，该错误导致服务器在执行查询时死亡。

• 在其他主机上运行的客户端没有连接所需的特权。

• 以及更多其他信息，请访问：B.5.2.9 MySQL服务器已消失。

调试

这里有一些专家级的调试思路：

• 检查日志，例如

  sudo tail -f $(mysql -Nse "SELECT @@GLOBAL.log_error")

• 经测试您的连接mysql，telnet或ping功能（例如mysql_ping在PHP）。

• 使用tcpdump嗅探MySQL的通信（会为套接字连接不工作），例如：

  sudo tcpdump -i lo0 -s 1500 -nl -w- port mysql | strings

• 在Linux上，使用strace。在BSD / Mac上，使用dtrace/ dtruss，例如

  sudo dtruss -a -fn mysqld 2>&1

  请参阅：DTracing MySQL入门

在以下网址了解更多如何调试MySQL服务器或客户端的信息：26.5调试和移植MySQL。

作为参考，请检查sql-common/client.c文件中负责引发CR_SERVER_GONE_ERRORclient命令错误的源代码。

MYSQL_TRACE(SEND_COMMAND, mysql, (command, header_length, arg_length, header, arg));
if (net_write_command(net,(uchar) command, header, header_length,
          arg, arg_length))
{
  set_mysql_error(mysql, CR_SERVER_GONE_ERROR, unknown_sqlstate);
  goto end;
}

以防万一，检查变量可以使用

$> mysqladmin variables -u user -p 

这将显示当前变量，在本例中为max_allowed_pa​​cket，正如有人在另一个答案中所说的那样，您可以使用

mysql> SET GLOBAL max_allowed_packet=1072731894

就我而言，没有考虑cnf文件，我也不知道为什么，所以SET GLOBAL代码确实有帮助。

我解决了该错误，ERROR 2006 (HY000) at line 97: MySQL server has gone away并按顺序执行以下两个步骤，成功迁移了> 5GB的sql文件：

1. 按照其他建议创建了/etc/my.cnf，其内容如下：

   [mysql]
   connect_timeout = 43200
   max_allowed_packet = 2048M
   net_buffer_length = 512M
   debug-info = TRUE

2. 将标志附加--force --wait --reconnect到命令（即mysql -u root -p -h localhost my_db < file.sql --verbose --force --wait --reconnect）。

重要说明：这两个步骤都是必要的，因为如果我不花时间对/etc/my.cnf文件进行更改以及附加这些标志，则导入后某些表将丢失。

使用的系统：OSX El Capitan 10.11.5; 适用于osx10.8的mysql Ver 14.14 Distrib 5.5.51（i386）

我有同样的问题，但是在[mysqld]下的my.ini / my.cnf文件中更改max_allowed_pa​​cket可以解决问题。

加一行

max_allowed_packet=500M

现在，一旦完成，请重新启动MySQL服务。

您还可以以root用户（或SUPER特权）登录数据库并执行

set global max_allowed_packet=64*1024*1024;

也不需要MySQL重新启动。请注意，您应该my.cnf按照其他解决方案中所述修复文件：

[mysqld]
max_allowed_packet=64M

重新启动MySQL后，确认更改：

show variables like 'max_allowed_packet';

您也可以使用命令行，但是可能需要更新开始/停止脚本，而这些脚本可能无法在系统更新和补丁程序中保留下来。

根据要求，我在这里添加自己的答案。高兴地看到它有效！

解决方案是在标签下的选项文件中增加wait_timeout和connect_timeout参数的值[mysqld]。

我必须恢复一个400MB的mysql备份，这对我有用（我在下面使用的值有些夸张，但您明白了）：

[mysqld]
port=3306
explicit_defaults_for_timestamp = TRUE
connect_timeout = 1000000
net_write_timeout = 1000000
wait_timeout = 1000000
max_allowed_packet = 1024M
interactive_timeout = 1000000
net_buffer_length = 200M
net_read_timeout = 1000000
set GLOBAL delayed_insert_timeout=100000

块引用

这里可能发生几件事；

• 您INSERT的服务器长时间运行，并且客户端正在断开连接。重新连接时，它没有选择数据库，因此会出现错误。这里的一个选项是从命令行运行批处理文件，然后在参数中选择数据库，就像这样；

$ mysql db_name <source.sql

• 另一种是通过php或其他某种语言运行命令。在每个长期运行的语句之后，您可以关闭并重新打开连接，以确保在每个查询开始时都已连接。

如果您在Mac上并且通过像我这样的brew安装mysql，则可以使用以下方法。

1. cp $(brew --prefix mysql)/support-files/my-default.cnf /usr/local/etc/my.cnf

来源：对于自制mysql安装，my.cnf在哪里？

2. 添加max_allowed_packet=1073741824到/usr/local/etc/my.cnf

3. mysql.server restart

我在使用Mysql群集时遇到此错误，我不知道此问题是否来自群集使用情况。由于错误完全相同，因此请在此处提供解决方案。由于数据节点突然崩溃而出现此错误。但是，当节点崩溃时，您仍然可以使用cmd获得正确的结果：

ndb_mgm -e 'ALL REPORT MEMORYUSAGE'

而且mysqld也可以正常工作。因此，起初，我不明白出了什么问题。大约5分钟后，ndb_mgm结果显示没有数据节点正常工作。然后我意识到了问题。因此，尝试重新启动所有数据节点，然后mysql服务器返回，一切正常。

但是对我来说很奇怪，在我丢失了mysql服务器的某些查询后，当我使用cmd like时show tables，我仍然可以获得诸如的返回信息33 rows in set (5.57 sec)，但是没有显示表信息。

对于Amazon RDS（这是我的情况），您可以将max_allowed_packet参数值更改为以字节为单位的任何数值，这对于您可能拥有的任何插入物中的最大数据都有意义（例如：如果插入物中有50mb的blob值，请设置max_allowed_packet到64M = 67108864）（新的或现有的）parameter-group。然后将该参数组应用于您的MySQL实例（可能需要重启实例）。

如果重新连接并获得连接ID 2，则服务器几乎肯定崩溃了。

请与服务器管理员联系，并让他们诊断问题。没有任何非恶意的SQL应该不会使服务器崩溃，并且mysqldump的输出当然也不会。

服务器管理员可能犯了一些大的操作错误，例如分配的缓冲区大小大于体系结构的地址空间限制，或者大于虚拟内存容量。MySQL错误日志可能会包含一些相关信息。无论如何，他们将对此进行监视。

这更是一个罕见的问题，但是如果有人复制了整个/ var / lib / mysql目录作为将其数据库迁移到另一台服务器的一种方式，我就已经看到了。它不起作用的原因是因为数据库正在运行并且正在使用日志文件。如果/ var / log / mysql中有日志，有时有时不起作用。解决方案是也复制/ var / log / mysql文件。

对于正在寻找数据库导入失败解决方案的Drupal 8用户：

在sql dump文件的末尾，可以使用命令将数据插入“ webprofiler”表。我想这是一些调试日志文件，对于站点正常工作并不重要，因此可以删除所有这些日志文件。我删除了所有这些插入，包括LOCK TABLES和UNLOCK TABLES（以及之间的所有内容）。它在sql文件的最底部。问题描述如下：

https://www.drupal.org/project/devel/issues/2723437

但是除了截断该表之外，没有其他解决方案。

顺便说一句，我尝试了以上答案的所有解决方案，但没有其他帮助。

我已经尝试了所有上述解决方案，但都失败了。

我最终使用-h 127.0.0.1而不是使用default var/run/mysqld/mysqld.sock。

当您创建的SCHEMA与转储中使用的COLLATION不同时，也会发生此错误消息。因此，如果转储包含

CREATE TABLE `mytab` (
..
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

您还应该在SCHEMA归类中反映出这一点：

CREATE SCHEMA myschema COLLATE utf8_unicode_ci;

我一直在架构中使用utf8mb4_general_ci，因为我的脚本来自全新的V8安装，现在在旧5.7上加载数据库时崩溃了，这使我几乎疯了。

因此，也许这可以帮助您节省一些令人沮丧的时间... :-)

（MacOS 10.3，MySQL 5.7）

如果这些答案都不能解决您的问题，我将通过删除表并以这种方式自动重新创建表来解决：

when creating the backup, first backup structure and be sure of add:
DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT
CREATE PROCEDURE / FUNCTION / EVENT
IF NOT EXISTS
AUTO_INCREMENT

然后将此备份与您的数据库一起使用，它将删除并重新创建所需的表。

然后，您仅备份数据，然后执行相同操作，它将起作用。

如何像这样使用mysql客户端：

mysql -h <hostname> -u username -p <databasename> < file.sql