逻辑备份mysqldump—mydumper和物理备份xtrabackup的原理解析

逻辑备份mysqldump原理

参考网上找的一张图，可以大概理解其过程。

1. FLUSH /!40101 LOCAL / TABLES ####Closes all open tables, forces all tables in use to be closed, and flushes the query cache.
2. FLUSH TABLES WITH READ LOCK ####调用FTWRL，加全局读锁，禁止全局读写，和第一步有点重复，但是当有第一个flush tables执行的时候，如果有一个长事务的update存在的时候，第一个flush tables并不会锁住整个mysql，而当长事务执行完成后，FTWRL会很快执行，所以第一个flush tables的存在是很有必要性的，使mysql加锁更加层次化，避免长时间阻塞mysql执行线程。
3. SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ ####设置当前会话级别的事务隔离级别为RR，可重复读。可以避免不可重复读和幻读。
4. START TRANSACTION /!40100 WITH CONSISTENT SNAPSHOT / ####开启事务并获取一致性快照，获取db的一致性状态，有mysqldump参数--single-transaction决定，仅支持innodb引擎。
5. SHOW MASTER STATUS ####由参数 --master-data决定，可以显式或者注释方式记录master的binlog信息，包括master log file和master log pos俩个指标。
6. UNLOCK TABLES ####释放全局读锁
7. show databases 获取全部库开始循环，备份第一个库，建库语句show create database 后 savepoint sp 因为通过前面的一致性快照只能做到全局的commit和rollback，这里针对每个库存储point点位方便备份完单表后初始化回到之前savepoint点位。这样做不会堵塞已经备份的表的ddl操作。同时执行show tables获取库下全部表，循环执行，其中表备份show create table记录建表语句，及表数据备份为insert values，语句为SELECT /!40001 SQL_NO_CACHE / * FROM table_name；一般会加主键限制每次数量级。
8. commit关闭一致性快照事务。

逻辑备份mydumper原理

mydumper和mysqldump原理类似，最大的区别在于多线程复制。并发的粒度可以到行级别，还是通过线程分别调用FTWRL并获取一致性点位。

物理备份xtrabackup原理

Percona XtraBackup（简称PXB）是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具，支持 MySQl（Oracle）、Percona Server 和 MariaDB。

1.innobackupex在执行后会fork一个xtrabackup的进程，然后就等待xtrabackup的ibd数据文件。
2.xtrabackup在备份innoDB相关数据会启动俩个线程进行备份，一个是redo拷贝线程，负责拷贝redo文件在备份开始后新产生的数据文件。redo线程只有一个，在ibd拷贝线程之前启动，在ibd拷贝线程结束后结束。xtrabackup进程开始执行后，先启动redo拷贝线程，从最新的checkpoint点开始顺序拷贝redo日志；然后再启动ibd数据拷贝线程，在xtrabackup拷贝ibd过程中，innobackupex进程一直处于等待状态（等待文件被创建）。
3.xtrabackup拷贝完成ibd后，通知innobackupex（通过创建文件），同时自己进入等待（redo线程仍然进行拷贝）；
4.innobackupex收到xtrabackup通知后，执行FLUSH TABLES WITH READ LOCK(FTWRL),去的一致性点位，开始拷贝非ibd文件可选copy或者rsync方式俩种，拷贝非 InnoDB 文件过程中，因为数据库处于全局只读状态，如果在业务的主库备份的话，要特别小心，非 InnoDB 表（主要是MyISAM）比较多的话整库只读时间就会比较长，这个影响一定要评估到。
5.当 innobackupex 拷贝完所有非 InnoDB 表文件后，通知 xtrabackup（通过删文件） ，同时自己进入等待（等待另一个文件被创建）
6.xtrabackup 收到 innobackupex 备份完非 InnoDB 通知后，就停止 redo 拷贝线程，然后通知 innobackupex redo log 拷贝完成（通过创建文件）；
7.innobackupex 收到 redo 备份完成通知后，就开始解锁，执行 UNLOCK TABLES；
8.最后 innobackupex 和 xtrabackup 进程各自完成收尾工作，如资源的释放、写备份元数据信息等，innobackupex 等待 xtrabackup 子进程结束后退出。