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.备份和恢复速度

经验值：某个备份出的.sql文件大小为39GB，备份耗时约80分钟；在测试恢复中，发现需要约206分钟。环境：Quad-Core AMD Opteron(tm) 4*2核32G内存；

7.其他

*****备份不要在数据库压力较大的时候进行，每天凌晨备份是比较合适的

*****如果是事务型引擎（InnoDB），建议使用--single-transaction参数，这样可以让锁表时间变得很短

参考：

1. Manual about mysqldump
2. Manual about Lost Connection
3. Manual about net_write_timeout