即使使用 max_allowed_packet 参数，在使用 mysqldump 时也会丢失与 mysql 的连接答案

【问题标题】：getting Lost connection to mysql when using mysqldump even with max_allowed_packet parameter即使使用 max_allowed_packet 参数，在使用 mysqldump 时也会丢失与 mysql 的连接
【发布时间】：2018-10-31 20:47:32
【问题描述】：

我想在我的远程服务器数据库中转储特定表，它工作正常，但其中一个表是 9m 行，我得到：

Lost connection to MySQL server during query when dumping table `table_name` at row: 2002359

所以在线阅读后我明白我需要增加我的 max_allowed_packet，并且可以将它添加到我的命令中。

所以我运行以下命令来转储我的表：

mysqldump -uroot -h my.host -p'mypassword' --max_allowed_packet=512M db_name table_name | gzip  > dump_test.sql.gz

由于某种原因，我仍然得到：

Lost connection to MySQL server during query when dumping table `table_name` at row: 2602499

我做错了吗？

很奇怪，只有 900 万条记录……不算太大。

【问题讨论】：

标签： mysql database-connection

【解决方案1】：

尝试将--quick 选项添加到您的mysqldump 命令；它适用于大桌子。它将结果集中的行流式传输到输出，而不是吞下整个表，然后将其写出。

 mysqldump -uroot -h my.host -p'mypassword' --quick --max_allowed_packet=512M db_name table_name | \
 gzip  > dump_test.sql.gz

您也可以尝试将--compress 选项添加到您的mysqldump 命令。这使得它使用对您的 MySQL 服务器更网络友好的压缩连接协议。请注意，您仍然需要 gzip 管道； MySQL 的压缩协议不会导致转储从 mysqldump 压缩中出来。

也有可能是服务器超时了与mysqldump 客户端的连接。您可以尝试重置超时持续时间。通过其他方式连接到您的服务器并发出这些查询，然后运行您的 mysqldump 作业。

这些将超时设置为一个日历日。

    SET GLOBAL wait_timeout=86400;
    SET GLOBAL interactive_timeout=86400;

最后，如果您的服务器远离您的机器（通过路由器和防火墙），则可能会中断mysqldump 的连接。一些劣质路由器和防火墙对 NAT（网络地址转换）会话有时间限制。他们应该在使用时保持这些会话处于活动状态，但有些则不会。或者，您可能达到了公司为外部连接配置的时间或规模限制。

尝试登录到离服务器较近的机器并在其上运行mysqldump。然后使用其他方式（sftp？）将您的 gz 文件复制到您自己的机器上。

或者，您可能需要对该文件的转储进行分段。你可以做这样的事情（未调试）。

mysqldump  -uroot -h my.host -p'mypassword'  \ 
          db_name table_name --skip-create-options --skip-add-drop-table \
          --where="id>=0 AND id < 1000000" | \
          gzip....

然后用这些行重复。

          --where="id>=1000000 AND id < 2000000" | \

          --where="id>=2000000 AND id < 3000000" | \
          ...

直到你得到所有的行。颈部疼痛，但它会起作用。

【讨论】：

它存活了一段时间，但仍然得到了Lost connection to MySQL server during query when dumping table `table_name` at row: 2926704。它让我发疯......
请看我的放大答案。
谢谢哥们，我认为 --compress 确实有所不同 :) 感谢@O。琼斯

【解决方案2】：

对我来说，跳过锁表时一切正常

 mysqldump -u xxxxx --password=xxxxx --quick --max_allowed_packet=512M --skip-lock-tables --verbose   -h xxx.xxx.xxx.xxx > db.sql

我可能会产生一致性问题，但允许我备份 5GB 数据库而没有任何问题。

【讨论】：

【解决方案3】：

使用上面的 JohnBigs 评论，--compress 标志对我有用。

我之前尝试过--single-transaction、--skip-extended-insert 和--quick，但均未成功。

【讨论】：

【解决方案4】：

尝试其他选项：

net_read_timeout=3600 
net_write_timeout=3600

在 my.ini/my.cnf 或通过SET GLOBAL ...

【讨论】：

【解决方案5】：

我在我的服务器上遇到了类似的问题，MySQL 显然会在夜间备份期间重新启动。它始终是同一个数据库，但实际表有时会有所不同。

从这里的其他答案中尝试了几个，但最后只是一些 cronjob 执行未完成的查询。这并没有导致触发监视的 CPU 和 RAM 使用量过多，但显然足以压缩转储导致 OOM 杀手变得活跃。修复了cronjob，下次备份又好了。

要寻找的东西：

OOM？ dmesg | grep invoked
进程被杀死？ grep killed /var/log/kern.log

【讨论】：

【解决方案6】：

另外，请确保您的 MYSQL.EXE 客户端与您的 mysql 服务器版本相同。

所以，如果您的 mysql 版本是 8.0.23，但您的客户端版本是 8.0.17 或 8.0.25，您可能会遇到问题。我在 mysql 服务器 8.0.23 上使用 8.0.17 版本遇到了这个问题 - 更改客户端版本以匹配服务器版本解决了这个问题。

【讨论】：