作者:史彩哲 | 来源:互联网 | 2017-05-12 15:07
CentOSrelease5.4(Final)x86_64GNULinux2.6.18-164.el52.安装配置(1)安装配置mysql-5.1.56在MySQL5.1.38前的版本
CentOS release 5.4 (Final) x86_64 GNU/Linux 2.6.18-164.el52.安装配置(1)安装配置mysql-5.1.56 在MySQL 5.1.38前的版本
一.Xtrabackup 简介及备份原理说明:
Xtrabackup是由percona开发的一个开源软件,能够非常快速地备份与恢复mysql数据库,且支持在线热备份(备份时不影响数据读写),此软件可以说是innodb热备工具ibbackup的一个开源替代品
Xtrabackup中包含两个工具:
l xtrabackup -用于热备份innodb,xtradb引擎表的工具,不能备份其他表。
l innobackupex-对xtrabackup封装的perl脚本,提供了用于myisam(会锁表)和innodb引擎,及混合使用引擎备份的能力。
Xtrabackup可以做什么
l 在线(热)备份整个库的InnoDB, XtraDB表
l 在xtrabackup的上一次整库备份基础上做增量备份(innodb only)
l 以流的形式产生备份,可以直接保存到远程机器上(本机硬盘空间不足时很有用)
MySQL数据库本身提供的工具并不支持真正的增量备份,二进制日志恢复是point-in-time(时间点)的恢复而不是增量备份。Xtrabackup工具支持对InnoDB存储引擎的增量备份,工作原理如下:
(1)首先完成一个完全备份,并记录下此时检查点的LSN(Log Sequence Number)。
(2)在进程增量备份时,比较表空间中每个页的LSN是否大于上次备份时的LSN,如果是,则备份该页,同时记录当前检查点的LSN。
在Xtrabackup的wiki上简单的介绍了一下实现的原理:
首先,在logfile中找到并记录最后一个checkpoint(“last checkpoint LSN”),然后开始从LSN的位置开始拷贝InnoDB的logfile到xtrabackup_logfile;接着,开始拷贝全部的数据文件.ibd;在拷贝全部数据文件结束之后,才停止拷贝logfile。
因为logfile里面记录全部的数据修改情况,所以,,即时在备份过程中数据文件被修改过了,恢复时仍然能够通过解析xtrabackup_logfile保持数据的一致。
Tip1:Xtrabackup是一个用于备份InnoDB/XtrDB的工具,真正的在线备份(不影响数据的读写),InnoDB Hot Backup的开源替代品。
Tip2:在使用参数stream=tar备份的时候,你的xtrabackup_logfile可能会临时放在/tmp目录下,如果你备份的时候并发写入较大的话xtrabackup_logfile可能会很大(5G+),很可能会撑满你的/tmp目录,可以通过参数--tmpdir指定目录来解 决这个问题。
备份原理
XtraBackup基于InnoDB的crash-recovery功能。它会复制innodb 的data file,由于不锁表,复制出来的数据是不一致的,在恢复的时候使用crash-recovery,使得数据恢复一致。
InnoDB维护了一个redo log,又称为 transaction log,事务日志,它包含了innodb数据的所有改动情况。当InnoDB启动的时候,它会先去检查data file和transaction log,并且会做二步操作:
1.It applies committed transaction log entries to the data files
2.it performs an undo operation on any transactions that modified data but did not commit.
XtraBackup在备份的时候, 一页一页地复制innodb的数据,而且不锁定表,与此同时,XtraBackup还有另外一个线程监视着transactions log,一旦log发生变化,就把变化过的log pages复制走。为什么要急着复制走呢? 前几章的时候就提过这个问题,因为transactions log文件大小有限,写满之后,就会从头再开始写,所以新数据可能会覆盖到旧的数据。
在prepare过程中,XtraBackup使用复制到的transactions log 对备份出来的innodb data file 进行crash recovery。
实现细节
文件权限
xtrabackup以read-write模式打开innodb的数据文件,然后对其进行复制。其实它不会修改此文件。也就是说,运行xtrabackup的用户,必须对innodb的数据文件具有读写权限。
为什么要用rw模式呢?直接read模式不好么?
因为xtrabackup采用了其内置的innodb库来打开文件,而innodb库打开文件的时候就是rw的。
Tuning the OS Buffers
因为XtraBackup要从文件系统中复制大量的数据,所以它尽可能地使用posix_fadvise(),来告诉OS不要缓存读取到的数据,从而提升性能。因为这些数据不会重用到了,OS却没有这么聪明。如果要缓存一下的话,几个G的数据,会对OS的虚拟内存造成很大的压力,其它进程,比如mysqld很有可能被swap出去,这样系统就会受到很大影响了。
posix_fadvise(file,0,0, POSIX_FADV_DONTNEED)
而且XtraBackup在读取数据的时候还尽可能地预读:
posix_fadvise(file,0,0, POSIX_FADV_SEQUENTIAL)
复制数据文件
在备份innodb page的过程中,XtraBackup每次读写1MB的数据,1MB/16KB=64个page。
这个不可配置。读1MB数据之后,XtraBackup一页一页地遍历这1MB数据,使用innodb的buf_page_is_corrupted()函数检查此页的数据是否正常,如果数据不正常,就重新读取这一页,最多重新读取10次,如果还是失败,备份就失败了,退出。
It skips this check on the doublewrite buffer??
在复制transactions log的时候,每次读写512KB的数据。同样不可以配置。