原文地址:http://blog.chinaunix.net/uid-20785090-id-4212816.html
xtrabackup作为innodb的hotbackup工具,由percona公司开发,因开源,热备份和物理备份而在mysql中部署广泛,详情的说明可见之前的博客讨论.
在物理级别热备份主要的一大挑战就是在文件级别数据块不一致.我们知道innodb的单个page大小由innodb_page_size 来决定,一般为16K.由4个文件系统4K的块组成.
mysql> show global variables like 'innodb_page_size';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| innodb_page_size | 16384 |
+------------------+-------+
1 row in set (0.00 sec)
由于是热备份,当备份工具在拷贝innodb page的时候,数据库本身的进程也有可能在写这个page那么备份工具拷贝出来的page,就有可能是坏的,也称为page 头尾不一致或是page断裂.这也就是为什么普通的os复制工具不能用来做为数据库物理热备份的工具原因.
再看来看xtrbackup工具是怎么解决这一问题的.在备份开始的时候,xtrabackup会像普通的拷贝工具一样去复制所有的innodb page,所以也会有page断裂的问题存在。xtrabackup在备份开始的时候,生成另一个线程去拷贝当前的innodb的事务日志, 并同时监控innodb的事务日志文件,一旦有生成新的innodb的事务日志,也会同时写到xtrabckup自己的日志中去.
在备份结束后,xtrabacup得到的结果是一份有page断裂的数据文件和备份期间所有的innodb的事务日志.这个时候的情况和mysql实例崩溃的结果是一样的(实例崩溃后数据文件不完整,事务日志完整).xtrabackup还需要一个过程,称为prepare,这个过程所做的事情和mysql实例崩溃后所做的操作基本一致。利用坏的数据文件和事务日志进行rollback和forward操作。
xtrabckup本身链接了innodb相关的库,所在我们在prepare阶段看到innodb的启动和关闭信息,很类似于标准的mysql实例启动和关闭过程,实质是我们在prepare的时候,xtrabackup在调用innodb相关的代码进行实例恢复.prepare过后,xtrabackup备份文件就是一个一致性的数据拷贝,可以直接用来启动mysql。
可以看到xtrabackup通过innodb的事务日志来和数据page,进行实例恢复,然后得到一致性的备份.而对于那些非innodb的表则无能为力了,因为没有事务日志.所以我们可以看到在xtrackup备份Myisam的表,还是需要只读表锁来进行锁定,然后再备份数据文件,和普通的拷贝工具无异.