mysql备份优化_MySQL备份流程及优化

1.Flush table with read lock 的认识：

Flush table with read lock(简称:  FTWRL) 有哪些问题：

例如让DBA头大的long query，FTWRL需要等待所有的表没有引用后关闭所有表，long query 导致FTWRL无法执行成功。这也是经常备份被hung住，有可能导致备份失败。

2.老版本如何获得一致性的备份：

2.1 mysqldump

早期使用mysqldump 来备份，xtrabackup 成为当前主流Inoodb＋MyiSAM热备工具。

从MySQL 5.1开始： 在最后备份非事务引擎表的时候为了获得一致性备份需要在MySQL上获得  Flush table with read lock，有可能在压力大的库或者有事务没有正常关闭的连接在，会导致备份无法因超时后导致备份失败。还有如果在master 上备份会导致加FTWRL到最后这段时间会堵塞所有的DML，Master这段时间变成只读，长短取决于非事务表的数量和大小。

percona server 从5.6.16-64.0开始优化了mysqldump备份，引入轻量级锁，lock tables for backup  和   lock binlog for backup。mysqldump 增加参数：--lock-for-backup

2.2 xtrabackup:

version<2.2.0 :也是加FTWRL，和老版本mysqldump类似。老版本的改进：Improved FLUSH TABLES WITH READ LOCK handling：https://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/improved_ftwrl.html。

version>=2.2.0 引入轻量级锁，lock tables for backup;  和   lock binlog for backup;

xtrabackup物理备份流程变化如下：

修改之前(<2.2.0 )的流程：

1.get Redo LSN

2.copy 系统表空间+事务引擎表的数据文件+后台子进程(IBACKUP)拷贝Redo

3.FLUSH TABLES WITH READ LOCK

4.copy 所有 *.frm文件，非事务引擎表(MyISAM、ARCHIVE等)数据＋索引文件

5.Get the binary log coordinates(坐标/位点)

6.finalize the background copy of REDO log

7.unlock tables;

修改之后(>=2.2.0 )的流程：

1.get Redo LSN

2.copy 系统表空间+事务引擎表的数据文件+后台子进程(IBACKUP)拷贝Redo

3.LOCK TABLES FOR BACKUP

4.copy  所有 *.frm文件，非事务引擎表(MyISAM、ARCHIVE等)数据＋索引文件

5.LOCK BINLOG FOR BACKUP

6.finalize the background copy of REDO log

7.UNLOCK TABLES;

8.get the binary log coordinates(坐标/位点)

9.UNLOCK BINLOG

3.优化的目标

3.1 引入备份锁的优势

LOCK TABLES FOR BACKUP:

作用：获取一致性数据

a)禁止非事务引擎(非InnoDB)表写入(也即DML)。

b)禁止所有表的DDL。

优点：

a)不会被大查询阻塞。

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

LOCK BINLOG FOR BACKUP:

作用：获取一致性位点。

a)禁止对binlog的位点操作(不允许DML、DDL)

优点：

a)时间短，对db的影响很小。

下面是xtrabackup-2.2.4的备份主要log：