Mysqldump
Mysqldump用于备份，不得不提两个关键的参数：
--single-transaction：在开始备份前，执行start transaction命令，以此来获取一致性备份，该参数仅对innodb存储引擎有效。
--master-data=2：主要用于记录一致性备份的位点。
理解Mysqldump工作原理，一定要将事务表(innodb)和非事务表(比如myisam)区别对待，因为备份的流程与此息息相关。而且，到目前为止，我们也无法规避myisam表，即使我们的所有业务表都是innodb，因为mysql库中系统表仍然采用的myisam表。
备份的基本流程如下：
1.调用FTWRL(flush tables with read lock)，全局禁止读写
2.开启快照读，获取此时的快照(仅对innodb表起作用)
3.备份非innodb表数据(*.frm,*.myi,*.myd等)
4.非innodb表备份完毕后，释放FTWRL锁
5.逐一备份innodb表数据
6.备份完成。
整个过程，可以参考我同事的一张图，但他的这张图只考虑innodb表的备份情况，实际上在unlock tables执行完毕之前，非innodb表已经备份完毕，后面的t1,t2和t3实质都是innodb表，而且5.6的mysqldump利用保存点机制，每备份完一个表就将一个表上的MDL锁释放，避免对一张表锁更长的时间。
大家可能有一个疑问，为啥备份innodb表之前，就已经将锁释放掉了，这实际上是利用了innodb引擎的MVCC机制，开启快照读后，就能获取那个时间的一致的数据，无论需要备份多长时间，直到整个事务结束(commit)为止。
Mydumper
Mydumper原理与Mysqldump原理类似，最大的区别是引入了多线程备份，每个备份线程备份一部分表，当然并发粒度可以到行级，达到多线程备份的目的。这里要解决最大一个问题是，如何保证备份的一致性，其实关键还是在于FTWRL。对于非innodb表，在释放锁之前，需要将表备份完成。对于innodb表，需要确保多个线程都能拿到一致性位点，这个动作同样要在持有全局锁期间完成，因为此时数据库没有读写，可以保证位点一致。所以基本流程如下：
物理备份(Xtrabackup)
相对于逻辑备份利用查询提取数据中的所有记录，物理备份更直接，拷贝数据库文件和日志来完成备份，因此速度会更快。当然，无论是开源的Mydumper还是官方最新的备份工具(5.7.11的mysqlpump)都支持了多线程备份，所以速度差异可能会进一步缩小，至少从目前生产环境来看，物理备份使用还是比较多的。由于Xtrabackup支持备份innodb表，实际生产环境中我们使用的工具是innobackupex，它是对xtrabackup的一层封装。innobackupex脚本用来备份非 InnoDB 表，同时会调用 xtrabackup命令来备份 InnoDB 表，innobackupex的基本流程如下：
