xtrabackup备份和恢复MySQL

xuke123

　　xtrabackup备份和恢复MySQL
　　xtrabackup有两个主要的工具：innobackupex和xtrabackup，xtrabackup只能备份InnoDB和XtraDB数据表，innobackupex封装了xtrabackup，可以备份MyISAM数据表。
　　MySQL数据库本身提供的工具并不支持真正的增量备份，二进制日志恢复是point-in-time(时间点)的恢复而不是增量备份。Xtrabackup工具支持对InnoDB存储引擎的增量备份，工作原理如下：
　　1.首先完成一个完全备份，并记录下此时检查点的LSN(Log Sequence 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 zxvf xtrabackup-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(not implemented)] 指定备份标准输出格式
　　--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-BINARY ibbackup二进制路径
　　--no-lock 禁止表级锁。全部是InnoDB引擎表和不关系二进制日志位置下使用
　　--scpopt=SCP-OPTIONS 指定scp参数
　　4.innobackupex备份
　　# ./innobackupex-1.5.1  /www/mybak/
　　在/www/mybak/目录下将创建以时间戳为名称的目录
　　--stream=tar 将使用到tar4ibd进行压缩。注意：在解压时候必须加上-i参数进行解压。
　　5.恢复
　　# ./mysqladmin shutdown
　　# rm -rf innodb
　　# ./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.53 unknown-linux-gnu (x86_64)
　　xtrabackup: cd to /mydata/mybak/
　　xtrabackup: This target seems to be not prepared yet.

　　xtrabackup: xtrabackup_logfile detected:>　　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
　　InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
　　110411 16:49:25  InnoDB: highest supported file format is Barracuda.
　　InnoDB: Log scan progressed past the checkpoint lsn 732446480
　　110411 16:49:25  InnoDB: Database was not shut down normally!
　　InnoDB: Starting crash recovery.
　　InnoDB: Reading tablespace information from the .ibd files...
　　InnoDB: Doing recovery: scanned up to log sequence number 733504186 (56 %)
　　110411 16:49:25  InnoDB: Starting an apply batch of 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 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
　　InnoDB: Apply batch completed
　　InnoDB: Last MySQL binlog file position 0 560768957, file name ./mysql-bin.000001
　　110411 16:49:25 Percona XtraDB (http://www.percona.com) 1.0.13-12.4 started; log sequence number 733504186
　　[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 560768957, file name ./mysql-bin.000001
　　xtrabackup: starting shutdown with innodb_fast_shutdown = 1
　　110411 16:49:32  InnoDB: Starting shutdown...
　　110411 16:49:33  InnoDB: Shutdown completed; log sequence 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.53 unknown-linux-gnu (x86_64)
　　xtrabackup: cd to /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: The InnoDB 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 use innodb_read_io_threads and innodb_write_io_threads instead
　　110411 16:49:58  InnoDB: Log file ./ib_logfile0 did not exist: new to be created

　　InnoDB: Setting log file ./ib_logfile0>　　InnoDB: Database physically writes the file full: wait...
　　InnoDB: Progress in MB: 100 200
　　110411 16:50:03  InnoDB: Log file ./ib_logfile1 did not exist: new to be created

　　InnoDB: Setting log file ./ib_logfile1>　　InnoDB: Database physically writes the file full: wait...
　　InnoDB: Progress in MB: 100 200
　　110411 16:50:09  InnoDB: Log file ./ib_logfile2 did not exist: new to be created

　　InnoDB: Setting log file ./ib_logfile2>　　InnoDB: Database physically writes the file full: wait...
　　InnoDB: Progress in MB: 100 200
　　110411 16:50:14  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!
　　110411 16:50:14  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 560768957, file name ./mysql-bin.000001
　　110411 16:50:14 Percona XtraDB (http://www.percona.com) 1.0.13-12.4 started; log sequence number 733553676
　　[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 560768957, file name ./mysql-bin.000001
　　xtrabackup: starting shutdown with innodb_fast_shutdown = 1
　　110411 16:50:16  InnoDB: Starting shutdown...
　　110411 16:50:16  InnoDB: Shutdown completed; log sequence 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 (for incremental): '783599510'
　　>> log scanned up to (783977887)
　　xtrabackup: Stopping log copying thread.
　　xtrabackup: Transaction log of lsn (783374191) to (783977887) was copied.
　　# 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) was copied.
　　# 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目录下，即可。同时还需要数据表结构文件。