mysqldump,mydumper以及xtrabackup备份流程简述

45321ttt

mysqldump备份原理
备份的基本流程如下：
1.调用FTWRL(flush tables with read lock)，全局禁止读写
2.开启快照读，获取此时的快照(仅对innodb表起作用)
3.备份非innodb表数据(*.frm,*.myi,*.myd等)
4.非innodb表备份完毕后，释放FTWRL锁
5.逐一备份innodb表数据
6.备份完成。

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