xtrabackup的执行过程

标签：过程   防止   sql   ike   设置   png   时间   cto   连接mysql   

执行全量备份过程中对数据库进行的操作

可以看出执行xtrabackup进行全量备份总共有两个线程

• SET SESSION lock_wait_timeout=31536000的作用是：因为如果某个会话中使用了lock tables语句对某表加了锁，或者某个会话在进行DDL，又或者某个会话正在进行一个大的事务，那么flush tables和flush tables with read lock会被阻塞。设置锁等待时间是为了防止innobackup执行获取全局锁超时而导致备份失败退出。

• FLUSH NO_WRITE_TO_BINLOG TABLES的作用是： 关闭所有打开的表，强制关闭所有正在使用的表，并刷新查询缓存和预准备语句缓存。还会从查询缓存中删除查询结果。默认情况下flush语句会写入binlog，这里使用no_write_to_binlog禁止记录。查看Binlog发现，binlog内真的啥都没记录。

• FLUSH TABLES WITH READ LOCK的作用是：关闭所有被打开的表，并且使用全局锁锁住所有库的所有表（锁住之后只能被select，不能做其他操作）。当我们备份或者需要数据库的一致状态时，这个是最高效的方式。如果有事务存在，那么该事务提交时会hang住，不会回滚。但是不会阻止数据库往log tables（比如general_log和slow log）里插入数据。

• FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS的作用是：将innodb层的重做日志持久化到磁盘，然后再进行拷贝。说白了就是在所有的事务表和非事务表备份完成，获取全局读锁，且使用了show master status语句获取了binlog的pos之后，执行刷新redo log buffer中的日志到磁盘中，然后redo log copy线程拷贝这最后的redo log日志数据。为啥这样数据就是完整的？因为获取了全局读锁到unlock tables释放之前，不会再有请求进来。

• UNLOCK TABLES的作用是：释放全局读锁。

• 在flush tables with read lock和unlock tables之间，执行了下面操作
  a、 拷贝所有非事务表，如系统MyISAM表
  b、 将redo log buffer落盘
  c、 拷贝redo log

• XtraBackup备份全过程
  1、连接mysql进行版本检查。
  2、通过读取配置文件，获取数据和日志文件位置。
  3、扫描监控读取redo log，有新的redo log就拷贝到xtrabackup的logfile中。
  4、拷贝共享表空间文件，innodb的.ibd数据文件
  5、关闭所有打开的表，获取全局读锁，开始拷贝非Innodb的表和文件Starting to backup non-InnoDB tables and files
  6、将redo log落盘，拷贝到xtrabackup的logfile中。
  7、释放全局读锁。
  8、记录binlog信息等，备份结束。

• 对全备进行恢复时，并没有对数据库进行任何操作，全量日志中无任何记录

• 增量备份只针对innodb和全量备份的不同之处在于：
  A、在对增量innodb表等进行拷贝前，会统计变化的页儿的数量
  SELECT ‘INNODB_CHANGED_PAGES‘, COUNT(*) FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE ‘INNODB_CHANGED_PAGES‘
  
  B、使用全扫描进行增备，备份的共享表空间和ibd文件等都是增量，后缀为.delta
  

xtrabackup的执行过程

标签：过程   防止   sql   ike   设置   png   时间   cto   连接mysql   

原文地址：http://blog.51cto.com/8370646/2150179