原文地址：http://www.zsythink.net/archives/1450
mysqldump是mysql自带的逻辑备份工具。它的备份原理是，通过协议连接到mysql数据库，将需要备份的数据查询出来，将查询出的数据转换成对应的insert语句，当我们需要还原这些数据时，只要执行这些insert语句，即可将对应的数据还原。
mysqldump的优点：
可以直接使用文本处理工具处理对应的备份数据，因为备份数据已经被mysqldump转换为了对应的insert语句，所以，我们可以借助文件系统中的文本处理工具对备份数据进行直接处理。
mysqldump的缺点：
当数据为浮点类型时，会出现精度丢失
mysqldump的备份过程属于逻辑备份，备份速度、恢复速度与物理备份工具相比较慢，而且mysqldump备份的过程是串行化的，不会并行的进行备份，如果想要并行备份，可以使用mydumper，但是此处我们不考虑这些，只考虑mysqldump，当数据量较大时，一般不会使用mysqldump进行备份，因为效率较低。
mysqldump对innodb存储引擎支持热备，innodb支持事务，我们可以基于事务通过mysqldump对数据库进行热备。mysqldump对myisam存储引擎只支持温备，通过mysqldump对使用myisam存储引擎的表进行备份时，最多只能实现温备，因为在备份时会对备份的表请求锁，当备份完成后，锁会被释放。
我们先通过一些最简单的实验，来了解一下mysqldump，但是这些操作过于简陋，不足以满足我们的备份需求，备份的数据也有可能出现问题，所以不要使用简单示例中的语句进行备份，我们只是通过它们去了解mysqldump命令罢了，等我们掌握了它，再总结一些实用的备份命令，
简单示例：
假设，我们现在想要通过mysqldump备份zsythink数据库，那么，我们可以通过如下mysqldump命令：
mysqldump -u用户 -h localhost 数据库 -p数据库密码
该条命令执行后会将备份过程中创建的sql语句打印到终端，但是执行完后并不会实现备份效果。我们可以将打印出来的sql输出到sql文件内，这就是基本的msyql逻辑备份
mysqldump -u用户 -h localhost 数据库 -p数据库密码 > /tmp/db.sql
但是，细心如你一定发现了，此sql脚本中并不包含任何创建数据库的语句，只有创建表的语句，也就是说，在还原时，必须先确保对应的数据库已经存在，那么，我们能不能再备份时就生成创建库的语句呢？必须的额，使用--databases选项指定数据库，即可在备份时生成创建数据库的语句，
示例如下。
mysqldump -u用户 -h localhost --databases 数据库 -p数据库密码 > /tmp/db.sql
那么，我们能不能只备份数据库中的某张表呢？能不能同时备份指定的多张表呢？能不能一次备份多个数据库呢？必须能啊，只要我们灵活的运用一些选项即可，总结如下。使用如下语句备份zsythink数据库中的所有表，但是不会生成创建zsythink数据库的语句，只是备份其中的表（包括创建表的语句和数据）。
mysqldump -uroot -h192.168.1.146 zsythink -p
使用如下语句备份zsythink数据库中指定的表，下例中只会备份zsythink数据库中的t1、t2、t3表，其他表不会备份，也不会生成创建zsythink数据库的语句（但是对应的表的创建语句会生成，表数据会备份）。
mysqldump -uroot -h192.168.1.146 zsythink t1 t2 t3 -p
使用如下语句备份zsythink整个数据库，包括其中的所有表，并且会生成创建zsythink数据库的语句。
mysqldump -uroot -h192.168.1.146 --databases zsythink -p
使用如下语句备份指定的多个数据库，所有被指定的数据库中的表都会被备份，对应的创建库的语句也会生成，下例表示同时备份zsythink库与test库。
mysqldump -uroot -h192.168.1.146 --databases zsythink test -p
使用如下语句备份当前数据库服务中的所有库。
mysqldump -uroot -h192.168.1.146 --all-databases -p
其实，在某些时候，我们只是想要将数据库的表结构备份出来，不想备份数据，以便创建一个完全相同的干净数据库，那么我们可以使用如下语句备份数据库的所有表结构，如下命令表示备份zsythink数据库中的所有表的表结构，不包含表数据，不包含创建库的语句，只有创建表的语句，如下命令的"-d"选项可使用"--no-data"代替，他们效果完全相同。
mysqldump -uroot -hlocalhost -d zsythink -p
如下命令表示备份zsythink数据库中test表的表结构，不包含表数据，不包含创建库的语句，只有创建test表的语句。
mysqldump -uroot -hlocalhost -d zsythink test -p
常用的选项：
--master-data
在实际进行数据恢复时，往往需要进行时间点还原，通常的做法是先通过最近一次的备份，将数据恢复到备份时的样子，然后再通过二进制日志，将备份之后的更改操作重放一遍，这样就将数据恢复成了最近的模样，比如，备份开始时，二进制日志对应的position为123，那么我们在进行时间点还原时，则需要先通过"备份文件"将数据恢复为备份时的样子，然后再通过二进制日志文件，将position 123之后的所有操作重放一遍。但是，在还原时，我们怎么知道备份时position的值呢？没错，我们必须在备份时就做好标记，在恢复时才知道应该从哪里重放。否则在恢复时，我们则无法获取到重放二进制日志的起始点位置。
其实，备份时二进制日志文件的position非常重要，对于主从复制结构来说，我们同样需要用到它，如果，你的数据库已经运行了一段时间，里面已经存在了一些数据，而此时，你想要将数据库架构从单机架构改为主从架构，你想把当前的主机作为主服务器，然后再新加入一台服务器作为从服务器，那么，一般的做法是将主库中的数据先备份一份出来，然后导入到从库中，但是，当你从主库中备份数据时，往往是热备的，也就是说，备份完成后，有一些操作只在主库中完成了，而备份中却不存在这些数据，所以，我们使用备份在从库中将数据还原以后，还要告诉"从库"，将备份之后的操作从"主库"那边同步过来，但是，我们怎么知道从哪里开始同步呢？没错，我们必须在备份的时候就记住它的position，以便告诉从库，从哪里开始同步。其实，这与我们手动重放二进制日志时的场景并没有什么不同，它们的最终目的都是要确定通过备份还原数据以后，要从哪个位置开始执行之后的"重放"或"同步"操作。
--master-data选项有3个可用值，0、 1 、2，这三个值分别表示不同的含义
此值为0：
表示在使用mysqldump进行备份时，不记录对应二进制日志文件位置，将此值显式的设置为0与不使用此选项的效果相同。
此值为1：
表示在使用mysqldump进行备份时，记录对应二进制日志文件位置，此值为默认值，也就是说，使用--master-data与使用--master-data=1的效果相同，如果将此选项的值设置为1，则会在备份文件中生成对应的"CHANGE MASTER TO"语句，此语句中标明了备份开始时二进制日志的前缀名以及其所处的position(位置)，生成此语句的目的是，在主从复制结构中的"从服务器"中通过备份sql还原数据以后，告诉"从库"，从"主库"的二进制日志文件中的哪个位置开始"同步"。如果我们没有使用主从复制结构，同时又想要在备份时记录二进制日志文件的position，则可以将此选项的值设置为2。
此值为2：
表示在使用mysqldump进行备份时，记录对应二进制日值文件的位置，如果将此选项的值设置为2，则会在备份文件中生成对应的"CHANGE MASTER TO"语句，此语句中标明了备份开始时二进制日志的前缀名以及其所处的position(位置)，但是"CHANGE MASTER TO"语句将会被注释，与此值为1时不同，此选项值为1时，"CHANGE MASTER TO"语句不会被注释，此选项值为2时，"CHANGE MASTER TO"语句会被注释，所以，如果只是单纯的为了记录备份时的二进制日志文件位置，那么将此选项值设置为2即可。
--flush-logs
我们再来想另外一个问题，如果，我们将二进制日志的大小设置为600兆，那么，每当二进制日志的大小满600兆，对应的二进制日志文件就会发生滚动，生成一个新的二进制文件，并将原来的600兆保存，假设，我们使用mysqldump对数据库进行备份的那一刻，对应binlog的大小为300兆，也就是说，备份操作开始时，二进制日志文件的position的位置则会处于文件居中的位置，那么，当我们想要找到对应position进行重放时，此位置之前的操作记录对于我们来说都是"无用"的，可是比较尴尬的是，我们还必须找到此位置，这样就会产生一些"多余的工作量"，那么我们能不能直接避免这种情况的发生呢？必须的，劳动人民的智慧是无穷的，聪明如你一定想到了，使用一个选项就能搞定，没错，就是一个选项，它就是--flush-logs选项，当我们使用mysqldump进行备份时，如果使用了此选项，备份开始时就会滚动一次二进制日志，无论二进制日志对应的文件大小是否达到600兆，都会滚动，这样，我们就能在对应的二进制日志文件的开头部分开始重放日志了。
其他常用选项
我们说过，备份的最终目的是"还原"，而只备份表中的数据，往往是不够的，因为在数据库中，可能还存在一些存储过程和存储函数、存在一些触发器、事件表，这些"东西"也需要备份，以免最终的备份"不全"，在恢复的时候就"懵逼"了，那么，我们来看一些其他的常用的选项，总结如下。
--routines选项：表示备份时，存储过程和存储函数也会被备份。
--triggers选项：表示备份时，触发器会被备份。-
-events选项：表示备份时，事件表会被备份。
不同存储引擎下的备份
我们还需要考虑一个问题，如果我们要备份数据，我们一定要保证备份出的数据的可用性，如果备份后的数据在恢复以后，无法正常使用，那么备份出的数据也就失去了备份的意义，数据可用的前提就是数据的正确性、完整性、一致性。而不同的存储引擎，满足一致性时所使用的方法不同
表类型为innodb
我们说过，mysqldump支持对innodb存储引擎进行热备，热备的概念我们已经提到过，所谓热备，就是在备份的时候能够对数据库进行读写，但是，如果在备份时对数据库进行读写，怎样保证数据的一致性呢？没错，之前的文章已经详细解释过，如果表类型为innodb，基于"可重读"事务，即可保证热备出的数据的一致性。
在备份innodb存储引擎的表时，如果使用了--single-transaction选项，mysqldump会自动开启一个"可重读"的事务，基于这个独立的"事务"，备份出一个满足一致性的数据备份。
mysqldump自动将备份会话中的事务隔离级别设置为了"可重读"，并且开启了一个事务，而且，开始事务时，使用了"WITH CONSISTENT SNAPSHOT"，表示事务开始的那一刻，同时创建了快照，以保证备份事务中的"一致性读"。
表类型为myisam
如果你数据库中的表使用了myisam存储引擎，那么，在备份时最多只能达到温备的程度，因为myisam存储引擎不支持事务，即使我们使用--single-transaction选项对myisam表进行备份，也不会有任何作用，我们只能通过锁表的方式进行，即在备份开始到备份结束期间，备份的表会被加上读锁，以保证数据的一致性，但是如果你的mysql环境是主从环境，则可以在从服务器上进行备份操作，此处不考虑那么多，我们只要记住，对myisam表进行备份时，需要加锁以保证数据一致性即可。
对所有数据备份时，可以使用--lock-all-tables选项，对所有库的所有表加读锁，--lock-all-tables对应的短选项为-x，而且，此选项与--single-transaction选项不能同时存在，示例如下。
mysqldump -uroot -h192.168.1.146 --lock-all-tables --all-databases -p > dbbackup.sql
对指定的数据库进行备份时，可以使用--lock-tables选项，对指定库的所有表加锁，--lock-tables对应的短选项为-l，注意，此选项与--single-transaction选项同时存在时，此选项将失效，示例如下
mysqldump -uroot -h192.168.1.146 --lock-tables --databases zsythink -p > zsythink.sql
当然，我们也可以使用上述语句对innodb存储引擎的表进行备份，不过这样就不是热备了，而是温备。
常用情景：
表使用innodb存储引擎时常用的备份语句：
如果未开启二进制日志，备份指定的zsythink数据库，可以使用如下语句。
mysqldump -uroot -h192.168.1.146 --single-transaction --routines --triggers --events --databases zsythink -p > zsythink.sql
在开启二进制日志的情况下，备份指定的zsythink数据库，通常使用如下语句。
mysqldump -uroot -h192.168.1.146 --flush-logs --master-data=2 --single-transaction --routines --triggers --events --databases zsythink -p > zsythink.sql
在开启二进制日志的情况下，备份所有数据库，通常使用如下语句。
mysqldump -uroot -h192.168.1.146 --flush-logs --master-data=2 --single-transaction --routines --triggers --events --all-databases -p > dbbackup.sql
表使用myisam存储引擎时常用的备份语句：
如果未开启二进制日志，备份指定的zsythink数据库，可以使用如下语句。
mysqldump -uroot -h192.168.1.146 --routines --triggers --events --lock-tables --databases zsythink -p > zsythink.sql
在开启二进制日志的情况下，备份指定的zsythink数据库，通常使用如下语句。
mysqldump -uroot -h192.168.1.146 --flush-logs --master-data=2 --routines --triggers --events --lock-tables --databases zsythink -p > zsythink.sql
在开启二进制日志的情况下，备份所有数据库，通常使用如下语句。
mysqldump -uroot -h192.168.1.146 --flush-logs --master-data=2 --routines --triggers --events --lock-all-tables --all-databases -p > dbbackup.sql
假设，管理员误操作数据库，drop了zsythink数据库，现在需要回复，那么，可以参考如下过程。通过管理员账号登录mysql因为恢复数据时会执行大量的insert语句，如果没有特殊要求，还原时没有必要将这些操作记录到二进制日志中，所以关闭当前会话的二进制日志记录。
mysql > set sql_log_bin=OFF;
注意：所有恢复操作完成后，最好将当前会话中的sql_log_bin再次开启。
假设，通过mysqldump备份的出的zsythink数据库的数据文件存放在/testdir目录下，那么，可以在mysql提示符中使用如下命令，执行对应的sql文件。
. /testdir/zsythink.sql
上述备份sql文件执行完毕后，zsythink数据库已经恢复到了备份sql对应的时间点，如果不进行时间点恢复，那么做到这一步就算完成了恢复工作，但是我们往往需要进行时间点还原。
进行时间点恢复时，备份时间点之后的数据则需要通过二进制日志进行还原，首先，要从二进制日志中提取对应的sql，提取sql的起始位置为备份开始时那一刻二进制文件对应的position，因为在使用mysldump备份时，我们推荐使用--master-data=2选项，所以在对应的数据库备份sql文件中应该存在对应的position，提取sql的结束位置应该是drop语句对应的位置，因为咱们模拟的场景是有人误操作drop了数据库，所以结束位置应该是drop语句的位置。注意，不要把误操作的drop语句提取出来，否则重放对应sql时又会将对应的数据删除，如果是那样就前功尽弃了。