xtrabackup备份和恢复MySQL

xtrabackup备份和恢复MySQL

xtrabackup有两个主要的工具：innobackupex和xtrabackup，xtrabackup只能备份InnoDB和XtraDB数据表，innobackupex封装了xtrabackup，可以备份MyISAM数据表。

MySQL数据库本身提供的工具并不支持真正的增量备份，二进制日志恢复是point-in-time(时间点)的恢复而不是增量备份。Xtrabackup工具支持对InnoDB存储引擎的增量备份，工作原理如下：

1.首先完成一个完全备份，并记录下此时检查点的LSN(LogSequence Number)。

2.在进程增量备份时，比较表空间中每个页的LSN是否大于上次备份时的LSN，如果是，则备份该页，同时记录当前检查点的LSN。

 

1.下载xtrabackup（下载二进制版本免安装）

# wget http://www.percona.com/redir/downloads/XtraBackup/XtraBackup-1.5/Linux/binary/x86_64/xtrabackup-1.5.tar.gz

# tar zxvfxtrabackup-1.5.tar.gz -C /usr/local/

源码安装过程具体参见源码目录下BUILD.txt文件。

 

2.xtrabackup选项注释如下：

--print-defaults显示默认选项。Xtrabackup默认情况会去读my.cnf文件，读取顺序是/etc/my.cnf /etc/mysql/my.cnf /usr/local/etc/my.cnf ~/.my.cnf

--no-defaults 忽略任何my.cnf文件选项

--defaults-file=#读取指定的my.cnf文件

--defaults-extra-file=#再读取另外一个文件

--target-dir=name目的目录，默认目录在./xtrabackup_backupfiles/，相对于datadir目录

--backup 备份

--stats 计算datadir目录统计信息

--prepare 从backup恢复

--export 在恢复时，创建文件导入到另一个数据库

--apply-log-only在恢复时，停止恢复进程不进行LSN只使用log

--print-param 打印出参数

--use-memory=#buffer_pool_size值

--suspend-at-end在备份时，创建xtrabackup_suspended文件，直到备份完成后删掉

--throttle=# 限制IO总数

--log-stream 记录标准输出信息xtrabackup_logfile

--extra-lsndir=name仅适用于backup，保存另一份xtrabackup_checkpoints文件

--incremental-lsn=name仅适用于backup，增量备份

--incremental-basedir=name仅适用于backup，增量备份目录

--incremental-dir=name仅适用于prepare，恢复指定目录下的.delta文件和日志文件

--tables=name 过滤某些表

--tables_file=name过滤database.table列表文件

--create-ib-logfile

-h,--datadir=name datadir目录

-t,--tmpdir=name tmpdir目录

--parallel=# 默认为1.传输数据文件的并行线程数。没有任何流模式的影响

--innodb_* 有关innodb参数

 

3.innobackupex-1.5.1选项注释如下：

innobackupex-1.5.1[--sleep=MS] [--compress[=LEVEL]] [--include=REGEXP] [--user=NAME] 

           [--password=WORD] [--port=PORT][--socket=SOCKET] [--no-timestamp] 

           [--ibbackup=IBBACKUP-BINARY][--slave-info] [--stream=tar]

           [--scpopt=OPTIONS-FOR-SCP]

           [--defaults-file=MY.CNF]

           [--databases=LIST][--remote-host=HOSTNAME] [--no-lock] BACKUP-ROOT-DIR

对数据库进行热备。默认情况下以当前时间戳创建备份根目录。上述命令完整备份所有MyISAM和InnoDB引擎表以及索引。包含.frm,.MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .opt, .par和InnoDB数据和日志文件。使用mysql客户端程序连接mysql服务器，运行ibbackup(InnoDB热备程序)作为一个子进程。

 

innobackupex-1.5.1--apply-log [--use-memory=MB] [--uncompress] [--defaults-file=MY.CNF]

           [--export] [--redo-only][--ibbackup=IBBACKUP-BINARY] BACKUP-DIR

从备份恢复，运行ibbackup子进程，但是不能连接到数据库。按照BACKUP-DIR/backup-my.cnf定义，使用BACKUP-DIR/ibbackup_logfile恢复InnoDB数据文件和创建新的InnoDB日志文件。

 

innobackupex-1.5.1--copy-back [--defaults-file=MY.CNF] BACKUP-DIR

从备份目录拷贝数据，索引和日志文件到原datadir目录。

 

--defaults-file=[MY.CNF]该选项传递给xtrabackup子进程，从指定文件读取缺省选项

--apply-log 从备份恢复。

--redo-only 该选项强制跳过rollback阶段，只进行redo。这是有必要使用的，如果备份后，要使用增量改变的。

--copy-back 从备份目录拷贝数据和索引文件到datadir目录

--remote-host=HOSTNAME备份到远程主机上，使用ssh

--stream=[tar|cpio(notimplemented)] 指定备份标准输出格式

--tmpdir=DIRECTORY默认与tmpdir相同。使用—remote-host或—stream参数后，传输日志文件将存放在临时目录下

--use-memory=MB选项传递给xtrabackup子进程。恢复使用内存大小

--parallel=NUMBER-OF-THREADS选项传递给xtrabackup子进程，指定数据传输线程总数。默认为1

--throttle=IOS选项传递给xtrabackup子进程，限制IO线程数量

--sleep=MS 选项传递给xtrabackup子进程。每拷贝1MB数据暂停多少MS时间

--compress[=LEVEL]选项传递给xtrabackup子进程。压缩级别在0-9.1快速压缩，9最佳压缩，0不压缩。默认为1.

--include=REGEXP选项传递给xtrabackup子进程。使用正则进行匹配

--databases=LIST指定备份数据库

--tables-file=FILE

--uncompress选项传递给xtrabackup子进程。对压缩过的InnoDB数据文件不进行压缩

--export 仅使用于prepare选项。选项传递给xtrabackup子进程。

--user=NAME

--password=WORD

--host=HOST

--port=PORT

--slave-info 备份复制从服务端，主从信息记录在ibbackup_slave_info文件中

--socket=SOCKET

--no-timestamp不在备份根目录下创建以当前时间戳为名称的新的备份目录

--ibbackup=IBBACKUP-BINARYibbackup二进制路径

--no-lock 禁止表级锁。全部是InnoDB引擎表和不关系二进制日志位置下使用

--scpopt=SCP-OPTIONS指定scp参数

 

4.innobackupex备份

# ./innobackupex-1.5.1 /www/mybak/

在/www/mybak/目录下将创建以时间戳为名称的目录

--stream=tar 将使用到tar4ibd进行压缩。注意：在解压时候必须加上-i参数进行解压。

 

5.恢复

# ./mysqladminshutdown

# rm -rfinnodb

#./innobackupex-1.5.1 --apply-log /www/mybak/2011-04-11_15-28-02/

# ./innobackupex-1.5.1–copy-back /www/mybak/2011-04-11_15-28-02/

# chown –R mysql.mysql/www/mydata

 

6.xtrabackup备份

# ./xtrabackup--defaults-file=/etc/my.cnf --backup --target-dir=/mydata/mybak/

# ls

cacti  ibdata1 nagios  test  xtrabackup_checkpoints  xtrabackup_logfile

 

7.恢复

# ./xtrabackup--defaults-file=/etc/my.cnf --prepare --target-dir=/mydata/mybak/

./xtrabackup  Ver 1.5 Rev undefined for 5.1.53unknown-linux-gnu (x86_64)

xtrabackup: cdto /mydata/mybak/

xtrabackup:This target seems to be not prepared yet.

xtrabackup:xtrabackup_logfile detected: size=2097152, start_lsn=(732446480)

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: TheInnoDB memory heap is disabled

InnoDB:Mutexes and rw_locks use GCC atomic builtins

InnoDB:Compressed tables use zlib 1.2.3

InnoDB:Warning: innodb_file_io_threads is deprecated. Please useinnodb_read_io_threads and innodb_write_io_threads instead

11041116:49:25  InnoDB: highest supported fileformat is Barracuda.

InnoDB: Logscan progressed past the checkpoint lsn 732446480

11041116:49:25  InnoDB: Database was not shutdown normally!

InnoDB:Starting crash recovery.

InnoDB:Reading tablespace information from the .ibd files...

InnoDB: Doingrecovery: scanned up to log sequence number 733504186 (56 %)

11041116:49:25  InnoDB: Starting an apply batchof log records to the database...

InnoDB:Progress in percents: 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 3132 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 5758 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 8384 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 

InnoDB: Applybatch completed

InnoDB: LastMySQL binlog file position 0 560768957, file name ./mysql-bin.000001

11041116:49:25 Percona XtraDB (http://www.percona.com) 1.0.13-12.4 started; logsequence number 733504186

 

[notice(again)]

  If you use binary log and don't use any hackof group commit,

  the binary log position seems to be:

InnoDB: LastMySQL binlog file position 0 560768957, file name ./mysql-bin.000001

 

xtrabackup:starting shutdown with innodb_fast_shutdown = 1

11041116:49:32  InnoDB: Starting shutdown...

11041116:49:33  InnoDB: Shutdown completed; logsequence number 733553275

# ls

cacti  ibdata1 nagios  test  xtrabackup_binlog_pos_innodb  xtrabackup_checkpoints  xtrabackup_logfile

# ./xtrabackup--defaults-file=/etc/my.cnf --prepare --target-dir=/mydata/mybak/

./xtrabackup  Ver 1.5 Rev undefined for 5.1.53unknown-linux-gnu (x86_64)

xtrabackup: cdto /mydata/mybak/

xtrabackup:This target seems to be already prepared.

xtrabackup:notice: xtrabackup_logfile was already used to '--prepare'.

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 = 3

xtrabackup:   innodb_log_file_size = 268435456

xtrabackup:Starting InnoDB instance for recovery.

xtrabackup:Using 104857600 bytes for buffer pool (set by --use-memory parameter)

InnoDB: TheInnoDB memory heap is disabled

InnoDB:Mutexes and rw_locks use GCC atomic builtins

InnoDB:Compressed tables use zlib 1.2.3

InnoDB:Warning: innodb_file_io_threads is deprecated. Please useinnodb_read_io_threads and innodb_write_io_threads instead

11041116:49:58  InnoDB: Log file ./ib_logfile0did not exist: new to be created

InnoDB:Setting log file ./ib_logfile0 size to 256 MB

InnoDB:Database physically writes the file full: wait...

InnoDB:Progress in MB: 100 200

11041116:50:03  InnoDB: Log file ./ib_logfile1did not exist: new to be created

InnoDB:Setting log file ./ib_logfile1 size to 256 MB

InnoDB:Database physically writes the file full: wait...

InnoDB:Progress in MB: 100 200

11041116:50:09  InnoDB: Log file ./ib_logfile2did not exist: new to be created

InnoDB:Setting log file ./ib_logfile2 size to 256 MB

InnoDB:Database physically writes the file full: wait...

InnoDB:Progress in MB: 100 200

11041116:50:14  InnoDB: highest supported fileformat is Barracuda.

InnoDB: Thelog sequence number in ibdata files does not match

InnoDB: thelog sequence number in the ib_logfiles!

110411 16:50:14  InnoDB: Database was not shut down normally!

InnoDB:Starting crash recovery.

InnoDB:Reading tablespace information from the .ibd files...

InnoDB: LastMySQL binlog file position 0 560768957, file name ./mysql-bin.000001

11041116:50:14 Percona XtraDB (http://www.percona.com) 1.0.13-12.4 started; logsequence number 733553676

[notice(again)]

  If you use binary log and don't use any hackof group commit,

  the binary log position seems to be:

InnoDB: LastMySQL binlog file position 0 560768957, file name ./mysql-bin.000001

xtrabackup:starting shutdown with innodb_fast_shutdown = 1

11041116:50:16  InnoDB: Starting shutdown...

11041116:50:16  InnoDB: Shutdown completed; logsequence number 733553676

# ls

cacti    ib_logfile0 ib_logfile2  test                         xtrabackup_checkpoints

ibdata1  ib_logfile1 nagios      xtrabackup_binlog_pos_innodb xtrabackup_logfile

 

此时InnoDB的全部数据文件已经恢复了。将这些文件拷贝到datadir目录下。

注意：xtrabackup只是备份数据文件，不会备份数据表结构。因此恢复时，必须有对应的表结构文件。

 

# cp -r cacti/mydata/data/

# cp -r ib*/mydata/data/

# cp -r nagios/mydata/data/

# chown –R mysql.mysql/mydata/data

 

#/usr/local/mysql-5.5.11/bin/mysqld --user=mysql &

 

8.增量备份

 a.全量备份

# ./xtrabackup --backup--target-dir=/mydata/mybak/base

xtrabackup: The latest check point (forincremental): '783599510'

>> log scanned up to (783977887)

xtrabackup: Stopping log copying thread.

xtrabackup: Transaction log of lsn (783374191) to (783977887) wascopied.

 

# ls

cacti  ibdata1  nagios xtrabackup_checkpoints xtrabackup_logfile

 

# cat xtrabackup_checkpoints 

backup_type = full-backuped

from_lsn = 0

to_lsn = 783599510

last_lsn = 783977887

 

b.增量备份

# ./xtrabackup --backup --target-dir=/mydata/mybak/delta--incremental-basedir=/mydata/mybak/base

incremental backup from 783599510 is enabled.

……

xtrabackup: The latest check point (for incremental): '793114541'

>> log scanned up to (795499255)

xtrabackup: Stopping log copying thread.

xtrabackup: Transaction log of lsn (793069999) to (795499255) wascopied.

 

# ls /mydata/mybak/delta/

cacti  ibdata1.delta  nagios xtrabackup_checkpoints xtrabackup_logfile

 

# cat /mydata/mybak/delta/xtrabackup_checkpoints 

backup_type = incremental

from_lsn = 783599510

to_lsn = 793114541

last_lsn = 795499255

 

在增量备份目录下，数据文件都是以.delta结尾的。增量备份只备份上一次全量备份之后被修改过的page。

 

C.恢复过程：需要分别对全量和增量备份进行恢复操作

# ./xtrabackup --prepare --target-dir=/mydata/mybak/base

# ./xtrabackup --prepare --target-dir=/mydata/mybak/base--incremental-dir=/mydata/mybak/delta

上述过程，首先将全部文件备份到/mydata/mybak/base目录下，增量备份产生的文件备份到/mydata/mybak/delta目录下。在恢复过程中，首先指定全量备份的路径，然后将增量备份应用于该全量备份。

将/mydata/mybak/base目录下的文件拷贝到datadir目录下，即可。同时还需要数据表结构文件。