PerconaXtraBackup-2.2.10使用手册（三）操作指南-CSDN博客

Innobackupex脚本
innobackupex脚本工具是由Perl脚本语言实现对xtrabackup的C程序封装，它是一个InnoDB Hot Backup tool补丁版本。
集成了xtrabackup和一些其他功能比如文件拷贝，流式操作数据，也改进了很多地方使功能更加的方便使用。
它可以使用在对InnoDB / XtraDB表进行时间点备份的同时备份definitions, MyISAM tables,and other portions of the server.

Prerequisites 使用先决条件
Connection and Privileges Needed
Percona XtraBackup首先要可以连上数据库并有操作权限，而且datadir字段必须要配置了的因为在有的脚本里会用到。
不管是xtrabackup 和 innobackupex，在执行时都会有两个用户：系统用户和数据库用户，即时他们的名字一样的。
在链接数据库时必须指出密码：--user和--password
$ innobackupex --user=DBUSER --password=SECRET /path/to/backup/dir/
$ innobackupex --user=LUKE --password=US3TH3F0RC3 --stream=tar ./ | bzip2 -
$ xtrabackup --user=DVADER --password=14MY0URF4TH3R --backup --target-dir=/data/bkps/
如果你不使用--user那么脚本会自动用当前系统用户作为数据库用户执行
还有其他的一些链接数据库的选项
--port,--socket,--host。

Permissions and Privileges Needed
一旦链接上服务器，为了能完成备份操作，一定要给备份执行账号在datadir上有读写执行的权限。
数据库账号必须有一下权限：
①RELOAD and LOCK TABLES (unless the --no-lock option is specified) in order to FLUSH TABLES WITH
READ LOCK and FLUSH ENGINE LOGS prior to start copying the files, and LOCK TABLES FOR BACKUP
and LOCK BINLOG FOR BACKUP require this privilege when Backup Locks are used,
②REPLICATION CLIENT in order to obtain the binary log position,
③CREATE TABLESPACE in order to import tables (see Restoring Individual Tables),
④PROCESS in order to see all threads which are running on the server (see Improved FLUSH TABLES WITH
READ LOCK handling),
⑤SUPER in order to start/stop the slave threads in a replication environment, use XtraDB Changed Page Tracking
for Incremental Backups and for Improved FLUSH TABLES WITH READ LOCK handling,
⑥CREATE privilege in order to create the PERCONA_SCHEMA.xtrabackup_history database and table,
⑦INSERT privilege in order to add history records to the PERCONA_SCHEMA.xtrabackup_history table,
⑧SELECT privilege in order to use innobackupex --incremental-history-name or
innobackupex --incremental-history-uuid in order for the feature to look up the
innodb_to_lsn values in the PERCONA_SCHEMA.xtrabackup_history table.
下面指出一个要执行全备说需要的最小权限：
mysql> CREATE USER ’bkpuser’@’localhost’ IDENTIFIED BY ’s3cret’;
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO ’bkpuser’@’localhost’;
mysql> FLUSH PRIVILEGES;

The Backup Cycle - Full Backups (全备备份过程)
使用innobackupex实现全备
innobackupex是提供能备份MySQL整个实例的功能的，使用xtrabackup并且结合了其他工具像xbstream和xbcrypt。
要创建一个完整的周期备份，脚本里面必须指出备份存储的目录。
$ innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/
这样备份的话会生成一级时间点的目录，如果不需要则加上
--no-timestamp
不过此时一般会采用/path/to/BACKUP-DIR/$(date +%Y%m%d)/ 一个日期作为一级目录作为数据备份时间点区分，这样就变成一天一个备份了。
--defaults-file
指定MySQL配置文件位置
更多参数innobackupex --help|more

Preparing a Full Backup with innobackupex(预备一个可以作为恢复的完全备份)
在一个备份完成后，这个备份数据并不能直接用来恢复，因为里面可能还包含了未提交的事务或者要回滚的要按照日志在数据库重演。
完成了这个过程才能保证数据的一致性，这个时候这个数据才能作为一个备份用来恢复数据库。
准备过程你需要用到
$ innobackupex --apply-log /path/to/BACKUP-DIR
执行最后输出语句
111225 1:01:57 InnoDB: Shutdown completed; log sequence number 1609228
111225 01:01:57 innobackupex: completed OK!
那么就表示成功了，这个备份我们就可以使用了。
其他可选项
--use-memory
准备数据这个过程在使用内存越多的时候能速度越快，这个依赖你系统的可能RAM，通常越多的内存在该过程那么这个速度会快一些。
$ innobackupex --apply-log --use-memory=4G /path/to/BACKUP-DIR

Restoring a Full Backup with innobackupex(全备恢复数据库)
为了操作方便，innobackupex指定了一个--copy-back作为恢复数据库的选项，后接准备好的完整备份。
$ innobackupex --copy-back /path/to/BACKUP-DIR
该命令会把整个数据拷贝到数据库读取的my.cnf里指定的datadir，检查最后一行判断是否恢复成功：
innobackupex: Finished copying back files.
111225 01:08:13 innobackupex: completed OK!
特别提示：
The datadir must be empty
数据库指定datadir目录必须为空，Percona XtraBackup innobackupex --copy-back 并不会覆盖文件，
除非你使用innobackupex --force-non-empty-directories
还有另一点，恢复操作的时候数据库一定是被关闭的(service mysql stop)，你不能恢复数据库在一个运行的实例上(当然部分备份的导入除外)。

Incremental Backups with innobackupex(使用innobackupex实现增量备份)
随着两个备份直接的差异并不是很大，增量备份的出现可以减少磁盘空间的占用，也可以作为一个不间断备份的手段。
增量备份是可以实现在每一个有日志序列号的InnoDB页，这个日志号是整个数据库的一个版本号，任何一个更新，这个号都是自增。

在创建增量备份的时候，首先你需要有一个全备数据作为增量基础数据：
$ innobackupex /data/backups
如果你查看备份目录下的xtrabackup-checkpoints文件
[root@localhost 20150527]# cat xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 1595926
last_lsn = 1595926
compact = 0
我们把第一个备份的目录叫做INCREMENTAL-DIR-1。

至于接下来的增量备份就是相似的，但是每一个备份都是基于上一个时间点的。
$ innobackupex --incremental /data/backups --incremental-basedir=INCREMENTAL-DIR-1
[root@localhost 2015-05-28_16-25-12]# cat xtrabackup_checkpoints
backup_type = incremental
from_lsn = 1595926
to_lsn = 1596247
last_lsn = 1596247
compact = 0
刚刚我在测试表插入了一个数据后这个编号就+1了，这样就完成了增量备份的目的。

开始我们说了这个增量备份是基于InnoDB的日志号的，那么这里也提供了另一种备份的方法，基于日志号：
$ innobackupex --incremental /data/backups --incremental-lsn=1595926
特别提示：整个增量过程的备份都是基于XtraDB or InnoDB-based tables，其他表的增量是不可能实现的，所以在innobackupex整理备的时候非InnoDB/XtraDB表都是直接复制全备。

Preparing an Incremental Backup with innobackupex(预备一个可以作为恢复的增量备份)
增量备份的准备数据和完备有点点差别，原因自己想想也知道。
增量备份准备数据：
在完备上：
$ innobackupex --apply-log --redo-only BASE-DIR
在增量上：
$ innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1
$ innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-2
但是最后一个备份不需要--redo-only
$ innobackupex --apply-log BASE-DIR --incremental-dir=INCREMENTAL-DIR-last
以为加上后，服务器虽然还是会保证数据一直性，但是可能会导致最后的数据恢复后还会回滚。
增备上执行的这个命令具体操作：
把所有非InnoDB/XtraDB表最新的版本复制到完整备份，然后InnoDB/XtraDB表更新操作日志

在执行增量准备过程中一定要按照顺序执行，否则恢复的数据也是无用的，如果你不确定你执行到哪儿了，可以查看xtrabackup_checkpoints再选择下一个增量的起始位置是多少。
当所有日志都跑完了后，现在我们要执行：
$ innobackupex --apply-log BASE-DIR
回滚所有未提交的事务。
然后就回到了Restoring a Full Backup with innobackupex(全备恢复数据库)这个过程了:
$ innobackupex --copy-back BASE-DIR

Partial Backups(部分备份)
percona xtrabackup支持部分备份，也就是说我们可以备份单表或单库。
但是备份的数据必须都在独立的表空间里面，这样的话我们就要开启服务器上的nnodb_file_per_table参数。
部分备份有3个选项可以使用：
--include:设置正则表达式的格式，匹配的就备份
--table-file:在文件中指定要备份的表，然后通过这个选项传入文件
--database:指定数据库列表
使用include方式
$ innobackupex --include=’^mydatabase[.]mytable’ /path/to/backup
这个选项是传给xtrabackup –tables，所有的数据库目录都会被创建，但是里面可能是空的。
使用tables-file方式
$ echo "mydatabase.mytable" > /tmp/tables.txt
$ innobackupex --tables-file=/tmp/tables.txt /path/to/backup
这个选项是应用xtrabackup –tablefile，只有匹配到表的数据库目录才会被创建
使用database方式
innobackupex可以传递用空格隔开的数组，格式为：databasename[.tablename]
$ innobackupex --databases="mydatabase.mytable mysql" /path/to/backup
注意：--databasees选项只会对非innodb引擎表和frm文件产生影响，对于innodb数据文件总是备份的

预备部分备份
$ innobackupex --apply-log –export /path/to/backup
恢复部分备份(见后面恢复单表方法Restoring Individual Tables)

Compact Backups(紧凑备份、窄备份)
在备份InnoDB表过程中不备份索引，这样会减少很大空间，但是这样的缺点就是要花很久的时间来重建索引。
For example full backup taken without and with the --compact option:
#backup size without --compact
2.0G 2013-02-01_10-18-38
#backup size taken with --compact option
1.4G 2013-02-01_10-29-48

特别提示：紧凑备份不支持系统自带的表空间，所以为了正确的完成紧凑备份，我们建议把innodb-file-per-table 启用，但是好像不起用也没遇见什么问题。
Creating Compact Backups
$ innobackupex --compact /data/backups
这样都会在/data/backups目录下还产生一个时间戳目录，如果你不需要就加上--no-timestamp参数
可以在备份目录下查看xtrabackup_checkpoints文件：
[root@localhost 2015-05-29_14-30-15]# cat xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 1596247
last_lsn = 1596247
compact = 1

Preparing Compact Backups
预备一个紧凑备份，我们需要加一个--rebuild-indexes 和--apply-logs 配合使用
$ innobackupex --apply-log --rebuild-indexes /data/backups/2015-05-29_14-30-15
注意：为了重建速度，可以使用并发创建索引，使用参数—rebuild-threads指定并发数。

Restoring Compact Backups
$ innobackupex --copy-back /path/to/BACKUP-DIR

Encrypted Backups(加密备份)
Percona XtraBackup自2.1起的版本使用libgcrypt library 实现了本机的加密解密备份，流备份现在支持xbstream而tar流还不支持。
Creating Encrypted Backups
为了实现备份的加密，我们需要交互使用--encrypt-key 和 --encrypt-key-file
--encryption =ALGORITHM 目前支持的加密算法有AES128, AES192 和 AES256
--encrypt-key =ENCRYPTION_KEY 作为的加密的问价必须是2进制文件或者txt
$ innobackupex --encrypt=AES256 --encrypt-key="GCHFLrDFVx6UAsRb88uLVbAVWbK+Yzfs" /data/backups
$ innobackupex --encrypt=AES256 --encrypt-key-file=/data/backups/keyfile /data/backups
解密
$ innobackupex --decrypt=AES256 --encrypt-key="GCHFLrDFVx6UAsRb88uLVbAVWbK+Yzfs" /data/backups/时间戳
innobackupex –decrypt使用这个解密会把原文件删除，留下解压好的文件放在相同的目录下面。
解密后的预备备份和恢复与上面的方法一致。

高级特性：Streaming and Compressing Backups(流式压缩备份) 和 Incremental Streaming Backups using xbstream and tar(流式压缩增量备份)
$ innobackupex --user=root -password=xxx --stream=xbstream --compress /tmp | ssh root@192.168.74.129 "xbstream -x -C /home/bak"
顺便在这里把压缩备份一起写上
①基于tar格式备份
本地：
$ innobackupex --stream=tar /tmp >/backup/bak.tar 非压缩方式备份
$ innobackupex --stream=tar /tmp |gzip >/backup/bakz.tar.gz 压缩方式备份
$ innobackupex --stream=tar ./ | gzip - > backup.tar.gz
$ innobackupex --stream=tar ./ | bzip2 - > backup.tar.bz2
解压方法：tar -xivf bak.tar
tar -xizvf bakz.tar.gz
都加上参数i解压innobackupex的备份
远程：
$ innobackupex --stream=tar /tmp | ssh root@192.168.74.129 / "cat - > /backup/bak.tar" 非压缩方式备份
$ innobackupex --stream=tar /tmp | ssh root@192.168.74.129 / "gzip >/backup/bak.tar.gz" 压缩方式备份
②基于xbstream格式备份
本地：
$ innobackupex --stream=xbstream /tmp >/backup/bak.xbstream 非压缩方式备份
$ innobackupex --stream=xbstream --compress /tmp >/backup/bak_compress.xbstream 压缩方式备份
输出日志
$ innobackupex --stream=xbstream /tmp 2>>"$backupLog" | gzip > "$backup_file" 2>>"$backupLog"

Taking Backups in Replication Environments(复制环境下的备份)
这个是特别针对主从复制环境中的从库做的备份改进。
slave-info
--slave-info，会打印binary log的位置和master server名，并且以change master的方式写到xtrabackup_slave_info中。
safe-slave-backup
--safe-slave-backup,为了保证复制状态的一致性，这个选项会关闭slave sql线程，等待直到SHOW STATUS 中的Slave_open_temp_tabls为了才启动备份。如果等待时间超过—safe-slave-backup-timeout就会报错默认300秒。备份成功后 slave sql thread会自动启动。

Accelerating the backup process(加速备份进程)
Accelerating with --parallel copy and –compress-threads(使用parallel和compress-threads加速)
当有多个文件时，可以使用使用—parallel加速备份，这个选项会指定xtrabackup备份文件的线程数。
$ innobackupex --parallel=4 /path/to/backup
如果使用xbstream可以考虑通过—compress-threads加速压缩进程，默认为1。
$ innobackupex --stream=xbstream --compress --compress-threads=4 ./ > backup.xbstream

Accelerating with --rsync option(使用rsync加速)
为了加速复制过程，最小化FLUSH TABLES WITH READ LOCK堵塞时间，使用innobackupex –rsync。使用了这个选项所有文件都会在一个cp命令里面，而不是每个文件一个cp。并且innobackupex会调用2次 rsync，一次在执行FLUSH TABLES WITH READ LOCL之前，一次在之后。第二次执行的时候会把第一次之后的修改过的数据。

Throttling backups with innobackupex(节流备份)
尽管innobackupex不会堵塞数据库操作，但是备份终会消耗系统资源。为了减少资源消耗，可以使用—throttle来限制每秒钟读写对次数。
innobackupex --throttle option works only during the backup phase, ie. it will not work with
innobackupex --apply-log and innobackupex --copy-back options。只对备份操作有效。

Restoring Individual Tables(还原独立表)
在5.6以前的服务器版本是不能通过表空间恢复数据的，即使是启用了innodb_file_per_table.
现在Percona XtraBackup能在Percona Server或者MySQL 5.6以上版本能实现还原。这个功能只作用在*.ibd文件，并且不能导入不包含自己的.ibd文件。
$ innobackupex --apply-log --export /path/to/backup
OTHERSERVER|mysql> CREATE TABLE mytable (...) ENGINE=InnoDB;
OTHERSERVER|mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
OTHERSERVER|mysql> ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

Point-In-Time recovery
首先我们有一个完备恢复
然后查看cat /path/to/backup/xtrabackup_binlog_info
获取到File:mysql-bin.000003 Position: 57
再获取一个最新的完备：
$ innobackupex --copy-back /path/to/backup
最新新的完备会把日志拷过来
确认好在上一个完备之后又多少日子写在数据库,获取差异日志导出SQL
$ mysqlbinlog /path/to/datadir/mysql-bin.000003 /path/to/datadir/mysql-bin.000004 /path/to/datadir/mysql-bin.00XXXX\
--start-position=57 > mybinlog.sql
这时你可以指定任何时间点作为数据截止时间，比如我们使用2015-3-25 01:00:00
$ mysqlbinlog /path/to/datadir/mysql-bin.000003 /path/to/datadir/mysql-bin.000004 \
--start-position=57 --stop-datetime="2015-3-25 01:00:00" | mysql -u root –p
这样你就可以时间点恢复数据库了，前提是你得有日志哈，不要过期被自动删除了就悲剧了。

Improved FLUSH TABLES WITH READ LOCK handling(提高对FLUSH TABLES WITH READ LOCK控制)
在备份的时候，为了保证数据一致性，在备份非innodb表的之前会先使用FLUSH TABLES WITH READ LOCK，这个语句在有长时间查询运行的情况下也能执行，但是其他的所有事都会被堵塞，Waiting for table flush或者Waiting for master to send event，这个时候不应该kill FLUSH TABLES WITH READ LOCK，而是应该kill掉那个大的查询。因为当有大的查询的时候，FLUSH TABLES WITH READ LOCK会被卡住。
为了能够避免这种事情发生需要实现2个事情：
1.innobackupex等一个好的时机运行
2.innobackupex可以kiil 所有查询或者只能存在SELECT查询。即kill所有阻止获取全局锁的查询。
等待查询完成
为了避免innobackupex等待FLUSH TABLES WITH READ LOCK执行太长时间，可以使用innobackupex –lock-wait-timeout，可以用来限制等待时间，一旦超时就会报错退出。
另外一个是设置等待查询的类型，innobackupex --lock-wait-query-type 可取的值是all或者update，如果为all那么会等待所有长运行查询完成，如果是update，会等待除select之外的DML完成。
--lock-wait-threshold用来定义 --locl-wait-query-type中的长运行查询，如果超过--lock-wait-threshold都算长运行查询。
Kill堵塞查询
innobackupex可以kill所有阻止获取全局锁的查询。
可以通过指定--kill-long-queries-timeout用来指定执行FLUSH TABLES WITH READ LOCK后还可以执行的时间，0为不kill，--kill-long-query-type用来指定超时之后，kill的查询类型，可以是all或者select。
$ innobackupex --lock-wait-threshold=40 --lock-wait-query-type=all --lock-wait-timeout=180 --kill-long-queries-timeout=20 --kill-long-query-type=all /data/backups/