http://blog.itpub.net/15480802/viewspace-1173479/
1 原理
分3个阶段:备份backup – 预恢复prepare -- 恢复restore
注:复制innodb表文件时可能包含不完整事务,需要prepare将其变为consistent
首先复制所有的Innodb数据文件,这样复制出来的文件肯定是不一致的,然后对每个文件进行崩溃恢复处理,最终达到一致.
XtraBackup在启动的时候会记录一个LSN(log sequence number),然后就把所有的Innodb数据文件复制出来,这样复制出来的数据文件是不一致的,但是XtraBackup会在后台运行一个进程把所有对redo log file的修改记录下来;
以上的操作是由xtrabackup二进制程序(比如xtrabackup_55)完成的,如果使用innobackupex 脚本,刚才的步骤完成以后,innobackupex就会去备份MyISAM表和.frm文件,这时要保证数据的一致性就会先锁表了,通过FLUSH TABLES WITH READ LOCK命令锁表然后把文件复制出来,再释放掉这个锁。
在恢复数据的时候,要经过prepare(recovery)和restore两个步骤。在prepare结束以后,Innodb的表恢复到了复制Innodb文件结束的时间点,这个时间点也就是锁表复制MyISAM表的起点,所以最终数据是一致的。一般我们在恢复的时候执行两次prepare,是因为第二次prepare会帮助我们生成redo log文件,从而加快MySQL数据库启动的速度。
备份
$ innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/
--将数据库备份放在BACKUP-DIR目录,默认新建一个子目录,--no-timestamp会跳过此功能;
prepare
$ innobackupex --apply-log /path/to/BACKUP-DIR
此时数据可以被程序访问使用;可使用—use-memory选项指定所用内存以加快进度,默认100M;
恢复
$ innobackupex --copy-back /path/to/BACKUP-DIR
从my.cnf读取datadir/innodb_data_home_dir/innodb_data_file_path等变量;
先复制MyISAM表,然后是innodb表,最后为logfile;--data-dir目录必须为空
2 增量备份
首先要做全备,每个备份目录都保有xtrabackup-checkpoints文件,内容如下
backup_type = full-backuped
from_lsn = 0
to_lsn = 1291135
增量备份以to_lsn为起点
$ innobackupex --incremental /data/backups --incremental-basedir=BASEDIR
其xtrabackup-checkpoints文件内容如下
backup_type = incremental
from_lsn = 1291135
to_lsn = 1352113
可再此基础上继续增量备份
增量备份的prepare有点复杂,如果对base backup执行事务一致性恢复,则其不能再用于增量备份恢复,为此须指定—redo-only选项;
innobackupex --apply-log --redo-only BASE-DIR
innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1
innobackupex --apply-log BASE-DIR --incremental-dir=INCREMENTAL-DIR-2
当合并完所有的增量备份后,开始回滚所有未提交的事务
innobackupex --apply-log BASE-DIR
3 恢复单表
Oracle rman提供了restore datafile,针对坏块也有blockrecover,即尽可能的避免全库恢复;
Innobackx也提供了类似功能,允许恢复单个表空间;
对备份执行prepare
$ innobackupex --apply-log --export /path/to/backup
--export让innodb采用slow shutdown(full purge + change buffer merge),以保证表空间处于一致性并被import;
针对每个表,其文件列表如下
/data/backups/mysql/test/export_test.exp
/data/backups/mysql/test/export_test.ibd
/data/backups/mysql/test/export_test.cfg--innodb数据字典的dump,5.6起不是必需;
恢复单表
mysql> CREATE TABLE mytable (...) ENGINE=InnoDB; --创建相同结构的表
mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
将.ibd/.exp/.cfg复制到数据目录
mysql> ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;
4 基于时间点的恢复
每个备份目录都有一个xtrabackup_binlog_info,记录备份binlog时数据库当前位置,这也是数据库一致性恢复的终点;
$ cat /path/to/backup/xtrabackup_binlog_info
mysql-bin.000003 57
$ innobackupex --copy-back /path/to/backup
待恢复完成后,便可通过mysqlbinlog执行时间点恢复
$ mysqlbinlog /path/to/datadir/mysql-bin.000003 /path/to/datadir/mysql-bin.000004 \
--start-position=57 --stop-datetime="11-12-25 01:00:00" | mysql -u root –p
5 在slave执行备份
须留意以下两个参数
--slave-info
This option is useful when backing up a replication slave server. It prints the binary log position and name of the master server. It also writes this information to the xtrabackup_slave_info file as a CHANGE MASTER command. A new slave for this master can be set up by starting a slave server on this backup and issuing a CHANGE MASTER command with the binary log position saved in the xtrabackup_slave_info file.
--safe-slave-backup
Stop slave SQL thread and wait to start backup until Slave_open_temp_tables in SHOW STATUS is zero. If there are no open temporary tables, the backup will take place, otherwise the SQL thread will be started and stopped until there are no open temporary tables. The backup will fail if Slave_open_temp_tables does not become zero after --safe-slave-backup-timeout seconds. The slave SQL thread will be restarted when the backup finishes.
http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/innobackupex_script.html
http://www.banping.com/2011/07/01/xtrabackup-process-backgroud/
http://www.mysqlperformanceblog.com/2012/01/25/how-to-recover-a-single-innodb-table-from-a-full-backup/