XtraBackup初步试验

XtraBackup备份工具的介绍以及原理参见“XtraBackup原理与程序说明”

本文介绍对该工具的试验，包括备份（完全备份、部分备份）和还原等操作。

1.安装

通过官方下载页面 http://www.percona.com/downloads/XtraBackup/ 下载二进制包进行。这里下载percona-xtrabackup-2.0.6-521.tar.gz包。
shell>tar -xzvf percona-xtrabackup-2.0.6-521.tar.gz
shell>ln -s /db/script/armyknife/percona-xtrabackup-2.0.6 xtrabackup
shell>ls -l /db/script/armyknife/xtrabackup/bin
total 40276
-rwxr-xr-x. 1 mysql mysql 108823 Mar 20 05:29 innobackupex
lrwxrwxrwx. 1 mysql mysql 12 Apr 28 13:22 innobackupex-1.5.1 -> innobackupex
-rwxr-xr-x. 1 mysql mysql 2258560 Mar 20 05:29 xbstream
-rwxr-xr-x. 1 mysql mysql 12530688 Mar 20 05:24 xtrabackup
-rwxr-xr-x. 1 mysql mysql 10641245 Mar 20 05:29 xtrabackup_51
-rwxr-xr-x. 1 mysql mysql 15693986 Mar 20 05:17 xtrabackup_55
shell>vi ~/.bash_profile
…
export PATH=/db/script/armyknife/xtrabackup/bin:$PATH
shell>source ~/.bash_profile

2.备份与恢复

根据我们日常备份和恢复的需求，使用xtrabackup需要实现：
1）整个实例备份，即备份所有库
2）备份单个库
3）备份单个表

备份都应是在线操作，备份快照对应的binlog坐标应被记录。
备份本身还应支持全备和增备。
以下根据我们自身的要求，来测试xtrabackup的备份功能。

测试实例包含mysql,performance_schema和testdb三个库。
testdb中含表t1。
mysql> select * from t1;
+——+
| id |
+——+
| 1 |
| 2 |
| 3 |
+——+
3 rows in set (0.00 sec)

a)备份实例下所有库
shell>mkdir -p /db/backup/test/20130507
shell>innobackupex –host=192.168.10.178 –port=3300 –user=backup –password=23khfisF –defaults-file=/etc/my7.cnf –slave-info –no-timestamp /db/backup/test/20130507/all/ #最后指定的备份目录必须不存在。
…
innobackupex: Created backup directory /db/backup/test/20130507/all
130507 13:53:10 innobackupex: Starting mysql with options: –defaults-file=’/etc/my7.cnf’ –password=xxxxxxxx –user=’backup’ –host=’192.168.10.178′ –port=’3300′ –unbuffered –
130507 13:53:10 innobackupex: Connected to database with mysql child process (pid=29711)
130507 13:53:12 innobackupex: Connection to database server closed

130507 13:53:12 innobackupex: Starting ibbackup with command: xtrabackup_55 –defaults-file=”/etc/my7.cnf” –defaults-group=”mysqld” –backup –suspend-at-end –target-dir=/db/backup/test/20130507/all –tmpdir=/db/tmp7
innobackupex: Waiting for ibbackup (pid=29722) to suspend
innobackupex: Suspend file ‘/db/backup/test/20130507/all/xtrabackup_suspended’

xtrabackup_55 version 2.0.6 for Percona Server 5.5.16 Linux (x86_64) (revision id: undefined)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /db/data7
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /db/log7
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 1073741824
xtrabackup: using O_DIRECT
>> log scanned up to (1766161)
[01] Copying ./ibdata1 to /db/backup/test/20130507/all/ibdata1
[01] …done
[01] Copying ./testdb/t1.ibd to /db/backup/test/20130507/all/./testdb/t1.ibd
[01] …done

130507 13:53:13 innobackupex: Continuing after ibbackup has suspended
130507 13:53:13 innobackupex: Starting mysql with options: –defaults-file=’/etc/my7.cnf’ –password=xxxxxxxx –user=’backup’ –host=’192.168.10.178′ –port=’3300′ –unbuffered –
130507 13:53:13 innobackupex: Connected to database with mysql child process (pid=29741)
130507 13:53:15 innobackupex: Starting to lock all tables…
>> log scanned up to (1766161)
>> log scanned up to (1766161)
130507 13:53:26 innobackupex: All tables locked and flushed to disk
>> log scanned up to (1766161)

130507 13:53:28 innobackupex: Starting to backup non-InnoDB tables and files
innobackupex: in subdirectories of ‘/db/data7′
innobackupex: Backing up file ‘/db/data7/testdb/db.opt’
innobackupex: Backing up file ‘/db/data7/testdb/t1.frm’
innobackupex: Backing up files ‘/db/data7/mysql/*.{frm,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}’ (72 files)
innobackupex: Backing up files ‘/db/data7/performance_schema/*.{frm,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}’ (18 files)
130507 13:53:28 innobackupex: Finished backing up non-InnoDB tables and files

130507 13:53:28 innobackupex: Waiting for log copying to finish

xtrabackup: The latest check point (for incremental): ’1766161′
xtrabackup: Stopping log copying thread.
.>> log scanned up to (1766161)

xtrabackup: Transaction log of lsn (1766161) to (1766161) was copied.
130507 13:53:31 innobackupex: All tables unlocked
130507 13:53:31 innobackupex: Connection to database server closed

innobackupex: Backup created in directory ‘/db/backup/test/20130507/all’
innobackupex: MySQL binlog position: filename ‘sm_7db-bin.000006′, position 2794
innobackupex: MySQL slave binlog position: master host ”, filename ”, position
130507 13:53:31 innobackupex: completed OK!

从上述输出，可以看出备份执行的大致过程：

1. innobackupex尝试连接数据库，确认可连接；
2. 由于未指定应用程序，连接数据库确认MySQL服务器的版本，以便确定使用哪个二进制文件进行后续操作；
3. 由确定的程序（这里为xtrabackup_55，带上获取到的或默认的选项内容）执行，备份事务型存储引擎表；
4. 事务型存储引擎表备份完成后，执行FLUSH TABLES WITH READ LOCK，锁定所有表，刷新数据到磁盘；
5. 拷贝剩余的文件；
6. 释放表锁；
7. 打印出binlog相关信息；
8. 看到innobackupex: completed OK!，确定顺利完成备份。

查看生成的备份文件
shell>ls -lrt /db/backup/test/20130507/all
total 18468
-rw-r–r–. 1 mysql mysql 263 May 7 13:53 backup-my.cnf #启动实例所需的最基础的[mysqld]的InnoDB配置
-rw-r—–. 1 mysql mysql 18874368 May 7 13:53 ibdata1 #数据文件
-rw-r–r–. 1 mysql mysql 25 May 7 13:53 xtrabackup_binlog_info #快照生成时对应的binlog坐标（文件名称+位置），信息取自SHOW MASTER STATUS
-rw-r–r–. 1 mysql mysql 53 May 7 13:53 xtrabackup_slave_info #作为slave，对应到master的信息
drwx——. 2 mysql mysql 4096 May 7 13:53 testdb #数据文件夹
drwxr-xr-x. 2 mysql mysql 4096 May 7 13:53 mysql #数据文件夹
drwxr-xr-x. 2 mysql mysql 4096 May 7 13:53 performance_schema #数据文件夹
-rw-r—–. 1 mysql mysql 2560 May 7 13:53 xtrabackup_logfile #拷贝过程中的事务日志
-rw-r—–. 1 mysql mysql 77 May 7 13:53 xtrabackup_checkpoints #记录备份信息，包括类型(全备、增备)，状态，lsn信息等。这些信息可以用于全备后对应的增备。
-rw-r–r–. 1 mysql mysql 13 May 7 13:53 xtrabackup_binary #记录备份时使用的二进制程序
shell>cd /db/backup/test/20130507/all
shell>cat backup-my.cnf
# This MySQL options file was generated by innobackupex.
# The MySQL server
[mysqld]
innodb_data_file_path=ibdata1:10M:autoextend
innodb_log_files_in_group=2
innodb_log_file_size=1073741824
innodb_fast_checksum=0
innodb_page_size=16384
innodb_log_block_size=512
shell>cat xtrabackup_binlog_info
sm_7db-bin.000006 2794
shell>cat xtrabackup_slave_info #由于该库不是slave，所以没有有效master信息
CHANGE MASTER TO MASTER_LOG_FILE=”, MASTER_LOG_POS=
shell>cat xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 1766161
last_lsn = 1766161
shell>cat xtrabackup_binary
xtrabackup_55

b)恢复完全备份
备份完成后，插入了些数据到t1表中
mysql> select * from t1;
+——+
| id |
+——+
| 1 |
| 2 |
| 3 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
+——+
8 rows in set (0.00 sec)
现在想恢复到完整备份时的数据，所有库。

首先需要prepare，将备份数据进行一致性处理，使其可用。
shell>innobackupex –apply-log /db/backup/test/20130507/all #可以添加y–use-memory=2GB加速prepare过程
prepare完成后，再查看下备份文件
shell>ls -lrt
total 2117676
-rw-r–r–. 1 mysql mysql 263 May 7 13:53 backup-my.cnf
-rw-r–r–. 1 mysql mysql 25 May 7 13:53 xtrabackup_binlog_info
-rw-r–r–. 1 mysql mysql 53 May 7 13:53 xtrabackup_slave_info
drwx——. 2 mysql mysql 4096 May 7 13:53 testdb
drwxr-xr-x. 2 mysql mysql 4096 May 7 13:53 mysql
drwxr-xr-x. 2 mysql mysql 4096 May 7 13:53 performance_schema
-rw-r–r–. 1 mysql mysql 13 May 7 13:53 xtrabackup_binary
-rw-r—–. 1 mysql mysql 2097152 May 7 14:10 xtrabackup_logfile
-rw-r–r–. 1 mysql mysql 1073741824 May 7 14:11 ib_logfile1
-rw-r–r–. 1 mysql mysql 32 May 7 14:11 xtrabackup_binlog_pos_innodb
-rw-r–r–. 1 mysql mysql 1073741824 May 7 14:11 ib_logfile0
-rw-r—–. 1 mysql mysql 18874368 May 7 14:11 ibdata1
-rw-r—–. 1 mysql mysql 77 May 7 14:11 xtrabackup_checkpoints
根据更新时间的不同，可以看到新生成了三个文件，更新了三个文件。

新生成的文件包括：

1.ib_logfile0、ib_logfile1是根据backup-my.cnf生成的InnoDB日志文件；
2.xtrabackup_binlog_pos_innodb是二进制日志坐标信息，根据备份期间的事务日志进行日志校准，这个只在数据库实例下只有InnoDB或XtraDB两种类型表更新的情况下才准确。

更新的文件包括：
1.xtrabackup_logfile
2.ibdata1将备份期间的变化写入数据文件
3.xtrabackup_checkpoints记录的是当前状态，查看内容
backup_type = full-prepared
from_lsn = 0
to_lsn = 1766161
last_lsn = 1766161
发现type变成了full-prepared。

进行恢复操作
shell>innobackupex –copy-back /db/backup/test/20130507/all
报错：
Original data directory ‘./’ is not empty! at /db/script/armyknife/xtrabackup/bin/innobackupex line 580.
从这个错可以看出，第一、不指定的话，其不知道copy-back的目标地址，默认就在工作目录；第二、目标目录不能非空。

由此可以看出，我们可以将完整备份恢复到任意指定空目录。
shell>service mysql7 stop #恢复时，必须关闭当前服务器
shell>rm -rf /db/data7/* /db/log7/* /db/tmp7/*
shell>innobackupex –copy-back –defaults-file=/etc/my7.cnf /db/backup/test/20130507/all
如果执行拷贝的不是mysql用户，则应将恢复的文件拥有者修改为mysql，避免启动时遇到读写权限问题。
shell>chmod -R mysql.mysql /db/data7 /db/log7
可以看到，恢复只把数据文件拷贝到了/db/data7下，其余目录没有文件
shell>ls -lrt /db/data7 /db/log7 /db/tmp7
/db/tmp7:
total 0

/db/log7:
total 0

/db/data7:
total 18452
-rw-r–r–. 1 mysql mysql 53 May 8 11:59 xtrabackup_slave_info
-rw-r–r–. 1 mysql mysql 32 May 8 11:59 xtrabackup_binlog_pos_innodb
drwxr-xr-x. 2 mysql mysql 4096 May 8 11:59 testdb
drwxr-xr-x. 2 mysql mysql 4096 May 8 11:59 mysql
drwxr-xr-x. 2 mysql mysql 4096 May 8 11:59 performance_schema
-rw-r–r–. 1 mysql mysql 18874368 May 8 11:59 ibdata1
shell>service mysql7 start #启动
mysql> select * from t1;
+——+
| id |
+——+
| 1 |
| 2 |
| 3 |
+——+
3 rows in set (0.00 sec)
可以看到，数据恢复到了备份时的状态。

c)增备整个实例
增备需要首先由一个全备，然后在全备的基础之上进行增量备份。
以下模拟全备+增备1+增备2->恢复的流程。

步骤一、全备
shell>innobackupex –host=192.168.10.178 –port=3300 –user=backup –password=23khfisF –defaults-file=/etc/my7.cnf –slave-info –no-timestamp /db/backup/test/20130507/all2/
shell>cat /db/backup/test/20130507/all2/xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 1766934
last_lsn = 1766934

步骤二、增备1
备份完成后，对现有表t1进行些插入操作，生成增量数据。
mysql> select * from t1;
+——+
| id |
+——+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
| 10 |
| 11 |
+——+
11 rows in set (0.00 sec)
shell>innobackupex –host=192.168.10.178 –port=3300 –user=backup –password=23khfisF –defaults-file=/etc/my7.cnf –slave-info –no-timestamp –incremental –incremental-basedir=/db/backup/test/20130507/all2/ /db/backup/test/20130507/all2inc
看下生成的备份文件
shell>ls -lrt /db/backup/test/20130507/all2inc
total 392
-rw-r–r–. 1 mysql mysql 263 May 8 15:19 backup-my.cnf
-rw-r—–. 1 mysql mysql 360448 May 8 15:19 ibdata1.delta
-rw-r—–. 1 mysql mysql 44 May 8 15:19 ibdata1.meta
-rw-r–r–. 1 mysql mysql 25 May 8 15:20 xtrabackup_binlog_info
-rw-r–r–. 1 mysql mysql 53 May 8 15:20 xtrabackup_slave_info
drwx——. 2 mysql mysql 4096 May 8 15:20 testdb
drwxr-xr-x. 2 mysql mysql 4096 May 8 15:20 mysql
drwxr-xr-x. 2 mysql mysql 4096 May 8 15:20 performance_schema
-rw-r—–. 1 mysql mysql 2560 May 8 15:20 xtrabackup_logfile
-rw-r—–. 1 mysql mysql 81 May 8 15:20 xtrabackup_checkpoints
-rw-r–r–. 1 mysql mysql 13 May 8 15:20 xtrabackup_binary
shell>cd /db/backup/test/20130507/all2inc
shell>cat ibdata1.meta
page_size = 16384
zip_size = 0
space_id = 0
shell>cat xtrabackup_checkpoints
backup_type = incremental
from_lsn = 1766934
to_lsn = 1769227
last_lsn = 1769227

步骤三、增备2
在增备1的基础之上再做增备，生成增量数据
mysql> select * from t1;
+——+
| id |
+——+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
| 10 |
| 11 |
| 12 |
| 13 |
| 14 |
+——+
14 rows in set (0.00 sec)
shell>innobackupex –host=192.168.10.178 –port=3300 –user=backup –password=23khfisF –defaults-file=/etc/my7.cnf –slave-info –no-timestamp –incremental –incremental-basedir=/db/backup/test/20130507/all2inc/ /db/backup/test/20130507/all2inc2
shell>cd /db/backup/test/20130507/all2inc2
shell>cat ibdata1.meta
page_size = 16384
zip_size = 0
space_id = 0
shell>cat xtrabackup_checkpoints
backup_type = incremental
from_lsn = 1769227
to_lsn = 1770078
last_lsn = 1770078

以上三个步骤，根据lsn的变化，可以看出备份间的关系，全备为0->1766934，增备1为1766934->1769227，增备2为1769227到1770078。

d）恢复全备+增备
要想恢复到增备2的结束点，应该依次处理全备、增备1、增备2。步骤如下：
1）全备prepare：针对全备文件进行redo，注意这里不进行完整的prepare，即不需要执行undo，否则无法与增备文件合并处理。
shell>innobackupex –apply-log –redo-only /db/backup/test/20130507/all2/
…
130508 15:50:21 InnoDB: Shutdown completed; log sequence number 1766934
130508 15:50:21 innobackupex: completed OK!
shell>cat xtrabackup_checkpoints
backup_type = full-prepared
from_lsn = 0
to_lsn = 1766934
last_lsn = 1766934
2）合并增备1
shell>innobackupex –apply-log –redo-only /db/backup/test/20130507/all2/ –incremental-dir=/db/backup/test/20130507/all2inc
shell>cat /db/backup/test/20130507/all2/xtrabackup_checkpoints
backup_type = full-prepared
from_lsn = 0
to_lsn = 1769227
last_lsn = 1769227
可以看到全备文件被更新了，lsn前进到第一次增备的位置。
3）合并增备2
这次不需要–redo-only，因为这是备份序列中的最后一个，不指定–redo-only可以使生成的完整备份处于可用状态。当然也可以指定–redo-only，这样当备份时，需要MySQL服务器进行rollback，会消耗启动时间。
shell>innobackupex –apply-log /db/backup/test/20130507/all2/ –incremental-dir=/db/backup/test/20130507/all2inc2
shell>cat /db/backup/test/20130507/all2/xtrabackup_checkpoints
backup_type = full-prepared
from_lsn = 0
to_lsn = 1770078
last_lsn = 1770078

至此，/db/backup/test/20130507/all2/中保存的就是prepare后的备份记录，可以随时用于恢复。

shell>service mysql7 stop #恢复时，必须关闭当前服务器
shell>rm -rf /db/data7/* /db/log7/* /db/tmp7/*
shell>innobackupex –copy-back –defaults-file=/etc/my7.cnf /db/backup/test/20130507/all2
shell>service mysql7 start
mysql> select * from t1;
+——+
| id |
+——+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
| 10 |
| 11 |
| 12 |
| 13 |
| 14 |
+——+
14 rows in set (0.00 sec)

与增备2后的状态一致！

e）部分备份，指定库和表
Xtrabackup支持部分备份，可以是指定的库和表。
实现部分备份的前提，是启用了innodb_file_per_table选项。这里我们已经启用。

注意：恢复部分备份，不应该使用–copy-back的方式，虽然有些情况下可以实现恢复，但是更多时候会有数据文件信息和共享表空间存储的元信息不一致的情况，导致问题的产生。要恢复部分备份，应改用import的方式。

实现部分备份，可以指定–include或–tables-file或–databases。

shell>mkdir -p /db/backup/test/20130510
1)–databases
shell>innobackupex –host=192.168.10.178 –port=3300 –user=backup –password=23khfisF –databases=”testdb mysql.user mysql.db” –defaults-file=/etc/my7.cnf –slave-info –safe-slave-backup –no-timestamp /db/backup/test/20130510/p1
shell>ls -lrt /db/backup/test/20130510/p1/mysql
total 36
-rw-r–r–. 1 mysql mysql 9582 May 8 16:39 db.frm
-rw-r–r–. 1 mysql mysql 764 May 8 16:39 user.MYD
-rw-r–r–. 1 mysql mysql 2048 May 8 16:39 user.MYI
-rw-r–r–. 1 mysql mysql 10630 May 8 16:39 user.frm
-rw-r–r–. 1 mysql mysql 0 May 8 16:39 db.MYD
-rw-r–r–. 1 mysql mysql 2048 May 8 16:39 db.MYI

2)–tables-file
在testdb下创建表t2,t33表，包含与t1相同的结构和数据，再使用–tables-file进行备份。
shell>vi /tmp/bk.txt
testdb.t1
testdb.t33
mysql.db
shell>innobackupex –host=192.168.10.178 –port=3300 –user=backup –password=23khfisF –tables-file=/tmp/bk.txt –defaults-file=/etc/my7.cnf –slave-info –safe-slave-backup –no-timestamp /db/backup/test/20130510/p2
shell>ls -lrt /db/backup/test/20130510/p2/testdb
total 216
-rw-r–r–. 1 mysql mysql 8556 May 8 16:39 t1.frm
-rw-rw—-. 1 mysql mysql 8556 May 10 09:35 t33.frm
-rw-r—–. 1 mysql mysql 98304 May 10 10:22 t33.ibd
-rw-r—–. 1 mysql mysql 98304 May 10 10:22 t1.ibd

3)–include
经测试，–include=<正则> 的方式，正则似乎并不好用，支持得不好，不推荐使用。

可以看到，部分备份，只包含指定的库、表的文件，未指定的表不会备份出来。

f)恢复指定库和表
首先需要prepare，将备份数据进行一致性处理，使其可用
shell>innobackupex –apply-log –export /db/backup/test/20130510/p2
执行过程中会报如下类似信息：
130510 11:03:03 InnoDB: Error: table ‘testdb/t2′
     InnoDB: in InnoDB data dictionary has tablespace id 8,
     InnoDB: but tablespace with that id or name does not exist. It will be removed from data dictionary.
由于数据文件时部分备份，而共享表空间包含未备份出的表、库信息，所以会报类似上述错误，innobackupex会用xtrabackup从共享表空间中删除这部分未备份出来的表的信息。未来使用就不会再报类似错误。
如果指定了export，则会生成如下信息
130510 11:03:04 Percona XtraDB (http://www.percona.com) 1.1.8-20.1 started; log sequence number 1778362
     xtrabackup: export option is specified.
     xtrabackup: export metadata of table ‘testdb/t33′ to file `./testdb/t33.exp` (1 indexes)
     xtrabackup: name=GEN_CLUST_INDEX, id.low=22, page=3
     xtrabackup: export metadata of table ‘testdb/t1′ to file `./testdb/t1.exp` (1 indexes)
     xtrabackup: name=GEN_CLUST_INDEX, id.low=20, page=3
和以前一样，看到130510 11:03:21 innobackupex: completed OK!就可以认为prepare完成。

prepare后，可以通过两种方式实现恢复：
方法一、import
针对Percona Server的XtraDB引擎，可以import到任何实例和任何库下，只要prepare时指定了–export即可。
而普通的5.6以前版本的MySQL服务器，import只能是恢复到原实例、原表，该表不能是备份后重建过或者truncate过。因为即使是独立表空间，InnoDB表的表定义信息还是保存在共享表空间中，而表定义信息是包含了db name以及table id(表重建或truncate后就更新了)等，而且独立表空间文件中，transaction ID和log sequence number不同实例又是不一样的。
这里，针对恢复回原环境，我们可以：
shell>alter table t1 discard tablespace;
然后将备份的t1.ibd文件拷贝至t1.frm所在目录，然后：
shell>alter table t1 import tablespace;
这样，就可以重新操作t1了，数据是备份时的数据。

方法二、直接拷贝至干净的datadir目录，干净意指没有其他库和表，当然，确保datadir目录下有mysql库。操作不再赘述。

3.小结

以上的实践仅仅针对基本的备份和恢复操作，未涉及到远程备份、压缩等。初步实践下来，针对我们使用的MySQL 5.5版本，整个实例备份和制定库表备份均可，但是备份的独立的表在使用上没有mysqldump出的逻辑备份那么易于迁移和和使用。Xtrabackup可以作为逻辑备份的辅助，尤其针对大库大表可以节省大量的CPU时间。

The post XtraBackup初步试验 appeared first on SQLParty.