逻辑备份mysqldump和物理备份xtrabackup的流程

mysqldump备份原理

备份的基本流程如下：

1. FLUSH TABLES

   功能：关闭实例上所有打开表目的：为第二步prepare，为了避免较长的事务操作造成FLUSH TABLES WITH READ LOCK操作迟迟得不到锁，但同时又阻塞了其它客户端操作

2. FLUSH TABLES WITH READ LOCK

   功能：加全局读锁目的：获得DB一致性状态

3. SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ

   功能：设置当前会话的事务隔离等级为RR，RR可避免不可重复读和幻读目的：确保在备份事务中任何时刻数据都相同

4. START TRANSACTION WITH CONSISTENT SNAPSHOT

   功能：获取当前数据库的快照，这个是由mysqldump中--single-transaction决定的目的： 简而言之，就是开启事务并对所有表执行了一次SELECT操作，这样可保证备份时，在任意时间点执行select * from table得到的数据和执行START TRANSACTION WITH CONSISTENT SNAPSHOT时的数据一致

5. obtain Log position

   功能：获取binlog的相关信息，这个是由--master-data决定的目的：记录了开始备份时，binlog的状态信息，包括MASTER_LOG_FILE和MASTER_LOG_POS

6. 备份非innodb表数据(.frm,.myi,.myd等)
   
7. unlock tables（非innodb表备份完毕）
   
8. 备份innodb表数据
   
9. 备份完成
   

xtrabackup备份原理

innobackupex的本质：innobackupex 脚本用来备份非 InnoDB 表，同时会调用 xtrabackup 命令来备份 InnoDB 表

备份的基本流程如下：

1. innobackupex 在启动后，会先 fork 一个进程，启动 xtrabackup进程，然后就等待 xtrabackup 备份完 ibd 数据文件
   
2. xtrabackup 在备份 InnoDB 相关数据时，是有2种线程的，1种是 redo 拷贝线程，负责拷贝 redo 文件，1种是 ibd 拷贝线程，负责拷贝 ibd 文件；redo 拷贝线程只有一个，在 ibd 拷贝线程之前启动，在 ibd 线程结束后结束。xtrabackup 进程开始执行后，先启动 redo 拷贝线程，从最新的 checkpoint 点开始顺序拷贝 redo 日志；然后再启动 ibd 数据拷贝线程，在 xtrabackup 拷贝 ibd 过程中，innobackupex 进程一直处于等待状态（等待文件被创建）
   
3. xtrabackup 拷贝完成idb后，通知 innobackupex（通过创建文件），同时自己进入等待（redo 线程仍然继续拷贝）
   
4. innobackupex 收到 xtrabackup 通知后，执行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位点，然后开始备份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷贝非 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 子进程结束后退出