mysqldump备份原理

备份的基本流程如下：

1.调用FTWRL(flush tables with read lock)，全局禁止读写

2.开启快照读，获取此时的快照(仅对innodb表起作用)

3.备份非innodb表数据(*.frm,*.myi,*.myd等)

4.非innodb表备份完毕后，释放FTWRL锁

5.逐一备份innodb表数据

6.备份完成。


shell> mysqldump --all-databases --master-data --single-transaction > all_databases.sql

执行流程

（1）FLUSH   TABLES

（2）FLUSH TABLES WITH READ LOCK

（3）SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ

（4）START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */

（5）SHOW MASTER STATUS

（6）UNLOCK TABLES

global read lock的持续时间很短，获取当前binlog的位置信息后立即释放；

 注意： 在执行时如果当前有一个事务长时间没有结束，那么FLUSH TABLES WITH READ LOCK将会一直等待，而更加严重的是，阻塞的FLUSH TABLES WITH READ LOCK会进一步阻塞后续的DML，从而造成mysql hang；


Mydumper

Mydumper原理与Mysqldump原理类似，最大的区别是引入了多线程备份，每个备份线程备份一部分表，当然并发粒度可以到行级，达到多线程备份的目的。

如何保证备份的一致性，其实关键还是在于FTWRL。

对于非innodb表，在释放锁之前，需要将表备份完成。

对于innodb表，需要确保多个线程都能拿到一致性位点，这个动作同样要在持有全局锁期间完成，因为此时数据库没有读写，可以保证位点一致


xtrabackup

innobackupex的基本流程如下：

1.开启redo日志拷贝线程，从最新的检查点开始顺序拷贝redo日志；

2.开启idb文件拷贝线程，拷贝innodb表的数据

3.idb文件拷贝结束，通过"LOCK BINLOG FOR BACKUP"来获取一致性位点；

4.通过LOCK TABLES FOR BACKUP命令来备份非innodb表数据；

5.由于此时没有新事务提交，等待redo日志拷贝完成

6.最新的redo日志拷贝完成后，相当于此时的innodb表和非innodb表数据都是最新的

7.获取binlog位点，此时数据库的状态是一致的。

8.释放锁，备份结束。



LOCK TABLES FOR BACKUP

作用：备份数据

1.禁止非innodb表更新

2.禁止所有表的ddl

优化点：

1.不会被大查询堵塞(关闭表)

2.不会堵塞innodb表的读取和更新，这点非常重要，对于业务表全部是innodb的情况，则备份过程中DML完全不受损

UNLOCK TABLES


LOCK BINLOG FOR BACKUP

作用：获取一致性位点。

1.禁止对位点更新的操作

优化点：

1.允许DDl和更新，直到写binlog为止。

UNLOCK BINLOG


FTWRL(flush tables with read lock)

无论是哪种备份工具，为了获取一致性位点，都强依赖于FTWRL。这个锁杀伤力非常大，因为持有锁的这段时间，整个数据库实质上不能对外提供写服务的。

由于FTWRL需要关闭表，如有大查询，会导致FTWRL等待，进而导致DML堵塞的时间变长。

即使是备库，也有SQL线程在复制来源于主库的更新，上全局锁时，会导致主备库延迟。

FTWRL这把锁持有的时间主要与非innodb表的数据量有关，如果非innodb表数据量很大，备份很慢，那么持有锁的时间就会很长。

即使全部是innodb表，也会因为有mysql库系统表存在，导致会锁一定的时间。