代码之家 › 专栏 › 技术社区 › JohnBigs

使用mysqldump时与mysql的连接丢失,即使使用max\u allowed\u packet参数

database-connection mysql

JohnBigs · 技术社区 · 6 年前

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

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

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万张唱片…不太大。

1 回复 | 直到 6 年前

O. Jones 6 年前

--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 mysqldump文件

也有可能服务器正在超时连接到服务器客户。您可以尝试重置超时持续时间。通过其他方式连接到服务器并发出这些查询,然后运行 mysqldump文件 工作。

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

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

最后,如果您的服务器离您的机器很远(通过路由器和防火墙),则可能会发生中断 mysqldump文件 的连接。一些劣质路由器和防火墙对NAT(网络地址转换)会话有时间限制。它们应该在使用过程中保持这些会话的活动性,但有些没有。或者你可能达到了公司为外部连接设定的时间或大小限制。

尝试登录到靠近服务器的计算机并运行然后使用其他方法(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" | \
          ...

DPalharini 4 年前

对我来说,当我跳过锁表时,一切都很好

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

我可能会造成一致性问题,但允许我备份一个5GB的数据库没有任何问题。

Parris Varney 5 年前

使用上面的JohnBigs评论 --compress 国旗是我的工作。

我以前试过 --single-transaction , --skip-extended-insert ,和 --quick 没有成功。

Moshe L 5 年前

其他尝试选项:

net_read_timeout=3600 
net_write_timeout=3600

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

Larsen 3 年前

我的服务器上也有类似的问题,MySQL显然会在夜间备份时重新启动。它总是同一个数据库,但实际的表有时是不同的。

在这里尝试了其他答案中的几个,但最后只是一些cronjob执行的查询没有完成。这并没有导致太多的CPU和RAM使用,从而触发了监视,但显然足够压缩转储导致OOM killer变为活动状态。修复了cronjob,下一次备份再次正常。

哦? dmesg | grep invoked
grep killed /var/log/kern.log

Watson 3 年前

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