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库系统表存在,导致会锁一定的时间。