今天用mysqldump导数据,结果报错了,后看了下面的帖子,佩服楼主。
原文链接: http://hi.baidu.com/ldtrain/blog/item/1c7f87be76c9020119d81f18.html
mysqldump:Got error:2013: Lost connection to MySQL server during query when dumping table’
mysqldump拾遗
mysqldump是MySQL数据库备份最基本的方法,本文将简单的介绍mysqldump使用过程中容易忽略的问题。包括基本使用,和使用中的遇到一些问题,欢迎讨论。
1.基本使用
mysqldump -ubackup -p --all-databases > ~/dz_dump.sql mysqldump -ubackup -p --databases feel> ~/feel_dump.sql #仅备份单个数据库 mysqldump -ubackup -p --no-data --all-databases> ~/no_data.sql #仅备份表结构
2.关于INFORMATION_SCHEMA
information_schema是由mysql server维护的一个数据库,在备份数据库的时候,我们是不需要这个数据库的。事实情况也很好,5.0、5.1版本下的mysqldump都是不会导出这个数据库的。但是4.1的mysqldump不买这个帐,会将information_schema一起导出,这是不必要的。(使用4.1版本的mysqldump必须使用–single-transaction参数,因为即使是root用户也不能lock information_schema里面的数据表)
3.使用备份做备库
--master-info可以帮你用备份出来的数据做一个备库
4.较大的数据量
如果你的数据量,到了几千万的级别,mysqldump的速度就会变的很慢,而且dump生成的文件会很大,你想从备份恢复数据库时间也会很长,这时候,你可能需要寻找新的备份方法了
5.”Lost connection to MySQL server”
在使用mysqldump的时候(尤其是向NFS上备份的时候),很多人都被’mysqldump:Got error:2013: Lost connection to MySQL server during query when dumping table’的问题困扰,在Manual中对这个问题有一些简单的说明。
在向NFS上备份的时候,数据的流向是这样的:MySQL Server端从数据文件中检索出数据,然后分批将数据返回给mysqldump客户端,然后mysqldump将数据写入到NFS上。一般地,向NFS上写入数据的速度较之Server端检索发送数据的速度要慢得多,这就会导致mysqldump无法及时的接受Server端发送过来的数据,Server端的数据就会积压在内存中等待发送,这个等待不是无限期的,当Server的等待时间超过net_write_timeout(默认是60秒)时它就失去了耐心,mysqldump的连接会被断开,同时抛出错误Got error: 2013: Lost connection。
增加net_write_timeout可以解决上述的问题的。在实践中发现,在增大net_write_timeout后,Server端会消耗更多的内存,有时甚至会导致swap的使用(并不确定是不是修改net_write_timeout所至)。建议在mysqldump之前修改net_write_timeout为一个较大的值(如1800),在mysqldump结束后,在将这个值修改到默认的60。
6.其他
Lost connection to MySQL server during query 错误
造成这样的错误原因很多
个人经验认为先试一试这两个参数,大部分都是这个原因引起的:
bind-address = 127.0.0.1
skip-name-resolve
这两个参数任意一个就行。
也就是说遇到2006,2013错误就重新连接一下MySQL。
2. MySQL层面,需要配置一些参数 my.cnf
wait_timeout = x 超时时间
max_allowed_packet = y 最大允许数据量
适当增加x,y的值。
3. 一般出现这种情况不是所有例句而是单个表,请你先修复表一般都能解决这类问题
*****备份不要在数据库压力较大的时候进行,每天凌晨备份是比较合适的
*****如果是事务型引擎(InnoDB),建议使用--single-transaction参数,这样可以让锁表时间变得很短
参考: