MySQL备份恢复之XtraBackup

标签：style   tar   ext   width   color   strong   get   int   art   2014   文件   

一、 简介

        我们知道，针对InnoDB存储引擎，MySQL本身没有提供合适的热备工具，ibbackup虽是一款高效的首选热备方式，但它是是收费的。好在Percona公司给大家提供了一个开源、免费的Xtrabackup热备工具，它可实现ibbackup的所有功能，并且还扩展支持真正的增量备份功能，是商业备份工具InnoDB Hotbackup的一个很好的替代品。

Xtrabackup包括两个主要工具：Xtrabackup和innobackupex：

Xtrabackup只能备份InnoDB和XtraDB两种引擎表，而不能备份MyISAM数据表。

innobackupex则是参考InnoDBHotbackup的innoback脚本修改而来的一个perl脚本，它封装了xtrabackup，主要是为了能方便的同时备份InnoDB和MyISAM引擎表。但在处理MyISAM时需要加一个读锁，这会阻塞线上服务的写操作，所以数据库中MyISAM表越少越好。另外，该工具还加入了一些其它使用选项，比如slave-info，可以在备份中记录一些Slave需要的信息，根据这些信息，可以很方便的利用备份重做Slave。

        通过Xtrabackup，不但可在线（热）备份整个库的InnoDB、XtraDB表，还可在上一次整库备份的基础上做增量备份（InnoDB only），其工作原理如下：

        首先完成一个完全备份，并记录下此时检查点的LSN（Log Sequence Number）；在进行增量备份时，比较表空间中每个页的LSN是否大于上次备份时的LSN，如果是，则备份该页，同时记录当前检查点的LSN。

注意：在增量备份时，作为备份基础的全备文件不能压缩，否则备份失效；另外，增量备份期间，表结构变更的话，变更部分的备份也会失效。

二、安装

         Pecona官方网站提供了Xtrabackup源码包、二进制包以及RPM包三种安装包，下载地址为：http://www.percona.com/downloads/XtraBackup/ 本文选择最简单方便的RPM包安装，如下：

[root@db ~]# rpm -ivh percona-xtrabackup-2.0.5-499.rhel5.x86_64.rpm

warning: percona-xtrabackup-2.0.5-499.rhel5.x86_64.rpm:Header V4 DSA signature: NOKEY, key ID cd2efd2a

Preparing...               ########################################### [100%]

  1:percona-xtrabackup    ########################################### [100%]

   安装完成后，会在/usr/bin/目录下生成如下命令工具：

[root@db ~]# cd /usr/bin/

[root@db bin]# ls xtr* inno*

innobackupex    innochecksum xtrabackup_51  xtrapchar  xtrapinfo xtrapproto  xtrapstats

innobackupex-1.5.1  xtrabackup   xtrabackup_55  xtrapin    xtrapout  xtrapreset

其中：

innobackupex                                 是备份时直接使用的工具，它是一个perl脚本，内部封装xtrabackup；

innobackupex-1.5.1                       是innobackupex文件的一个软链接；

xtrabackup                                       是备份Innodb引擎的脚本；

xtrabackup_51                                xtrabackup运行时需要调用的工具，适用于MySQL 5.1版本；

xtrabackup_55                                xtrabackup运行时需要调用的工具，适用于MySQL 5.5版本；

三、Xtrabackup的使用

        首先来学习使用Xtrabackup这个命令工具，前面提到：它只能备份InnoDB和XtraDB两种引擎表，不能备份MyISAM数据表。

通过--help参数查看该命令的用法，如下：

Usage: [xtrabackup  [--default-file=#]   --backup |  xtrabackup [--defaults-file=#] --prepare] [OPTIONS]

参数解读如下：

示例1：完全备份与恢复(InnoDB)

(1)备份

脚本内容：

[root@db xtrabak]# more xtra_backup.sh 
# 2014-04-29
mkdir -p /data/xtrabak/bak_`date +%F`/
echo "backup begin" `date`
xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/data/xtrabak/bak_`date +%F`/
cp -r /var/lib/mysql/test /data/xtrabak/bak_`date +%F`/

注意：xtrabackup只备份数据文件，并不备份数据表结构文件（.frm），所以还需手动拷贝一下，以便xtrabackup恢复时使用

执行备份脚本：

[root@db xtrabak]# sh xtra_backup.sh 
backup begin Tue Apr 29 15:22:09 CST 2014
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 499)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql/
xtrabackup: Target instance is assumed as followings.
xtrabackup:   innodb_data_home_dir = /var/lib/mysql
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = /var/lib/mysql
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 5242880
>> log scanned up to (1830807)
[01] Copying /var/lib/mysql/ibdata1 to /data/xtrabak/bak_2014-04-29/ibdata1
[01]        ...done
xtrabackup: The latest check point (for incremental): ‘1830807‘
xtrabackup: Stopping log copying thread.
.>> log scanned up to (1830807)


xtrabackup: Transaction log of lsn (1830807) to (1830807) was copied.

从输出可以看出，备份过程首先记录LSN，然后拷贝数据文件（注意，并没有备份表结构文件.frm），最后拷贝并记录LSN。备份完成后，在指定目标目录除了拷贝过来的数据文件ibdata1及表结构文件夹test外，还生成了另外两个文件，分别记录日志及检查点，如下：

[root@db xtrabak]# cd bak_2014-04-29/
[root@db bak_2014-04-29]# ls
ibdata1  test  xtrabackup_checkpoints  xtrabackup_logfile

恢复

删除库test，然后通过备份文件执行恢复，如下：

脚本内容：

说明：脚本中步骤依次为：

实施对备份文件进行恢复前的准备；

从备份文件拷贝数据表结构到默认的数据目录；

删除默认数据目录中对应的数据文件并复制备份的数据文件到默认数据目录；

修改默认数据目录权限并重启MySQL服务

执行恢复脚本：

[root@db xtrabak]# sh xtra_prepare.sh 
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 499)
xtrabackup: cd to /data/xtrabak/bak_2014-04-29/
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1830807)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 2097152
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
140429 15:28:34  InnoDB: Initializing buffer pool, size = 100.0M
140429 15:28:34  InnoDB: Completed initialization of buffer pool
140429 15:28:34  InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140429 15:28:34  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Last MySQL binlog file position 0 85912, file name ./mysql-bin.000026
140429 15:28:34 Percona XtraDB (http://www.percona.com) 1.0.17-12.5 started; log sequence number 1830807


[notice (again)]
  If you use binary log and don‘t use any hack of group commit,
  the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 85912, file name ./mysql-bin.000026


xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140429 15:28:34  InnoDB: Starting shutdown...
140429 15:28:34  InnoDB: Shutdown completed; log sequence number 1832037
Shutting down MySQL....                                    [  OK  ]
Starting MySQL.                                            [  OK  ]

执行完成后，检查发现test库已成功恢复。

示例2：增量备份与恢复

增量备份是以完全备份或上一次增量备份为基础的备份，适合数据库很大的情况，支持在线热备，备份期间不锁定表，不影响用户使用，备份恢复效率都比较高。

下面我们来模拟一次增量备份：

（1）  完全备份

现在test库有三张表，执行一次完全备份

－－脚本内容：

[root@db xtrabak]# more xtra_full_bak.sh 
# 2014-04-29
mkdir -p /data/xtrabak/full_bak_`date +%F`/
xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/data/xtrabak/full_bak_`date +%F`/
cp -r /var/lib/mysql/test/ /data/xtrabak/full_bak_`date +%F`/

－－执行脚本

[root@db xtrabak]# sh xtra_full_bak.sh 
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 499)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup:   innodb_data_home_dir = /var/lib/mysql
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = /var/lib/mysql
xtrabackup:   innodb_log_files_in_group = 3
xtrabackup:   innodb_log_file_size = 67108864
>> log scanned up to (1653514)
[01] Copying /var/lib/mysql/ibdata1 to /data/xtrabak/full_bak_2014-04-29/ibdata1
[01]        ...done
xtrabackup: The latest check point (for incremental): ‘1653514‘
xtrabackup: Stopping log copying thread.
.>> log scanned up to (1653514)


xtrabackup: Transaction log of lsn (1653514) to (1653514) was copied.

执行完成后，查看备份文件

[root@db xtrabak]# cd full_bak_2014-04-29/
[root@db full_bak_2014-04-29]# ls
ibdata1  test  xtrabackup_checkpoints  xtrabackup_logfile

（2）  增量备份

向test库中添加一张新表，然后执行增量备份

－－脚本内容：

[root@db xtrabak]# more xtra_delta_bak.sh 
# 2014-04-29
mkdir -p /data/xtrabak/delta_bak_`date +%F`/
xtrabackup --defaults-file=/etc/my.cnf --backup --target-dir=/data/xtrabak/delta_bak_`date +%F`/ --incremental-basedir=/data/xtrabak/full_bak_`date +%F`/
cp -r /var/lib/mysql/test/ /data/xtrabak/full_bak_`date +%F`/

说明：这里需要再次拷贝test库的表结构文件，因为期间可能会增加或删除表

－－执行脚本

[root@db xtrabak]# sh xtra_delta_bak.sh 
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 499)
incremental backup from 1653514 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup:   innodb_data_home_dir = /var/lib/mysql
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = /var/lib/mysql
xtrabackup:   innodb_log_files_in_group = 3
xtrabackup:   innodb_log_file_size = 67108864
>> log scanned up to (1660436)
[01] Copying /var/lib/mysql/ibdata1 to /data/xtrabak/delta_bak_2014-04-29/ibdata1.delta
[01]        ...done
xtrabackup: The latest check point (for incremental): ‘1660436‘
xtrabackup: Stopping log copying thread.
.>> log scanned up to (1660436)


xtrabackup: Transaction log of lsn (1660436) to (1660436) was copied.

执行完成后，查看备份文件

[root@db xtrabak]# cd delta_bak_2014-04-29/
[root@db delta_bak_2014-04-29]# ls
ibdata1.delta  ibdata1.meta  xtrabackup_checkpoints  xtrabackup_logfile

注意：在增量备份目录下，数据文件是以.delta结尾的，增量备份只备份上一次完全备份后被修改过的page；当然，若再次执行增量备份，可以上一次完全备份为基础，也可以第一次增量备份为基础，每次增量备份的目录都是需要修改的。

（3）  恢复

删除test库，模拟故障，然后通过完全备份及增量备份文件执行恢复。

－－脚本内容：

[root@db xtrabak]# more xtra_delta_prepare.sh 
xtrabackup --defaults-file=/etc/my.cnf --prepare --target-dir=/data/xtrabak/full_bak_`date +%F`/
xtrabackup --defaults-file=/etc/my.cnf --prepare --target-dir=/data/xtrabak/full_bak_`date +%F`/ --incremental-dir=/data/xtrabak/delta_bak_`date +%F`/
cp -r /data/xtrabak/full_bak_`date +%F`/test/ /var/lib/mysql/
rm /var/lib/mysql/ib*
cp /data/xtrabak/full_bak_`date +%F`/ib* /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
service mysql restart

－－执行脚本

[root@db xtrabak]# sh xtra_delta_prepare.sh 
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 499)
xtrabackup: cd to /data/xtrabak/full_bak_2014-04-29/
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1653514)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 2097152
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
140429 18:28:21  InnoDB: Initializing buffer pool, size = 100.0M
140429 18:28:21  InnoDB: Completed initialization of buffer pool
140429 18:28:21  InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140429 18:28:21  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Last MySQL binlog file position 0 2596, file name ./mysql-bin.000043
140429 18:28:22 Percona XtraDB (http://www.percona.com) 1.0.17-12.5 started; log sequence number 1653514


[notice (again)]
  If you use binary log and don‘t use any hack of group commit,
  the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 2596, file name ./mysql-bin.000043


xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140429 18:28:22  InnoDB: Starting shutdown...
140429 18:28:22  InnoDB: Shutdown completed; log sequence number 1653514
xtrabackup version 2.0.5 for Percona Server 5.1.59 unknown-linux-gnu (x86_64) (revision id: 499)
incremental backup from 1653514 is enabled.
xtrabackup: cd to /data/xtrabak/full_bak_2014-04-29/
xtrabackup: This target seems to be already prepared.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1660436)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = /data/xtrabak/delta_bak_2014-04-29/
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 2097152
xtrabackup: page size for /data/xtrabak/delta_bak_2014-04-29//ibdata1.delta is 16384 bytes
Applying /data/xtrabak/delta_bak_2014-04-29//ibdata1.delta to ././ibdata1...
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup:   innodb_data_home_dir = ./
xtrabackup:   innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup:   innodb_log_group_home_dir = /data/xtrabak/delta_bak_2014-04-29/
xtrabackup:   innodb_log_files_in_group = 1
xtrabackup:   innodb_log_file_size = 2097152
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Compressed tables use zlib 1.2.3
140429 18:28:22  InnoDB: Initializing buffer pool, size = 100.0M
140429 18:28:22  InnoDB: Completed initialization of buffer pool
140429 18:28:22  InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
140429 18:28:22  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Last MySQL binlog file position 0 2703, file name ./mysql-bin.000045
140429 18:28:22 Percona XtraDB (http://www.percona.com) 1.0.17-12.5 started; log sequence number 1660436


[notice (again)]
  If you use binary log and don‘t use any hack of group commit,
  the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 2703, file name ./mysql-bin.000045


xtrabackup: starting shutdown with innodb_fast_shutdown = 1
140429 18:28:22  InnoDB: Starting shutdown...
140429 18:28:23  InnoDB: Shutdown completed; log sequence number 1660436
Shutting down MySQL...                                     [  OK  ]
Starting MySQL.....                                        [  OK  ]
执行成功后，检查发现test数据库已成功恢复。

四、 Innobackupex使用

        前面提到，Innobackupex可同时备份InnoDB和MyISAM引擎表，所以通常都直接使用innobackupex。需要注意的是my.cnf中必须加上datadir这个参数，因为要根据它来定位InnoDB引擎的数据文件位置。

innobackupex也包含一系列参数，可通过innobackupex --help命令查看，此处不逐一说明了。

下面我们通过一个完整的示例来演示其用法，如下：

（1）  备份

－－脚本内容：

[root@db xtrabak]# more backup.sh 
# 2014-04-29
mkdir -p /data/xtrabak/bak_`date +%F`/
echo "backup begin" `date`
log=innobackupex_`date +%F`.log
str=bak_`date +%F`
innobackupex --user=root --password=root123 --defaults-file=/etc/my.cnf --stream=tar /data/xtrabak/$str/ 2>/data/xtrabak/$log | gzip>/data/xtrabak/$str/base.tar.gz
echo "backup end" `date`
cp /etc/my.cnf /data/xtrabak/my_`date +%F`.cnf

－－执行脚本：

[root@db xtrabak]# sh backup.sh 
backup begin Wed Apr 30 16:15:02 CST 2014
backup end Wed Apr 30 16:15:27 CST 2014

[root@db xtrabak]# cd bak_2014-04-30/
[root@db bak_2014-04-30]# ls
base.tar.gz

执行完成后，生成备份文件的压缩包

（2）  增量日志备份

由于数据库不停的对外提供服务，备份之后的操作会记录到binlong日志文件中，所以我们还应备份后续的日志文件。

此处删除几张表，并切换日志以模拟真实环境，备份完整的binlog日志文件；然后关闭数据库，删除数据库所有文件，以便模拟故障。

－－脚本内容（binlog备份到远程机器）:

（3）  恢复

－－脚本内容：

[root@db xtrabak]# more prepare.sh 
# 2014-04-30
service mysql stop
mkdir -p /data/xtrabak/prepare_`date +%F`/
tar -ixzvf /data/xtrabak/bak_`date +%F`/base.tar.gz -C /data/xtrabak/prepare_`date +%F`/
innobackupex --apply-log --user=root --defaults-file=/etc/my.cnf /data/xtrabak/prepare_`date +%F`/
innobackupex --copy-back --user=root --defaults-file=/etc/my.cnf /data/xtrabak/prepare_`date +%F`/
chown -R mysql:mysql /var/lib/mysql/
rm -rf /var/lib/mysql/xtrabackup_binlog_pos_innodb
service mysql restart

－－完全备份恢复后，通过binlog进行增量恢复

[root@db xtrabak]# mysqlbinlog --start-position="******" /data/log/mysql-bin.****** |mysql -uroot -p

注意：start-position的位置可通过解压后的备份文件查看，如下：

[root@db xtrabak]# cd prepare_2014-04-30/

或者

成功恢复后，MySQL即可正常使用。

MySQL备份恢复之XtraBackup,码迷,mamicode.com

MySQL备份恢复之XtraBackup

标签：style   tar   ext   width   color   strong   get   int   art   2014   文件   

原文地址：http://blog.csdn.net/dbaxiaosa/article/details/24704397