声明：本文由我的同事@fiona514编写，是我看过的最用心的中文说明介绍，强烈推荐大家学习使用。
Percona Xtrabackup 2.4.1
编译及软件依赖
centos5,6 需要升级cmake至2.8.2版本以上，解决：安装cmake版本3.4.3测试通过
centos5 gcc g++ 需要升级gcc至4.4以上上 ，解决：安装4.4.7测试通过
另外xtrabackcup另外Boost版本需要1.59.0版本或以上，目前centos5,6默认是1.41.0。解决：升级至1.59.0
GTID支持情况
测试5.6,5.7开启GTID下可以正常备份，还原
对MySQL5.5,MySQL5.6版本支持
5.6在开启和关闭gtid模式下都可以正常备份还原
5.5可以正常备份还原
5.6部分表导出还原测试正常
对现有版本结合新特性的建议
目前线上版本大部分在1.6.3和1.5版本。很多需求是通过第三方工具支持。结合2.4.1的新特性和release历史和目前情况，建议几点如下：
* xtrabackup支持非Innodb表备份，并且Innobackupex在下一版本中移除，建议通过xtrabackup替换innobackupex
* 流式备份通过--stream指定格式为xbtream而替代tar,支持streaming格式的并行备份和压缩
* 之前脚本使用第三方压缩工具pbzip2进行压缩。建议通过--compress 和--compress-threads选项进行并行压缩
* 指定--safe-slave-backup，增加备份的一致性。（这个选项停止SQL线程并且等到show status中的slave_open_temp_tables为0的时候开始备份，如果没有打开临时表，bakcup会立刻开始，否则SQL线程启动或者关闭知道没有打开的临时表。如果slave_open_temp_tables在--safe-slave-backup-timeount（默认300秒）秒之后不为0，从库sql线程会在备份完成的时候重启）
* 指定--rsync选项，加速备份过程 (为了加速备份过程，同时减小FLUSH TBALES WITH READ LOCAK阻塞写的时间，当该选项指定时innobackupex使用rsync拷贝所有的非InnoDB文件替换cp。尤其适用于有大量的库和表的时候会更快。innobackup会调用rsync两次。1、执行flush tables with read lock前后 ；2、减少读锁被持有的时间内。因为第一调用在刷新读锁之前，所以它仅仅同步那些非事务的数据的变化)
* 针对紧凑备份和增量备份在虽然某些场景下非常有用，与刘伟商讨过暂时继续先不做计划做到统一版本中去
release历史
2.4.1 支持MySQL5.7(5.7.10)
2.3.2 命令行语法跟随MySQL5.6的变化而变化。另外命令行支持--datadir
2.3.1 innobackupex脚本用c重写，并且只是xtrabackup的符号连接。innobackupex支持2.2版本所有的特性，但是目前已降级在下个Major版本中移除，innobackupex将不支持所有新特性的语法，同时xtrabackup现在支持MyISAM的拷贝并且支持innobakcupex的所有特性。innobackupex先前特性的语法xtrabackup同样支持
2.2.21 支持5.6（基于5.6.24版本）
2.2.8 基于5.6.22 （解决当总redo log超过4G，prepare会失败的问题）
2.2.6 通过show variables读取Mysql选项。在初始化表扫描的时候输出更详细信息
2.2.5 基于5.6.21
2.2.1 移除xtrabackup_56 xtrabakcup_55,只保留xtrabakcup.移除Build脚本，支持cmake编译。基于5.6.16
2.1.6 innobackupex --force-non-empty-directories
2.1.4 MySQL versions 5.1.70, 5.5.30, 5.6.11
innobackupex --no-lock ,拷贝非Innodb数据时不停止复制线程，但是条件是备份期间非事务型表上不能有DDL或者DML操作
innobackupex --decrypt and innobackupex --decompress,
2.1.1 支持紧凑备份，加密备份。不在支持5.0内置Innodb和5.1内置Innoddb。移除--remote-host选项
2.1.0 支持mysql5.6的所有特性（GTID, 可移动表空间，独立undo表空间，5.6样式的buffer pool导出文件）
支持5.6引入的innodb buffer pool预载。buffer pool dumps可以生成或者导入加速启动。在备份时buffer pool dump拷贝到备份目录，在还原阶段拷贝回data目录，
--log-copy-interval 可配置log拷贝线程检查的间隔时间
如果开启gtid，xtrabackup_binlog_info储存gtid的值
支持xtrabackup --export，这个选项生成5.6样式的元数据文件。可以通过alter table import tablespace导入
2.0.5 --defaults-extra-file 存备份用户的用户名和密码的配置文件
2.0.3 支持--move-back
1.9.1 支持压缩备份，之前能能streaming备份之后通过外部工具压缩
支持streaming增量备份
LRU DUMP
1.6.4 innobackupex支持--rsync选项 在datadir目录进行两阶段rsync（首先没有写锁，之后有写锁，）减少写锁持有的时间
感兴趣的可以往后看。。。。。。
————————————————————————————————————————————————————————————————————————————————————————————————————
xtrabackup主要功能测试
innobackupex
创建本地Full Backup(创建，prepare，还原)
之后隐去--defaults-file=/data1/mysql5711/my5711.cnf.bakuse --no-timestamp --slave-info --socket=/tmp/mysql5711.sock --user=mysqlha --password=xxx 等选项
创建一份备份
innobackupex /data1/dbatemp/5711back
160321 10:56:00 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackupex
prints "completed OK!".
160321 10:56:00 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;port=5711;mysql_socket=/tmp/mysql5711.sock' as 'mysqlha' (using password: YES).
160321 10:56:00 version_check Connected to MySQL server
160321 10:56:00 version_check Executing a version check against the server...
160321 10:56:00 version_check Done.
160321 10:56:00 Connecting to MySQL server host: localhost, user: mysqlha, password: set, port: 5711, socket: /tmp/mysql5711.sock
Using server version 5.7.11-log
/usr/local/xtrabackup/bin/innobackupex version 2.4.1 based on MySQL server 5.7.10 Linux (x86_64) (revision id: a2dc9d4)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /data1/mysql5711
xtrabackup: open files limit requested 0, set to 204800
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 1363148800
xtrabackup: using O_DIRECT
InnoDB: Number of pools: 1
160321 10:56:01 >> log scanned up to (4151116)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 30 for slow_query_log/global_query_review_history, old maximum was 0
160321 10:56:01 [01] Copying ./ibdata1 to /data1/dbatemp/5711back/ibdata1
160321 10:56:02 >> log scanned up to (4151116)
160321 10:56:02 [01] ...done
160321 10:56:02 [01] Copying ./slow_query_log/global_query_review_history.ibd to /data1/dbatemp/5711back/slow_query_log/global_query_review_history.ibd
160321 10:56:02 [01] ...done
160321 10:56:02 [01] Copying ./slow_query_log/global_query_review.ibd to /data1/dbatemp/5711back/slow_query_log/global_query_review.ibd
160321 10:56:02 [01] ...done
160321 10:56:02 [01] Copying ./abc/object_info.ibd to /data1/dbatemp/5711back/abc/object_info.ibd
160321 10:56:02 [01] ...done
160321 10:56:02 [01] Copying ./mysql/time_zone_transition.ibd to /data1/dbatemp/5711back/mysql/time_zone_transition.ibd
160321 10:56:02 [01] ...done
160321 10:56:02 [01] Copying ./mysql/time_zone_name.ibd to /data1/dbatemp/5711back/mysql/time_zone_name.ibd
160321 10:56:02 [01] ...done
160321 10:56:02 [01] Copying ./mysql/slave_worker_info.ibd to /data1/dbatemp/5711back/mysql/slave_worker_info.ibd
160321 10:56:02 [01] ...done
160321 10:56:03 >> log scanned up to (4151116)
160321 10:56:03 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
160321 10:56:03 Executing FLUSH TABLES WITH READ LOCK...
160321 10:56:03 Starting to backup non-InnoDB tables and files
160321 10:56:03 [01] Copying ./slow_query_log/db.opt to /data1/dbatemp/5711back/slow_query_log/db.opt
160321 10:56:03 [01] ...done
160321 10:56:03 [01] Copying ./slow_query_log/global_query_review_history.frm to /data1/dbatemp/5711back/slow_query_log/global_query_review_history.frm
160321 10:56:03 [01] ...done
160321 10:56:04 [01] Copying ./mysql/proc.MYI to /data1/dbatemp/5711back/mysql/proc.MYI
160321 10:56:04 [01] ...done
160321 10:56:04 >> log scanned up to (4151116)
160321 10:56:04 [01] Copying ./mysql/time_zone_transition_type.frm to /data1/dbatemp/5711back/mysql/time_zone_transition_type.frm
160321 10:56:04 [01] ...done
160321 10:56:04 [01] Copying ./mysql/func.MYD to /data1/dbatemp/5711back/mysql/func.MYD
160321 10:56:06 [01] ...done
160321 10:56:06 >> log scanned up to (4151116)
160321 10:56:06 [01] Copying ./sys/schema_auto_increment_columns.frm to /data1/dbatemp/5711back/sys/schema_auto_increment_columns.frm
160321 10:56:07 [01] ...done
160321 10:56:07 >> log scanned up to (4151116)
160321 10:56:07 [01] Copying ./sys/sys_config_update_set_user.TRN to /data1/dbatemp/5711back/sys/sys_config_update_set_user.TRN
160321 10:56:07 [01] ...done
160321 10:56:07 Finished backing up non-InnoDB tables and files
160321 10:56:07 [00] Writing xtrabackup_slave_info
160321 10:56:07 [00] ...done
160321 10:56:07 [00] Writing xtrabackup_binlog_info
160321 10:56:07 [00] ...done
160321 10:56:07 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '4151107'
xtrabackup: Stopping log copying thread.
.160321 10:56:07 >> log scanned up to (4151116)
160321 10:56:07 Executing UNLOCK TABLES
160321 10:56:07 All tables unlocked
160321 10:56:07 [00] Copying ib_buffer_pool to /data1/dbatemp/5711back/ib_buffer_pool
160321 10:56:07 [00] ...done
160321 10:56:07 Backup created in directory '/data1/dbatemp/5711back'
MySQL binlog position: filename 'mysql-bin.000002', position '154'
MySQL slave binlog position: master host '10.75.22.67', filename 'mysql-bin.000007', position '154
160321 10:56:07 [00] Writing backup-my.cnf
160321 10:56:07 [00] ...done
160321 10:56:07 [00] Writing xtrabackup_info
160321 10:56:07 [00] ...done
xtrabackup: Transaction log of lsn (4151107) to (4151116) was copied.
160321 10:56:07 completed OK!
prepare
innobackupex --apply-log /data1/dbatemp/5711back
```
160321 11:04:16 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex
prints “completed OK!”.
/usr/local/xtrabackup/bin/innobackupex version 2.4.1 based on MySQL server 5.7.10 Linux (x86_64) (revision id: a2dc9d4)
xtrabackup: cd to /data1/dbatemp/5711back
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(4151107)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 8388608
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 8388608
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support not available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 4151107
InnoDB: Doing recovery: scanned up to log sequence number 4151116 (0%)
InnoDB: Doing recovery: scanned up to log sequence number 4151116 (0%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: xtrabackup: Last MySQL binlog file position 179018, file name mysql-bin.000001
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: 5.7.10 started; log sequence number 4151116
InnoDB: not started
InnoDB: xtrabackup: Last MySQL binlog file position 179018, file name mysql-bin.000001
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 4151291
InnoDB: Number of pools: 1
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 1363148800
InnoDB: PUNCH HOLE support not available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Setting log file ./ib_logfile101 size to 1300 MB
InnoDB: Progress in MB:
100 200 300 400 500 600 700 800 900 1000 1100 1200 1300
InnoDB: Setting log file ./ib_logfile1 size to 1300 MB
InnoDB: Progress in MB:
100 200 300 400 500 600 700 800 900 1000 1100 1200 1300
InnoDB: Setting log file ./ib_logfile2 size to 1300 MB
InnoDB: Progress in MB:
100 200 300 400 500 600 700 800 900 1000 1100 1200 1300
InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
InnoDB: New log files created, LSN=4151291
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 4151308
InnoDB: Doing recovery: scanned up to log sequence number 4151317 (0%)
InnoDB: Doing recovery: scanned up to log sequence number 4151317 (0%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: xtrabackup: Last MySQL binlog file position 179018, file name mysql-bin.000001
InnoDB: Removed temporary tablespace data file: “ibtmp1”
InnoDB: Creating shared tablespace for temporary tables
InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
InnoDB: File './ibtmp1' size is now 12 MB.
InnoDB: 96 redo rollback segment(s) found. 1 redo rollback segment(s) are active.
InnoDB: 32 non-redo rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: page_cleaner: 1000ms intended loop took 13284ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
InnoDB: 5.7.10 started; log sequence number 4151317
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 4151336
160321 11:04:32 completed OK!
### 还原全备:
innobackupex --defaults-file=/data1/mysql5711_bak/my5711.cnf.bakuse --copy-back /data1/dbatemp/5711back/
/usr/local/xtrabackup/bin/innobackupex version 2.4.1 based on MySQL server 5.7.10 Linux (x86_64) (revision id: a2dc9d4)
160321 11:29:27 [01] Copying ib_logfile0 to /data1/mysql5711/ib_logfile0
160321 11:29:31 [01] ...done
160321 11:29:31 [01] Copying ib_logfile1 to /data1/mysql5711/ib_logfile1
160321 11:29:34 [01] ...done
160321 11:29:34 [01] Copying ib_logfile2 to /data1/mysql5711/ib_logfile2
160321 11:29:37 [01] ...done
160321 11:29:38 [01] Copying ibdata1 to /data1/mysql5711/ibdata1
160321 11:29:38 [01] ...done
160321 11:29:38 [01] Copying ./xtrabackup_info to /data1/mysql5711/xtrabackup_info
160321 11:29:38 [01] ...done
160321 11:29:38 [01] Copying ./slow_query_log/global_query_review_history.ibd to /data1/mysql5711/slow_query_log/global_query_review_history.ibd
160321 11:29:38 [01] ...done
160321 11:29:38 [01] Copying ./slow_query_log/db.opt to /data1/mysql5711/slow_query_log/db.opt
160321 11:29:38 [01] ...done
160321 11:29:38 [01] Copying ./slow_query_log/global_query_review.ibd to /data1/mysql5711/slow_query_log/global_query_review.ibd
160321 11:29:38 [01] ...done
160321 11:29:38 [01] Copying ./slow_query_log/global_query_review_history.frm to /data1/mysql5711/slow_query_log/global_query_review_history.frm
160321 11:29:38 [01] ...done
160321 11:29:38 [01] Copying ./slow_query_log/global_query_review.frm to /data1/mysql5711/slow_query_log/global_query_review.frm
160321 11:29:38 [01] ...done
160321 11:29:38 [01] Copying ./abc/weibo_asset_info.frm to /data1/mysql5711/abc/weibo_asset_info.frm
160321 11:29:38 [01] ...done
160321 11:29:38 [01] Copying ./abc/object_info.ibd to /data1/mysql5711/abc/object_info.ibd
160321 11:29:39 [01] ...done
160321 11:29:39 [01] Copying ./mysql/user.frm to /data1/mysql5711/mysql/user.frm
......
......
160321 11:29:42 [01] ...done
160321 11:29:42 [01] Copying ./xtrabackup_slave_info to /data1/mysql5711/xtrabackup_slave_info
160321 11:29:42 [01] ...done
160321 11:29:42 [01] Copying ./ib_buffer_pool to /data1/mysql5711/ib_buffer_pool
160321 11:29:42 [01] ...done
160321 11:29:42 completed OK!
## stream bakcup
innobackupex --stream=tar ./ |gzip - > backup.tar.gz
innobackupex --compress --compress-threads=8 --stream=xbstream --parallel=4 ./ > backup.xbstream
## 增量备份
### base backup:
innobackupex /data1/dbatemp/
### 基于base bakcup的增量备份:
innobackupex --incremental /data/dbatemp --incremental-basedir=/data1/dbatemp/2016-03-21_12-02-03
160321 12:02:03 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;port=5711;mysql_socket=/tmp/mysql5711.sock' as 'mysqlha' (using password: YES).
160321 12:02:03 version_check Connected to MySQL server
160321 12:02:03 version_check Executing a version check against the server...
160321 12:02:03 version_check Done.
160321 12:02:03 Connecting to MySQL server host: localhost, user: mysqlha, password: set, port: 5711, socket: /tmp/mysql5711.sock
Using server version 5.7.11-log
/usr/local/xtrabackup/bin/innobackupex version 2.4.1 based on MySQL server 5.7.10 Linux (x86_64) (revision id: a2dc9d4)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /data1/mysql5711
xtrabackup: open files limit requested 0, set to 204800
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 1363148800
xtrabackup: using O_DIRECT
InnoDB: Number of pools: 1
160321 12:02:03 >> log scanned up to (4151364)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 30 for slow_query_log/global_query_review_history, old maximum was 0
160321 12:02:04 [01] Copying ./ibdata1 to /data1/dbatemp/2016-03-21_12-02-03/ibdata1
160321 12:02:04 >> log scanned up to (4151364)
160321 12:02:04 [01] ...done
160321 12:02:04 [01] Copying ./slow_query_log/global_query_review_history.ibd to /data1/dbatemp/2016-03-21_12-02-03/slow_query_log/global_query_review_history.ibd
160321 12:02:04 [01] ...done
160321 12:02:04 [01] Copying ./slow_query_log/global_query_review.ibd to /data1/dbatemp/2016-03-21_12-02-03/slow_query_log/global_query_review.ibd
160321 12:02:05 [01] Copying ./sys/sys_config.ibd to /data1/dbatemp/2016-03-21_12-02-03/sys/sys_config.ibd
160321 12:02:05 [01] ...done
160321 12:02:05 >> log scanned up to (4151364)
160321 12:02:06 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
160321 12:02:06 Executing FLUSH TABLES WITH READ LOCK...
160321 12:02:06 Starting to backup non-InnoDB tables and files
160321 12:02:06 [01] Copying ./slow_query_log/db.opt to /data1/dbatemp/2016-03-21_12-02-03/slow_query_log/db.opt
160321 12:02:06 [01] ...done
160321 12:02:06 [01] Copying ./slow_query_log/global_query_review_history.frm to /data1/dbatemp/2016-03-21_12-02-03/slow_query_log/global_query_review_history.frm
160321 12:02:10 Finished backing up non-InnoDB tables and files
Failed to get master binlog coordinates from SHOW SLAVE STATUS
This means that the server is not a replication slave. Ignoring the --slave-info option
160321 12:02:10 [00] Writing xtrabackup_binlog_info
160321 12:02:10 [00] ...done
160321 12:02:10 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '4151355'
xtrabackup: Stopping log copying thread.
.160321 12:02:10 >> log scanned up to (4151364)
160321 12:02:10 Executing UNLOCK TABLES
160321 12:02:10 All tables unlocked
160321 12:02:10 [00] Copying ib_buffer_pool to /data1/dbatemp/2016-03-21_12-02-03/ib_buffer_pool
160321 12:02:10 [00] ...done
160321 12:02:10 Backup created in directory '/data1/dbatemp/2016-03-21_12-02-03'
MySQL binlog position: filename 'mysql-bin.000001', position '154'
160321 12:02:10 [00] Writing backup-my.cnf
160321 12:02:10 [00] ...done
160321 12:02:10 [00] Writing xtrabackup_info
160321 12:02:10 [00] ...done
xtrabackup: Transaction log of lsn (4151355) to (4151364) was copied.
160321 12:02:10 completed OK!
### prepare增量备份
prepare base
innobackupex --incremental --apply-log --redo-only /data1/dbatemp/2016-03-21_12-02-03/ --use-memory=1G
/usr/local/xtrabackup/bin/innobackupex version 2.4.1 based on MySQL server 5.7.10 Linux (x86_64) (revision id: a2dc9d4)
xtrabackup: cd to /data1/dbatemp/2016-03-21_12-02-03
xtrabackup: This target seems to be not prepared yet.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(4151355)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 8388608
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = .
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 8388608
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 1073741824 bytes for buffer pool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support not available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 1G, instances = 1, chunk size = 128M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 4151355
InnoDB: Doing recovery: scanned up to log sequence number 4151364 (0%)
InnoDB: Doing recovery: scanned up to log sequence number 4151364 (0%)
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: xtrabackup: Last MySQL binlog file position 179018, file name mysql-bin.000001
InnoDB: not started
InnoDB: xtrabackup: Last MySQL binlog file position 179018, file name mysql-bin.000001
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 4151373
InnoDB: Number of pools: 1
160321 12:15:37 completed OK!
```
prepare增量:
innobackupex --incremental --apply-log --redo-only /data1/dbatemp/2016-03-21_12-02-03/ --use-memory=1G --incremental-dir=/data1/dbatemp/2016-03-21_12-19-21/
/usr/local/xtrabackup/bin/innobackupex version 2.4.1 based on MySQL server 5.7.10 Linux (x86_64) (revision id: a2dc9d4)
incremental backup from 4151355 is enabled.
xtrabackup: cd to /data1/dbatemp/2016-03-21_12-02-03
xtrabackup: This target seems to be already prepared with --apply-log-only.
InnoDB: Number of pools: 1
xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(4151355)
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = /data1/dbatemp/2016-03-21_12-19-21/
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 8388608
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 30 for slow_query_log/global_query_review_history, old maximum was 0
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//ibdata1.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//ibdata1.delta to ./ibdata1...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//slow_query_log/global_query_review.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//slow_query_log/global_query_review.ibd.delta to ./slow_query_log/global_query_review.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//slow_query_log/global_query_review_history.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//slow_query_log/global_query_review_history.ibd.delta to ./slow_query_log/global_query_review_history.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//abc/weibo_asset_info.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//abc/weibo_asset_info.ibd.delta to ./abc/weibo_asset_info.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//abc/object_info.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//abc/object_info.ibd.delta to ./abc/object_info.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_transition.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_transition.ibd.delta to ./mysql/time_zone_transition.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/slave_relay_log_info.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/slave_relay_log_info.ibd.delta to ./mysql/slave_relay_log_info.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/engine_cost.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/engine_cost.ibd.delta to ./mysql/engine_cost.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/slave_worker_info.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/slave_worker_info.ibd.delta to ./mysql/slave_worker_info.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_leap_second.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_leap_second.ibd.delta to ./mysql/time_zone_leap_second.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/help_category.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/help_category.ibd.delta to ./mysql/help_category.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/slave_master_info.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/slave_master_info.ibd.delta to ./mysql/slave_master_info.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/servers.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/servers.ibd.delta to ./mysql/servers.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_name.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_name.ibd.delta to ./mysql/time_zone_name.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/plugin.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/plugin.ibd.delta to ./mysql/plugin.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/innodb_index_stats.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/innodb_index_stats.ibd.delta to ./mysql/innodb_index_stats.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/server_cost.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/server_cost.ibd.delta to ./mysql/server_cost.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/help_topic.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/help_topic.ibd.delta to ./mysql/help_topic.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_transition_type.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone_transition_type.ibd.delta to ./mysql/time_zone_transition_type.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/help_relation.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/help_relation.ibd.delta to ./mysql/help_relation.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/gtid_executed.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/gtid_executed.ibd.delta to ./mysql/gtid_executed.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/innodb_table_stats.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/innodb_table_stats.ibd.delta to ./mysql/innodb_table_stats.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/time_zone.ibd.delta to ./mysql/time_zone.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//mysql/help_keyword.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//mysql/help_keyword.ibd.delta to ./mysql/help_keyword.ibd...
xtrabackup: page size for /data1/dbatemp/2016-03-21_12-19-21//sys/sys_config.ibd.delta is 16384 bytes
Applying /data1/dbatemp/2016-03-21_12-19-21//sys/sys_config.ibd.delta to ./sys/sys_config.ibd...
xtrabackup: using the following InnoDB configuration for recovery:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = /data1/dbatemp/2016-03-21_12-19-21/
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 8388608
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 1073741824 bytes for buffer pool (set by --use-memory parameter)
InnoDB: PUNCH HOLE support not available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Number of pools: 1
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 1G, instances = 1, chunk size = 128M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 4151355
InnoDB: Doing recovery: scanned up to log sequence number 4151364 (0%)
InnoDB: Doing recovery: scanned up to log sequence number 4151364 (0%)
InnoDB: Are you sure you are using the right ib_logfiles to start up the database? Log sequence number in the ib_logfiles is 4151355, less than the log sequence number in the first system tablespace file header, 4151373.
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: xtrabackup: Last MySQL binlog file position 179018, file name mysql-bin.000001
InnoDB: not started
InnoDB: xtrabackup: Last MySQL binlog file position 179018, file name mysql-bin.000001
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 4151373
InnoDB: Number of pools: 1
160321 12:21:44 [01] Copying /data1/dbatemp/2016-03-21_12-19-21/slow_query_log/db.opt to ./slow_query_log/db.opt
160321 12:21:44 [01] ...done
160321 12:21:44 [01] Copying /data1/dbatemp/2016-03-21_12-19-21/slow_query_log/global_query_review_history.frm to ./slow_query_log/global_query_review_history.frm
160321 12:21:44 [01] ...done
160321 12:21:44 [01] Copying /data1/dbatemp/2016-03-21_12-19-21/slow_query_log/global_query_review.frm to ./slow_query_log/global_query_review.frm
160321 12:21:44 [01] ...done
160321 12:21:44 [01] Copying /data1/dbatemp/2016-03-21_12-19-21/abc/weibo_asset_info.frm to ./abc/weibo_asset_info.frm
160321 12:21:44 [01] ...done
160321 12:21:44 [01] Copying /data1/dbatemp/2016-03-21_12-19-21/abc/db.opt to ./abc/db.opt
160321 12:21:44 [01] ...done
160321 12:21:48 [01] Copying /data1/dbatemp/2016-03-21_12-19-21/sys/session.frm to ./sys/session.frm
160321 12:21:48 [01] ...done
160321 12:21:48 [00] Copying /data1/dbatemp/2016-03-21_12-19-21//xtrabackup_binlog_info to ./xtrabackup_binlog_info
160321 12:21:48 [00] ...done
160321 12:21:48 [00] Copying /data1/dbatemp/2016-03-21_12-19-21//xtrabackup_info to ./xtrabackup_info
160321 12:21:48 [00] ...done
160321 12:21:48 completed OK!
[root@hebe211 dbatemp]# cat 2016-03-21_12-02-03/xtrabackup_checkpoints
backup_type = log-applied
from_lsn = 0
to_lsn = 4151355
last_lsn = 4151364
compact = 0
recover_binlog_info = 0
[root@hebe211 dbatemp]# cat 2016-03-21_12-19-21/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 4151355
to_lsn = 4151355
last_lsn = 4151364
compact = 0
recover_binlog_info = 0
prepare(base+incremental) 可选
压缩备份
innobackupex --compress --compress-threads=8 /data1/dbatemp/
生成QP文件
解压缩:
innobackupex --decompress /data1/dbatemp/2016-03-21_12-32-46/
需要安装qpress
备份还原单表
创建单表的Backup
innobackupex --include='abc.weibo_asset_info' /data1/dbatemp/
prepare单表bakcup
innobackupex --apply-log --export /data1/dbatemp/2016-03-21_12-46-24/
xtrabackup: export metadata of table 'abc/weibo_asset_info' to file `./abc/weibo_asset_info.exp` (4 indexes)
xtrabackup: name=PRIMARY, id.low=68, page=3
xtrabackup: name=ip_in, id.low=69, page=4
xtrabackup: name=owner, id.low=70, page=5
-rw-r--r-- 1 root root 1309 Mar 21 12:49 weibo_asset_info.cfg
-rw-r----- 1 root root 16384 Mar 21 12:49 weibo_asset_info.exp
-rw-r----- 1 root root 8980 Mar 21 12:46 weibo_asset_info.frm
-rw-r----- 1 root root 589824 Mar 21 12:46 weibo_asset_info.ibd
还原单表
还原机上执行:
alter table weibo_asset_info discard tablespace;
将weibo_asset_info.exp和weibo_asset_ibd文件传到目标机目标目录中
执行:
alter table weibo_asset_info import tablespace;
xtrabackup
fullbackup
创建full backup
xtrabackup --backup --target-dir=/data1/dbatemp/testx/
prepare backup
xtrabackup --prepare --target-dir=/data1/dbatemp/testx/
增量backup
创建一个full backup
xtrabackup --backup --target-dir=/data1/dbatemp/testa/
创建增量
xtrabackup --backup --target-dir=/data1/dbatemp/testa_incremental --incremental-basedir=/data1/dbatemp/testa
prepare base
xtrabackup --prepare --apply-log-only --target-dir=/data1/dbatemp/testa/
prepare incremental
xtrabackup --prepare --apply-log-only --target-dir=/data1/dbatemp/testa/ --incremental-dir=/data1/dbatemp/testa_incremental
prepare base+incremental
xtrabackup --prepare --target-dir=/data1/dbatemp/testa/
还原备份（需手动）
mkdir mysql5711
cd /data1/dbatemp/testa
rsync -rvt --exclude 'xtrabackup_checkpoints' --exclude 'xtrabackup_logfile' ./ /data1/mysql5711
cp my5711.cnf /data1/mysql5711
chown -R my5711:mysql mysql5711
创建基于GTID的SLAVE
创建全备
xtrabackup --backup --target-dir=/data1/dbatemp/testb/
MySQL binlog position: filename 'mysql-bin.000002', position '1099', GTID of the last change 'a34b5a32-e04e-11e5-a5bf-782b22675711:1'
MySQL slave binlog position: master host '10.75.22.67', purge list 'a34b5a32-e04e-11e5-a5bf-782b22675711:1'
prepare
xtrabackup --prepare --target-dir=/data1/dbatemp/testb/
restore,将backup移动到目标目录或者服务器
配置开启gtid的slave
set global gtid_purged=“a34b5a32-e04e-11e5-a5bf-782b22675711:1”;
change master to master_host='10.75.22.67', master_user='replica', master_password='eHnNCaQE3ND',MASTER_PORT=5711,MASTER_AUTO_POSITION = 1;
————————————————————————————————————————————————————————————————————————————————————————————————————
xtrabackup2.4.1文档
- innobackupex innobackupex只是xtrabackup的一个符号链接，innobackupex仍然支持像2.2版本一样支持所有的特性及语法，在将来的版本中会被降级或者移除
- xtrabackup 备份整个MySQL实例的MyISAM,InnoDB表，XtraDB表
- xbcrpt 加密和解密备份文件
- xbstream 允许streaming和通过xbstream格式中提取文件
- xbcloud 从云中上传或者下载全部或者部分xbstream归档文件
- 2.3之后的版本推荐通过xtrabackup脚本备份
Percona Xtrabackup Features
- 热备
- 增量复制
- 将压缩后的备份stream到其他server
- 在线的在mysql server实例之间移动表
- 更轻易的搭建新的从库
- 备份不增加server的压力
Innobackupex
- 前提
- 连接和权限 连接server，databases user通过--user和--password选项,如果不指定，xtrabackup认为是系统用户执行
$ 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/
- 其他连接选项
|
|
|
|
|
|
|
|
- 许可和权限
连接数据库之后，需要server文件系统层面datadir目录的读写和执行权限
至于数据库层面，需要如下权限:
1,RELOAD和LOCK TABLES权限
需要在拷贝文件之前FLUSH TABLES WITH READLOCKS和FLUSH ENGINE LOGS。另外当开启Backup Locks,执行LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP需要这两样权限
2，REPLICATION CLIENT权限 获得binlog的点位
3，CREATE TABLESPACE权限 目的是为了导入tables
4，PROCESS权限 show processlist
5, SUPER权限 复制环境下start slave 和stop slave
6，CREATE权限 目的是创建PERCONA_SECHEMA.xtrabackup_history数据库和表
7，INSERT权限 在PERCONA_SCHEAM.xtrabackup_history表中增加历史记录
8，SELECT权限 使用innobackupex --incremental-history-name 或者innobackupex --incremental-history-uuid目的是为了查询PERCONA_SCHEMA.xtrabackup表中innodb_tolsn的值
创建一个能够full backup最小权限的数据库用户:
mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 's3cret'; - mysql> GRANT RELOAD,LOCK TABLES,REPLICATION CLIENT ON *.* TO 'bkpuser'@'localhost';
- mysql> FLUSH PRIVILEGES;
-
全量备份生命周期-FULL Backups
通过Innobackupex创建一个备份
innobackupex是一个通过xtrabackup结合了xbstream和xbcrypt等来备份一整个数据库实例的工具
蒋健一个完整备份，除了连接数据库的选项还只需要一个参数，备份存储目录的路径
$ innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/
之后检查确认信息输出的最后一行:
innobackupex: Backup created in directory ’/path/to/BACKUP-DIR/2013-03-25_00-00-09’
innobackupex: MySQL binlog position: filename ’mysql-bin.000003’, position 1946
111225 00:00:53 innobackupex: completed OK!
备份会最终存储在以时间戳命名的目录内
在底层，在后台，innobackupex被称作二进制xtrabackup来备份Innodb所有表的数据并且拷贝所有的frm表定义文件，数据，和MyISAM,MERGE,CSV表相关的文件，触发器，数据库配置文件到一个时间戳的目录中去
其他需要考虑的选项
--no-timestamp：告诉innobackupex不要创建一个时间戳目录来存储备份
--defaults-file：可以提供innobackupex其他的数据库配置文件。唯一的限制就是必须放在第一个参数的位置
innobackupex --defaults-file=/tmp/other-my.cnf --user=XXX --password=XXX /path/to/backup
PREPARE阶段，用innobackupex prepare Full Backup
在创建了一个backup之后，数据还不能用于还原，因为有未提交的事务未完成或者事务日志需要重放，做这些待定的操作需要数据文件一致.这些都是prepare阶段的目的，一旦这些完成，数据就可以用了
需要指定选项apply-log：
innobakupex --apply-log /path/to/BACKUP-DIR
如果成功了，innobackupex操作之后，数据是立刻可用的
在后台，innobackupex通过读取backup-my.cnf开始prepare进程，在之后，innobackupe重放已提交的事务并回滚未提交的事务，一旦这些操作完成，所有信息在表空间中(innodb文件)，Log文件被重建.这些说明了调用xtrabackup --prepare两次。
注意这个preparation不适合增量备份，如果基于增量备份，将无法'add'增量部分
通过Innobackupex还原Full Backup
--copy-back选项，在server的datadir目录执行一份备份的还原
innobakupex --copy-back /path/to/BACKUP-DIR
--copy-back:做数据恢复时将备份数据文件拷贝到MySQL服务器的datadir
会跟具体my.cnf文件里的配置，拷贝所有数据相关的文件到datadir。
注意：
1.datadir目录必须为空。除非指定innobackupex --force-non-empty-directorires选项指定，否则--copy-backup选项不会覆盖
2.在restore之前,必须shutdown MySQL实例，你不能将一个运行中的实例restore到datadir目录中
3.由于文件属性会被保留，大部分情况下你需要在启动实例之前将文件的属主改为mysql，这些文件将属于创建备份的用户
chown -R my5711:mysql /data1/dbrestore
以上需要在用户调用Innobackupex之前完成
其他类型备份
通过Innobackupex进行增量备份
在每个备份之间并不是所有的信息都有变化，增量备份的目的是减少需要的存储容量和创建一份备份的时间
这些可以完成是因为每个InnoDB的页都有一个LSN，这个LSN相当于一整个数据库的版本号码，每次数据库更改，这个Number就会递增
增量备份就是拷贝某一个指定LSN开始的所有page
一旦这些pages以他们各自的顺序被放到一起，应用这些日志将重新创建影响数据库的进程，在创建backup时刻产生数据
通过innobakupex创建一份增量备份
首先，创建一份全量备份作为基础用于之后的增量备份
innobackupex /data1/dbbackup
将会在/data1/dbbackup目录生成一个带有时间戳的目录，比如假设备份是在上个月月底最后一天创建.BASEDIR是/data1/dbbackup/2016-02-29_23-01-18
可以通过innobackupex --no-timestamp选项覆盖这种行为，备份将会被创建在指定的目录中
如果检查BASE-DIR目录中的xtrabackup-checkpoints文件，你能看到如下：
backup_type = full-backuped
from_lsn = 0
to_lsn = 1291135
第二天创建一份增量备份,通过--incremental选项并提供BASEDIR:
innobackupex --incremental /data1/backups --incremental-basedir=BASEDIR
会在/data1/backups目录里生成另一份带有时间戳的目录，就是/data1/backups/2016-03-01_23-01-18,该目录包含了增量备份，我们称之为INCREMENTAL-DIR-1,如果检查该目录的xtrabackup-checkpoints文件。会看到如下:
backup_type = incremental
from_len = 1291135
to_lsn = 1352113
类似的，第三天创建另一份增量备份。但是第二天的增量备份变成了BASEDIR
innobackupex --incremental /data/backups --incremental-basedir=INCRENMENTAL-DIR-1
结果生成/data1/backups/2016-03-02_23-01-18，用INCREMENTAL-DIR-2来表示:
backup_type = incremental
from_lsn = 1352113
to_lsn = 1358967
像我们之前所说，增量备份只拷贝LSN大于一个指定值的pages，提供LSN会产生相同数据的目录：
innobackupex --incremental /data/backups --incremental-lsn=1291135
innobackupex --incremental /data/bakcups --incremental-lsn=1358967
因为全备或上一个增备并不是总在系统中（如备份后传输到远程）,用这种方法做增量备份非常有用。这种过程只能影响XtraDB和InnoDB表，其他引擎的表如MyISAM.在做增量备份的过程中时候会拷贝全部。
通过innobakupex prepare一份增量备份
prepare增量备份与全量备份不同。这里需要额外注意：
- 首先只有提交过的事务需要在每份备份中个重放 (apply-log BASEDIR)
- 这些将增量的部分合并到全量备份的base中去()
- 然后，未提交的事务必须回滚，为了有一个随时可用的备份
如果在基于base backup中重放提交事务回滚未提交事务，是不能add增量的。如果对于增量的这样做，是不能add从那刻起的数据和其余的增量。
--redo-only --apply-log:
强制备份日志时只redo ,跳过rollback。这在做增量备份时非常必要
innobackupex --apply-log --redo-only BASE-DIR
然后，第一个增量Backup能apply给base backup:
innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCRENMENTAL-DIR-1
如果没有--incremental-dir被设置了，innobackupex会选择在basedir里最近创建的一个子目录
此时，BASE-DIR包含了一直到第一次增量备份的数据，注意全备永远都在base backup目录里
然后在第二个增量备份上重复这个过程:
innobackupex --apply-log BASE-DIR --incremental-dir=INCREMENTAL-DIR-2
如果出现'complete ok'，最终的数据会都merge到base backup目录中去（BASE-DIR）
注意：--redo-only用于merging所有的增量除了最后一个
你可以通过以上的过程给base增加更多的增量，只要按照备份的完成的时间顺序依次即可。如果用错误的顺序Merge增量，备份就完全无用了。如果对apply的顺序有疑问，可以检查每个目录的xtrabackup_checkpoints文件
一旦你对base backup目录merge完所有的增量，接下来prepare，回滚未提交的事务:
innobackupex --apply-log BASE-DIR (innobackupex回滚未提交的事务)
此时的backup可以立刻用于还原了，此步preparation是可选的，然和，如果你还原没有这步，database server会开始rollback未提交的事务。如果发生crash时，database server会做同样的工作。这会延迟db server的启动时间，如果此步prepare则会避免
注意innobacupex不会创建iblog*这些文件，如果想要创建，用xtrabackup -prepare作用于该目录，否则，这些文件在server启动的时候被创建
通过innobackupex还原增量备份
preparing增量备份之后，base dir就是一个full backup,还原方式:
innobackupex --copy-back BASE-DIR
通过xbstream和tar进行增量流式备份
使用xbstream streaming选项，备份可以被打包成自定义的xbstream格式，同样需要一个Base backup
innobakcupex /data/bakcups
本地备份：
innobackupex --incremental --incremental-lsn=LSN-number --stream=xbstream ./ > incremental.xbstream
解压备份:
xbstream -x < incremental.xbstream
做一份本地备份并streaming到远程服务器然后解压:
innobackupex --incremental --incremental-lsn=LSN-number --stream=xbstream ./ | /
ssh user@hostname " cat - | xbstream -x -C > /backup-dir/"
--stream=[tar]
备 份文件输出格式, tar时使用tar4ibd , 该文件可在XtarBackup binary文件中获得.如果备份时有指定--stream=tar, 则tar4ibd文件所处目录一定要在$PATH中(因为使用的是tar4ibd去压缩, 在XtraBackup的binary包中可获得该文件)。
在 使用参数stream=tar备份的时候，你的xtrabackup_logfile可能会临时放在/tmp目录下，如果你备份的时候并发写入较大的话 xtrabackup_logfile可能会很大(5G+)，很可能会撑满你的/tmp目录，可以通过参数--tmpdir指定目录来解决这个问题
部分备份
只备份部分的表或者db，前提是开启innodb_file_per_table选项，每张表有独立的表空间。你不能通过简单地将prepared的部分备份使用--copy-back选项直接复制回数据目录，而是要通过导入表的方向来实现还原。当然，有些情况下，部分备份也可以直接通过--copy-back进行还原，但这种方式还原而来的数据多数会产生数据不一致的问题，因此，无论如何不推荐使用这种方式。
创建部分备份
有三种方法指定备份那部分数据
- --include选项 使用正则表达式方式时，要求为其指定匹配要备份的表的完整名称，即databasename.tablename
innobackupex --include='^mydatabase[.]mytable' /path/to/backup
上面的指令只备份表名相匹配的数据。--include选项传递给xtrabackup --tables，对每个库中的每个表逐一匹配，因此会创建所有的库，不过是空的目录。
- --tables-file选项 此选项的参数需要是一个文件名，此文件中每行包含一个要备份的表的完整名称，格式为databasename.tablename。
echo "mydatabase.mytable" > /tmp/tables.txt
innobackupex --tables-file=/tmp/tables.txt /path/to/backup
该选项传递给xtrabackup --tables-file，与--table选项不同，只有要备份的表的库才会被创建
- --databases选项 此选项接受的参数为数据名，如果要指定多个数据库，彼此间需要以空格隔开；同时，在指定某数据库时，也可以只指定其中的某张表。此外，此选项也可以接受一个文件为参数，文件中每一行为一个要备份的对象
innobackupex --databases="mydatabase.mytable mysql" /path/to/backup
该选项对innodb引擎表无效，还是会备份的
prepare部分备份
prepare部分备份的过程类似于导出表的过程，要使用--export选项进行：
innobackupex --apply-log --export /path/to/partial/backup
此命令执行过程中，innobackupex会调用xtrabackup命令从数据字典中移除缺失的表，因此，会显示出许多关于“表不存在”类的警告信息。同时，也会显示出为备份文件中存在的表创建.exp文件的相关信息。
还原部分备份
还原部分备份的过程跟导入表的过程相同。当然，也可以通过直接复制prepared状态的备份直接至数据目录中实现还原，不要此时要求数据目录处于一致状态。
压缩备份
备份innodb表的时候可能会忽略辅助索引，会使备份更紧凑并且节约磁盘空间。缺点是辅助索引重建导致backup prepare的过程会需要更长的时间。备份大小区别取决于辅助索引大小的区别。。例如没有加--compat选项的full backup.
注意：压缩备份不支持系统表空间，，所以需要打开innodb-file-per-table选项
创建压缩备份
innobackupex --compact /data/backups
会在/data/backups目录下创建个时间戳目录
如果检查BASE-DIR里面的xtrabackup_checkpoints文件，能看到如下:
backup_type = full-backuped
from_lsn = 0
to_lsn = 2888984349
last_lsn = 2888984349
compact = 1
没有--compact选项compact的值为0，这种方法方便的检查备份是否包含辅助索引
preparing压缩备份
preparing压缩备份需要重建索引，prepare backup需要--rebuild-index跟随--apply-logs
innobackupex --apply-log --rebuild-indexes /data/backups/2016-03-14_10-29-48
命令输出，除了标准innobackupex输出，还包含了索引重建的信息
还原压缩备份
innnobackupex有一个--copy-back选项。作用是讲一份backup还原到server的datadir目录中去
innobackupex --copy-back /path/to/backup-dir
会将所有数据相关的所有文件拷贝到datadir目录，由my.cnf配置文件定义
加密备份
2.1版本引入，加密或者解密本地备份或者由xbstream选项备份的流式备份，加密由libgcrypt库实现
创建加密备份
加密需要指定以下选项（--encrypt-key和--encrypt-key-file只需指定其中之一即可）
- --encryption=ALGORITHM 目前支持的算法有ASE128,AES192,AES256
- --encrypt-key=ENCRYPTION_KEY 使用合适长度加密key，因为会记录到命令行，所以不推荐使用
- --encrypt-key-file=KEYFILE 文件必须是一个简单二进制或者文本文件 加密key可通过以下命令行命令生成,生成的值可用于Key openssl rand -base64 24
--encrypt-key选项使用栗子:
innobackupex --encrypt=AES256 --encrypt-key="GCHFLrDFVx6UAsRb88uLVbAVWbK+Yzfs" /data/backups
优化加密过程
引入两个新的选项加速加密过程，--encrypt-threads和--encrypt-chunk-size
--encrypt-threads选项并行加密,--encrypt-chunk-size指定每个加密线程buffer的大小（字节，默认64K）
解密加密备份
可通过xbcrypt二进制解密，以下一行解密所有目录:
for i in ‘find . -iname "*\.xbcrypt"‘; do xbcrypt -d --encrypt-key-file=/root/secret_key --encrypt-
prepare加密备份
在备份解密之后，可以通过full backup一样的方式通过--apply-logs prepare
innobackupex --apply-log /data/backups/2016-03-14_08-31-35/
注意，xtrabackup不会自动移除加密文件，为了清理Backup目录，需要用户手动rm *.xbcrypt文件
还原加密备份
--copy-back选项，通过拷贝文件到datadir目录还原备份
innobackupex --copy-back /path/to/BACKUP-DIR
高级特性
流式和压缩备份
streaming模式，发送backup以tar或者xbstream格式到标准输出，取代拷贝文件到backup目录，这样允许你使用其他程序过滤bakcup的输出提供更灵活的备份，比如，通过管道将backup的输出压缩工具进行压缩，流式备份其中的一项好处是是通过unix管道备份可以自动加密
使用streaming特性，需要使用--stream选项并提供stream的格式（tar或者stream），和在哪里存临时文件
innobackpex --stream=tar /tmp
innobackup以--log-stream模式在子进程中启动xtrabackup,并且重定向日志到临时文件，之后使用xbstream以特殊的xbstream格式将所有数据文件stream到标准输出。
开启压缩时，xtrabakup以指定的压缩算法，压缩所有数据，除了元数据和非innodb文件等不被压缩文件，目前算法只支持quicklz。结果文件为qpress归档文件
使用xbstream作为stream选项，备份可以并行拷贝和压缩，大大的加速了备份过程，以防止备份同时压缩和加密。需要首先先解密之后再解压缩
使用xbstream栗子
存储完整备份到单一文件
innobackupex --stream=xbstream /root/backup/ > /root/backup/backup.xbtream
stream并且压缩这个备份:
innobackupex --stream=xbstream --compress /root/backup/ > /root/backup/backup.xbstream
解包到/root/backup/目录:
xbstream -x < backup.xbstream -C /root/backup/
将压缩backup发送到其他host并解压缩:
innobackupex --compress --stream=xbstream /root/backup/ | ssh user@otherhost "xbstream -x -C /root/
使用tar的栗子
将完整的backup存到一个tar归档
innobackupex --stream=tar /root/backup/ > /root/backup/out.tar
将tar归档发送到其他host
innobackupex --stream=tar ./ | ssh user@destination \ "cat - > /data/backups/backup.tar"
注意提取percona xtrabackup归档需要指定-i选项
tar -xizf backup.tar.gz
可指定喜欢的压缩工具:
innobackupex --stream=tar ./ | gzip - > backup.tar.gz
innobackupex --stream=tar ./ | bzip2 - > backup.tar.bz2
需要注意的是，流式备份需要在还原之前Prepare，流模式不需要prepare
复制环境中备份
从库备份需要指定以下选项:
- --slave-info选项
从库备份，它会打印binlog的点位，还有主库的名字，同样会将这些信息座位change master语句写入xtrabckup_slave_info文件
使用场景，可以通过以此备份搭建一个创建这个主库的从库。 - --safe-slave-backup
为保证一致性复制状态，这个选项停止SQL线程并且等到show status中的slave_open_temp_tables为0的时候开始备份，如果没有打开临时表，bakcup会立刻开始，否则SQL线程启动或者关闭知道没有打开的临时表。如果slave_open_temp_tables在--safe-slave-backup-timeount（默认300秒）秒之后不为0，从库sql线程会在备份完成的时候重启
强烈推荐
加速备份过程
- 通过--parallel拷贝和-compress-threads加速 当进行本地备份或者通过xbstream选项流式备份时，可以通过--parallel选项多个文件并发拷贝，这个选项指定xtrabackup创建生成的线程数来拷贝数据文件 前提需要开启innodb_file_per_table和共享表空间存在多个ibdata文件中，此特性实施级别为文件级别，在高碎片化的数据文件做并发文件转换会增加IO负载，因为极大的随机读请求重叠，你可以考虑对文件系统调优以获得最大的性能 如果数据存到单一文件中，这个选项没有任何影响。使用方法: 本地： innobackupex --parallel=4 /path/to/backup 如果使用xbstream在流式备份中可以通过--compress-threads选项加速压缩过程。这个选项指定了由并行数据压缩中xtrabackup创建的线程数，默认值为1 使用这个特性，只需加上该选项 innobackupex --stream=xbstream --compress --compress-threads=4 ./ > backup.xbstream
在applying log之前，压缩文件需要被解压缩
- 通过--rsync选项加速
为了加速备份过程，同时减小FLUSH TBALES WITH READ LOCAK阻塞写的时间，当该选项指定时，innobackupex使用rsync拷贝所有的非InnoDB文件替换cp。尤其适用于有大量的库和表的时候会更快。innobackup会调用rsync两次。1、执行flush tables with read lock之前；2、减少读锁被持有的时间内。因为第一调用在刷新读锁之前，所以它仅仅同步那些非事务的数据的变化
（它不能和--remote-host、--stream一起使用）
节流（Throttling）备份
虽然innobackupex不会阻塞任何数据库的操作，但是备份这个过程会给系统增加Load,如果系统没有更多的IO能力，那么可以限制innoabckupex读写Innodb数据的频率,通过--throttle选项控制
该选项直接传给xtrabackup二进制程序，并仅限制了innodb表的日志和文件操作的
iostat命令可以检查系统上IO操作，
注意innobackup --throttle选项只在备份阶段工作，innobackupex --apply-log and innobackupex --copy-back并不工作
--throttle选项很像mysqlbackup中的--sleep选项
还原单表
早于5.6b版本，是不可能在server中间拷贝文件来拷贝表。然而通过Xtrabackup，你可以任何innodb数据库中间导出单个表，并且把它们导入到MySQL5.6中（source不一定是MySQL5.6,但是destination必须是），并且只对独立ibd文件有效
导出表
exporting不是在创建backup的时候，而是在prepare阶段完成，一旦full backup建好，用--export选项prepare它
innobackupex --apply-log --export /path/to/backup
会为每个有独立表空间的Innodb创建一个.exp扩展的文件。
举个栗子：
find /data/backups/mysql/ -name export_test.*
/data/backups/mysql/test/export_test.exp
/data/backups/mysql/test/export_test.ibd
/data/backups/mysql/test/export_test.cfg
有三个文件需要导入线上5.6的表中
MySQL通过dump成一种特别格式的的Innodb字典的.cfg文件，这种格式不同于.exp。严格来说，.cfg文件不需要导入mysql5.6表空间。表空间即使从不同的server上也会导入成功。如果相关的.cfg文件在同样的目录中，innodb会做schema验证
每个.exp(或者.cfg)用来导入表
注意：innodb 慢停实例（full purge+change buffer merge）通过on --export,否则表空间会不一致并且不会被导入。所有常见的性能问题会被考虑：足够的buffer pool(例如--use-memory,默认100M)和足够的存储，否则将会耗费很久完成导出
导入表
将一张表导入到其他服务器上，首先以同样的表结构创建一张新表用于导入：
OTHERSERVER|mysql> CREATE TABLE mytable (...) ENGINE=InnoDB;
然后丢弃表空间:
OTHERSERVER|mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
然后，拷贝mytable.ibd和mytable.exp(如果导入到5.6则是mytable.cfg)到数据库家目录，然后导入表空间:
OTHERSERVER|mysql> ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;
一旦执行完成。导入表的书库是立刻可用的
基于时间点恢复
通过innobackupex和二进制日志可恢复指定时间点的数据
注意二进制日志包含从过去的一个时间点开始数据库的改变操作，你需要一个full datadir作为base，然后可以从二进制日志中apply一系列的操作使数据匹配你想要的那个时间点的操作
做一份snapshot，我们可以通过innobackupex做一份全备full backup
innobackupex /path/to/backup --no-timestamp
出于方便使用--no-timestamp选项。之后我们开始prepare，为了之后做好还原的准备
innobackupex --apply-log /path/to/bakcup
现在，假设过去了一段时间，你希望还原数据库到过去的某个特定点，想下制作快照时点的限制
想要找出二进制日志情况，执行show binary logs和show master status
然后找出快照生成时候的pos点。找到backup目录下的xtrabackup_binlog_info
cat /path/to/backup/xtrabackup_binlog_info
mysql-bin.000003 57
这会告诉备份的时间点的binlog日志及Pos点，这个pos点在还原备份时候非常有效
innobackupex --copy-back /path/to/backup
下一步就是从二进制日志中用mysqlbinlog从快照的pos点开始提前查询语句并重定向到一个文件中
mysqlbinlog /path/to/datadir/mysql-bin.000003 /path/to/datadir/mysql-bin.000004 --start-position=57 > mybinlog.sql
注意如果有多个binlog，需要列出所有
时刻观察来决定哪个POS点或者时间点是你要还原的那个点。一旦决定好了。管道传向server，假设时间点是11-12-25 01：00：00:
mysqlbinlog /path/to/datadir/mysql-bin.000003 /path/to/datadir/mysql-bin.000004 \
--start-position=57 --stop-datetime="11-12-25 01:00:00" | mysql -u root -p
提升FLUSH TABLES WITH READ LOCKING handling
备份时，FLUSH TABLES WITH READ LOCK会在备份非innodb文件之前使用来保证备份的一致性，FLUSH TABLES WITH READ LOCK甚至有查询执行了几个小时的时候仍可以运行，这种情况下，任何都会锁在Waiting for table flush or Waiting for master to send event这两种状态下，kill掉也不解决任何问题。只有kill掉导致FLUSH锁住的慢查才能让server重新正常运行。这就意味着如果长时间运行的查询时，FLUSH TABLES WITH READ LOCK会被卡住，
注意，上述情况在backup locks是无效的，Percona Server 5.6+中特性，XtraBackup会自动拷贝非Innodb数据避免阻塞修改InnoDB表的DML查询
两件事可以避免上述问题：
innobackupex 等待好时机
innobackupex 可以Kill阻止获得全局锁的查询（所有或者仅select查询）
等待查询完成
获取全局锁的好时机是指所有长查询都执行完毕，为防止innobackupex等待执行LUSH太长时间。新选项被引入:
innobakcupex --ftwrl-wait-timeout选项，限制等待时间，一旦超时就会报错退出。默认值为0，关闭此特性
另一个是设置等待查询的类型，innobackupex --ftwrl-sait-query-type，可选址为all和update,设置为all时，innobackupex会在执行FLUSH TABLES WITH READ LOCK之前等待所有长时查询完成（执行时间超过innobackupex--ftwrl-wait-threshold），当值为update时会等待UPDATE/ALTER/REPLACE/INSERT查询完成
--lock-wait-threshold用来定义 --locl-wait-query-type中的长运行查询，如果超过--lock-wait-threshold都算长运行查询。
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/
innobacupex花费不超过3分钟时间等待超过40秒的查询完成，FLUSH之后，innobackupex会等待20秒时间获取全局锁，如果超过20秒仍然没有获得，会kill所有的运行时间超过FLUSH命令的查询
innobackupex是如何工作的
2.3起innobackupex用c重写并且作为xtrabackup的符号连接，innobackupex支持2.2版本的所有特性和语法。但是现在已降级并且在下一个major版本中将被移除，。新的特性语法将加在xtrabakup中，而不是innobackupex中
making a backup
如果没有模式指定，innobakucpex默认为backup模式
默认的，innobackupex通过--suspend-at-end选项启动xtrabackup,并且让它拷贝innodb数据文件，当xtrabackup完成，innobackupex看着它创建xtarbackup_suspended_2文件并且执行FLUSH TABLES WITH READ LOCK.
innoabackupex之后检查MySQL变量来决定server支持哪些特性，特别是backup locks,change page bitmaps,GTID mode等等，如果一切顺利，二进制作为一个子进程启动
innobackupex在设置--safe-slave-backup选项后等待同步，并且flush所有表with read lock.阻止所有myisam表写入(除非指定--mo-lock)。
一旦完成，开始备份所有非Innodb文件，.frm,.MRG,.MYD,.MYI,.CSV,.OPT文件等等
当所有文件备份后，执行ibbackup并且等待直到完成备份完成拷贝事务完成。之后，表被解锁，开启同步（如果指定--safe-slave-backup）并且与server的连接关闭。之后，移除xtrabackup_suspended_2文件并允许xtrabackup退出
同时在备份的目录创建如下文件:
xtrabackcup_checkpoints 包含备份类型和LSN
xtrabackcup_binlog_info 包含开启备份时刻的binlog和POS
xtrabackcup_binlog_pos_innodb 包含开始备份InnoDB事务相关的binlog的POS
xtrabackup_slave_info 包含master的binlog和POS（需指定--slave-info）
backup-my.cnf 备份需要的my.cnf中的选项
xtrabackup_binary 包含backup需要的二进制文件
mysql-stderr
mysql-stdout
最终binlog pos打印在标准错误输出并且Innobackupex退出码为0退出
通过备份还原
还原备份通过--copy-back选项
innobackupex读取my.cnf中的变量并检查相关目录是否存在
之后拷贝MyISAM表，索引等等。首先是innodb表其次索引，最后是log文件。拷贝时保留文件属性。
作为替换，--move-back选项用来还原备份。这个选项与--copy-back相似。唯一的区别是它不拷贝文件，而是移动文件到目的地。这个选项移除backup文件，用时候必须小心。使用场景：没有足够的磁盘空间同事保留数据文件和Backup副本
innobackupex 命令行选项
选项
- --apply-log
通过apply名叫xtrabackup_logfile的事务日志来在BACKUP-DIR目录中Prepare一个backup，同样，创建新的事务日志。innodb配置从生成bakcup过程中innobakcupex创建的backup-my.cnf文件读取，innobackupex --apply-log 默认使用bakcup-my.cnf中的innodb配置.这里说的Innodb配置指的是影响数据格式的系统变量，例如：innodb_page_size,innodb_log_block_size等等，本地相关变量例如innodb_log_group_home_dir或者innodb_data_file_path.
一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。
对xtrabackup的--prepare参数的封装 - --backup-locks
仅支持percona server5.6，如果server不支持，开启不读私人和产生影响 - --close-files
2.2.5引入的新特性
关闭不再访问的文件句柄，这个选项直接传递给xtrabackup,当xtrabackup打开表空间通常并不关闭文件句柄目的是正确的处理DDL操作。如果表空间数量巨大，这是一种可以关闭不再访问的文件句柄的方法。使用该选项有风险，会有产生不一致备份的可能 - --compact
创建一份没有辅助索引的紧凑的备份，该选项直接传递给xtrabackup - --compress
该选项指导xtrabackup压缩innodb数据文件的backup的拷贝，直接传递给xtrabackup的子进程 - --compress-threads = #
该选项指定并行压缩的worker线程的数量，直接传递给xtrabackup的子进程 - --compress-chunk-size = #
这个选项指定每个压缩线程的内部worker buffer的大小。单位是字节，默认是64K。直接传递给xtrabackup子进程 - --copy-back
执行还原操作，从备份目录中最近的一份备份中拷贝所有文件到datadir,innobackupex --copy-back选项除非指定innobackupex --force-non-empty-directories选项，否则不会拷贝覆盖所有的文件 - --databases=LIST
指定innoabckupex备份的DB列表，该选项接受一个一个字符串参数或者包含DB列表的文件的全路径。如果没有指定该选项，所有包含innodb和myam表的DB会被备份，请确认--databases包含所有的innodb数据库和表，，以便所有的innodb.frm文件也同样备份，如果列表非常长的话。可以以文件代替 - --decompress
解压所有值钱通过--compress选项压缩成的.qp文件。innodbakcupex --parallel选项允许多个文件同时解压。为了解压，qpress工具必须有安装并且访问这个文件的权限。这个进程将在同一个位置移除原来的压缩/加密文件 - --decrypt=ENCRYPTION-ALGORITHM
解密所有之前通过--encrypt选项加密的.xbcrypt文件。--innobackup --parallel选项允许同时多个文件解密 - --defaults-file=[MY.CNF]
该选项指定了从哪个文件读取MySQL配置，必须放在命令行第一个选项的位置 - --defaults-extra-file=[MY.CNF]
指定了在标准defaults-file之前从哪个额外的文件读取MySQL配置，必须在命令行的第一个选项的位置 - --default-group=GROUP-NAME
这个选项接受了一个字符串参数指定读取配置文件的group,在一机多实例的时候需要指定 - --encrypt=ENCRYPTION_ALGORITHM
该选项指定了xtrabackup通过ENCRYPTION_ALGORITHM的算法加密innodb数据文件的备份拷贝，该选项直接传递给xtrabackup子进程 - --encrypt-key=ENCRYPTION_KEY
指导xtrabackup使用了--encrypt选项时候使用ENCRYPTION_KEY这个KEY,直接传递给xtrabackup子进程 - --encrypt-key-file=ENCRYPTION_KEY_FILE
这个选项告诉xtrabackup使用--encrypt的时候。Key存在了ENCRYPTION_KEY_FILE这个文件中 - --encrypt-chunk-size=#
这个选项指定了每个加密线程内部worker buffer的大小，单位字节，直接传递给xtrabackup子进程 - --export=DIRECTORY
这个选项直接传递给 xtrabackup --export选项。开启可导出单独的表之后再导入其他Mysql中 - --extra-lsndir=DIRECTORY
这个选项接受一个字符串参数指定保存额外一份xtrabackup_checkpoints文件的目录，直接传递给xtrabackup --extra-lsndir选项 - --force-non-empty-directories
指定该参数时候，使得innobackupex --copy-back或innobackupex --move-back选项转移文件到非空目录，已存在的文件不会被覆盖，如果--copy-back和--move-back文件需要从备份目录拷贝一个在datadir已经存在的文件，会报错失败 - --galera-info
该选项生成了包含创建备份时候本地节点状态的文件xtrabackup_galera_info文件，该选项只适用于备份PXC。 - --history=NAME
percona server5.6的备份历史记录在percona_schema.xtrabackup_history表 - --host=HOST
选项指定了TCP/IP连接的数据库实例IP - --ibbackup=IBBACKUP-BINARY
这个选项指定了使用哪个xtrabackup二进制程序。IBBACKUP-BINARY是运行percona xtrabackup的命令，。这个选项适用于xtrbackup二进制不在你是搜索和工作目录，如果指定了该选项,innoabackupex自动决定用的二进制程序 - --include=REGEXP
正则表达式匹配表的名字[db.tb]，直接传递给xtrabackup --tables选项。 - --incremental
这个选项告诉xtrabackup创建一个增量备份，直接传递给xtrabakcup子进程，当这个选项指定，需要同时指定--incremental-lisn或者--incremental-basedir。如果没有指定，默认传给xtrabackup --incremental-basedir，值为Backup BASE目录中的第一个时间戳目录 - --incremental-basedir=DIRECTORY
这个选项接受了一个字符串参数指定含有full backup的目录为增量备份的base目录，与--incremental同时使用 - --incremental-dir=DIRECTORY
指定了增量备份的目录,结合full backup生成生成一份新的full bakcup - --incremettal-history-name=NAME
这个选项指定了存储在PERCONA_SCHEMA.xtrabackup_history基于增量备份的历史记录的名字。Percona Xtrabackup搜索历史表查找最近（innodb_to_lsn）成功备份并且将to_lsn值作为增量备份启动出事lsn.与innobackupex--incremental-history-uuid互斥。如果没有检测到有效的lsn，xtrabackup会返回error - --incremetal-history-uuid=UUID
这个选项指定了存储在percona_schema.xtrabackup_history基于增量备份的特定历史记录的UUID - --incremental-lsn=LSN
这个选项指定增量备份的LSN，与--incremental选项一起使用 - --kill-long-queries-timeout=SECONDS
这个选项指定innobackupex从开始执行FLUSH TABLES WITH READ LOCK到kill掉阻塞它的这些查询之间等待的秒数，默认值为0.以为着Innobakcupex不会kill任何查询，使用这个选项xtrabackup需要有Process和super权限。 - --kill-long-query-type=all|select
指定kill的类型，默认是all - --ftwrl-wait-timeout=SECONDS
执行FLUSH TABLES WITH READ LOCK之前，innobackupex等待阻塞查询执行完成等待秒数，超时的时候如果查询仍然没有执行完，innobackupex会终止并报错，默认为0，innobakcupex不等待查询完成立刻FLUSH - --ftwrl-wait-threshold=SECONDS
指定innoabckupex检测到长查询和 innobackupex --ftwrl-wait-timeount不为0,这个长查询可以运行的阈值， - --ftwrl-wait-query-type=all|update
指定innobakcupex获得全局锁之前允许那种查询完成，默认是ALL - --log-copy-interval=#
这个选项指定了每次拷贝log线程完成检查之间的间隔（毫秒） - --move-back
从备份目录中将最近一份备份中的所有文件移动到datadir目录中 - --no-lock
关闭FTWRL的表锁，只有在你所有表都是Innodb表并且你不关心backup的binlog pos点
如果有任何DDL语句正在执行或者非InnoDB正在更新时（包括mysql库下的表），都不应该使用这个选项，后果是导致备份数据不一致
如果考虑备份因为获得锁失败，，可以考虑--safe-slave-backup立刻停止复制线程 - --no-timestamp
这个选项阻止在BACKUP-ROOT-DIR里创建一个时间戳子目录，指定了该选项的话，备份在BACKUP-ROOT-DIR完成 - --no-version-check
这个选项禁用由--version-check打开的version check - --parallel=NUMBER-OF-THREADS
指定xtrabackup并行复制的子进程数。注意是文件级别并行，如果有多个ibd文件，他们会并行拷贝，如果所有的表存在一个表空间文件中，没有任何作用。。直接传递给xtrabakcup --parallel选项 - --password=PASSWORD
- --port=PORT
- --rebuild-indexes
与--apply-log一起用时候才有效。并且直接传递给xtrabackup，在apply log之后重建所有辅助索引，该选项用于Prepare紧凑备份。 - --rebuild-threads=NUMBER-OF-THREADS
与--apply-log和--rebuild-index选项一起用时候才生效，重建索引的时候，xtrabacup以指定的线程数并行的处理表空间文件 - --redo-only
这个选项在prepare base full backup，往其中merge增量备份（但不包括最后一个）时候使用。传递给xtrabackup --apply-log-only的选项。这个强制xtrabackup跳过rollback并且只重做redo - --rsync
通过rsync工具优化本地传输，当指定这个选项，innobackupex使用rsync拷贝非Innodb文件而替换cp，当有很多DB和表的时候会快很多。不能--stream一起使用 - --safe-slave-backup
指定的时候innobackupex会在执行FLUSH TABLES WITH READ LOCK停止sql线程,并且直到show status里slave_open_temp_tables的值为0的时候start backup，。如果没有打开的临时表，就开始备份，否则sql线程start或者stop直到没有打开的临时表，如果在innobackupex --safe-slave-backup-timeout之后slave_open_temp_tables的值仍没有变成0备份就会失败。SQL线程会在backup完成之后重启。 - --safe-slave-backup-timeout=SECONDS
innobackupex --safe-slave-backup应该等多少秒等slave_open_temp_tables变成0，默认是300秒 - --scpopt=SCP-OPTIONS
当--remost-host指定的时候，指定传给scp的命令行选项。如果没有指定，默认为-Cp -c arcfour - --slave-info
对slave进行备份的时候使用，打印出master的名字和binlog pos，同样将这些信息以change master的命令写入xtrabackup_slave_info文件。可以通过基于这份备份启动一个从库并且保存在xtrabackup_slave_info文件中的binlog pos点创建一个新的从库 - --socket
连接本地实例的时候使用 - --sshopt=SSH-OPTIONS
在指定了--remost-host的时候，指定传给ssh的命令行选项 - --stream=STREAMNAME
流式备份的格式，backup完成之后以指定格式到STDOUT，目前只支持tar和xbstream。使用xbstream为percona xtrabakcup发型版本，如果在这个选项之后指定了路径。会理解值为tmpdir - --tables-file=FILE
指定含有表列表的文件，格式为database.table,该选项直接传给xtrabackup's --tables-file - --throttle=IOS
指定每秒IO操作的次数，直接传递给xtrabackup --throttle选项。只作用于bakcup阶段有效。apply-log和--copy-back不生效不要一起用 - --tmpdir=DIRECTORY
指定--stream的时候，指定临时文件存在哪里，在streaming和拷贝到远程server之前，事务日志首先存在临时文件里。 - --use-memory=#
只能和--apply-log选项一起使用，prepare a backup的时候，xtrabackup做crash recovery分配的内存大小，单位字节。也可(1MB,1M,1G,1GB),直接传给xtrabackup --use-memory选项 - --version
显示Innobackupex版本和版权信息后退出 - --version-check
innobackupex在与server创建连接之后的备份阶段进行版本检查
Xtrabackup 二进制
get started
配置xtrabackup
xtrabackup读取配置文件中的[mysqld]和[xtrabackup]部分，读取datardir和innodb选项，可以通过将这些都指定在[xtrabackup]部分。越靠后，越优先。
最简单的在[xtrabackup]部分只指定target_dir,该选项指定backup默认放的目录，例如:
[xtrabackup]
target_dir = /data/backups/mysql
Xtrabackup-FULL BAKCUPS
创建一个备份
运行xtrabackup指定--backup ，--target_dir,--datadir.
如果不指定target_dir，xtrabacup会创建它。如果目录存在且为空，xtrabackup会成功，xtrabackup不会覆盖已有文件。会报“file exist”的错误
这个工具将工作目录转换到datadir,并且执行两项主要的任务:(后台运行的log扫描线程扫描redo log,ibdata1上的文件拷贝线程)
- 后台启动一个拷贝日志的线程，这个线程关注innodb日志文件，当redo log有变化，这个线程拷贝变化的块到到target目录成为xtrabackup_logfile的文件
- 拷贝Innodb数据文件到目标目录，这不是个简单拷贝文件那么简单，它像Innodb那样打开读取文件，读取数据字典并且依次的拷贝一个page
当拷贝完数据文件，xtrabackup停止log-copying线程，并在target目录生成包含了备份类型和开头和结尾的lsn号的xtarabckup_checkpoints文件，
举例命令如下:xtrabakcup --backup --datadir=/data1/mysql/ --target-dir=/data/backups/
备份/data1/mysql目录并存储在/data/backups/mysql/。如果你指定一个相对路径,target目录会关联到当前路径
在备份过程期间，你能看到一大堆输出展示了文件正在拷贝中，同时log file线程重复的扫描redo log，并且文件拷贝线程将innodb数据文件拷贝到target目录
最后一件需要关注的事情是，LSN的值在哪里成为一个数字决定于你的系统
注意：log拷贝线程每秒检查事务日志去看是否写入了新的日志记录需要拷贝，也有偶然的log拷贝线程赶不上大量的写入事务日志的速度，redo log在被读取之前就被覆盖了，就会报错！！！！
当Backup结束，target目录包含了：/data/backups/ibdata11
/data/backups/test
/data/backups/test/tbl1.ibd
/data/backups/xtrabackup_checkpoints
/data/backups/xtrabackup_logfile备份会持续时间决定于数据库大小，在任何时间cancel都是安全的，因为它并不改变数据库
下一步要让backup变为可还原:prepare backup
preparing the backup
用--backup生成备份后，下一步就是prepare。数据文件不是时间点一致的直到他们被prepare，因为他们在程序运行时不同时间拷贝，并且发生时已经改变了，如果你尝试用这些数据文件启动innodb,之后会检测到崩溃，并且crash自己来防止在损坏的数据上继续运行。--prepare阶段让这些文件在任意时间都一致性，所以你可以在上面运行Innodb
注意：innobakcupex --apply-log 自动从bakcup-my.cnf读取innodb配置，或者--defaults-file=bakcup-my.cnf选项传递给xtrabackup。否则会导致不正确还原因为xtrabackup已经用了错误的配置选项
你可以在任何机器上运行Prepare操作，不需要在备份机上或者还原机上操作，你可以拷贝backup到一台专门的中控机并且在prepare
注意：你可以用新版本prepare一个较老版本创建的backup，但反过来不行。在一台不支持的Mysql server版本上prepare一个bakcup应该用支持该server的最新版本，例如，如果通过1.6版本xtrabackup备份mysql5.0,用2.2prepare是不支持的。因为2.1版本中移除了5.0
在prepare阶段，xtarbackup嵌入了修改过的innodb，禁止了innodb的检查，比如日志文件大小是否准确。
prepare阶段就是使用这个嵌入的innodb来做通过日志文件对数据文件进行crash恢复
xtrabackup --prepare --target-dir=/data/backups/mysql
完成之后，可以看到innodb shutdown的信息和lsn
你的备份现在是干净并且一致的了，并且准备好还原，然而，你可能希望额外的步骤让还原更快。这需要第二次Prepare。第一次prepare让数据文件完美的一致性。但是不常见新鲜的Innodb日志文件，如果这时候还原备份并且启动Mysql,它需要创建新的日志文件，这需要一段时间。你也许不想等待。如果你第二次运行--prepare，xtrabackup会创建日志文件，redo log的大小决定于mysql的配置文件
xtrabackup --prepare --target-dir=/data/backups/mysql/
xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to ’--prepare’.
101107 16:54:10 InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib_logfile0 size to <SIZE> MB
InnoDB: Database physically writes the file full: wait...
101107 16:54:10 InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib_logfile1 size to <SIZE> MB
InnoDB: Database physically writes the file full: wait...
101107 16:54:15 InnoDB: Shutdown completed; log sequence number 1284108
第二次或者第三次prepare不会改变已经Prepare的数据文件，你可以看输出:
xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to ’--prepare’.
不推荐prepare的时候中断xtrabackup进程，会导致数据文件损坏并且backup不可用，中断prepare进程不保证backup可用性
如果以后会拿这份这份backup作为基础而进行增量备份，prepare的时候要使用--apply-log-only选项，否则你无法apply增量备份到这份basic全备。
还原全备
xtrabackup没有还原备份的功能。由用户来做，你可以通过rsync或者cp来还原，你应该检查还原文件有正确的属主和权限
注意：datadir在还原备份之前必须为空，同样重要的是Mysql server需要还原之前shutdown，你不能在Mysql运行时还原到datadir目录（除非是导入部分备份）
rsync命令还原:
rsync -avrP /data1/backup/ /data1/mysql
文件属性保留，大多数情况下需要在启动实例之前改变文件的属主
chown -R mysql5711:mysql /data1/mysql5711
注意，xtrabackup只备份Innodb数据，你必须单独还原mysql系统库，myisam数据，表定义文件。或者innobakcupex
其他类型备份
增量备份
xtrabackup和Innobacupex都支持增量备份，意味着可以只拷贝自从上次全备之后变化的数据，你可以在每个full backup之间做很多份增量备份，这样你可以做这样一个备份程序一周做一次full backup每天一次增量，或者一天做一次full backup每小时做一次增量
增量备份原理，每个Innodb页都有一个LSN号，一份增量备份拷贝每个比上次增量备份或者全备LSN更新的page。
有两个算法可以找到这样的需要拷贝的Page的集合
- 对于所有server和版本可用，通过读取所有的数据页检查page的LSN
- 仅对Percona Server适用，忽略
增量备份不会不会实际的和上次的备份比较数据文件。你如果知道LSN的话甚至在没有先前备份的情况下使用通过--incremental-lsn执行一次增量备份。增量备份简单的读取page并且比较他们的LSN与上次备份的LSN。然而你仍然需要一个full bakcup来恢复增量的变化。如果没有一个full bakcup作为一个base，增量备份是没有用的
创建一份增量备份
创建一份增量备份，需要从一个full backup开始，xtrabakcup写一个叫xtrabackup_checkporints的文件到备份目标目录，这个文件包含一行显示to_lsn（backup结束时候的lsn）
xtrabackup --backup --target-dir=/data/backups/base --datadir=/data1/mysql5711
xtrabakcup_checkpoints文件包括
backup_type = full-bakcuped
from_lsn =0
to_lsn =1291135
基于这个full backup创建一份增量：
xtrabackup --backup --target-dir=/data/backups/inc1 --incremental-basedir=/data/backups/base --datadir=/data1/mysql5711
/data/backup/inc1/目录包含了增量的文件，比如ibdata1.delta和test/table1.idb.delta ，代表了从LSN1291135以来的变化，如果检查这个目录的xtrabacup_checkpoints文件，会看见如下:
bacup_type = incremental
from_lsn = 1291135
to_lsn = 1291340
现在可以拿inc1当做接下来增量备份的base目录:
xtrabackup --backup --target-dir=/data/backups/inc2 --incremental-basedir=/data/backups/inc1 --datadir=/data1/mysql5711/
prepare增量备份
增量备份的--prepare阶段与正常备份不同，在正常备份中，执行两种类型操作来保证数据库一致性，已提交的事务会在数据文件中重放，未提交的事务回滚，prepare备份的时候你需要跳过未提交事务的回滚，因为在备份的那个时刻未提交的事务正在进行中，并且明显的它们会在下次增量备份的提交。你需要使用--apply-log-only选项来阻止回滚阶段
如果你不用--apply-log-only选项阻止回滚，那么之后的增量备份就无效了。事务如果被回滚，那之后的增量备份就不能被重放
从你开始创建的full backup，你可以Prepare它，之后重放增量的区别，回忆你已经有如下备份base/,inc1/,inc2/
prepare base备份，然后阻止回滚：
xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base
输出显示lsn为1291135.
备份如果现在还原是非常安全的，甚至回滚的步骤被跳过了，如果你现在还原并启动MySQL,InnoDB会检测到回滚没有执行，之后再在后台进行开始crash恢复，通知你数据没有被正常关闭
重放第一个增量备份给full backup:
xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --incremental-dir=/data/backups/inc1
这样给/data/backups/base目录重放delta文件。将备份的时间前进到增量备份的时间点，之后照常重放事务日志，最终数据是在/data/backups/base并不在增量目录里.
显示如下：
incremental backup from 1291135 is enabled.
xtrabackup: cd to /data/backups/base/
xtrabackup: This target seems to be already prepared.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1291340)
Applying /data/backups/inc1/ibdata1.delta ...
Applying /data/backups/inc1/test/table1.ibd.delta ...
.... snip
101107 20:56:30 InnoDB: Shutdown completed; log sequence number 1291340
如果通过/data/backups/base目录还原，你可以看见数据库的状态是第一次备份时的状态
prepare第二次增量备份以同样的步骤，apply增量到上步的base，将数据的时间点同步到第二次增量备份的时间点
xtrabackup --prepare --target-dir=/data/backups/base --incremental-dir=/data/backups/inc2
--apply-log-only用在merging所有增量除最后一个。最后一步仍然可以用，备份最终也是一直的但是server不会执行回滚步骤
部分备份
需要开启innodb_file_per_table,有三种方式支持部分备份
注意：如果任何匹配的或者列入的表在备份期间删除，xtrabackup会失败
- 使用--tables选项匹配databasename.tablename xtrabackup --backup --datadir=/data1/mysql5711 --target-dir=/data/backups/ --tables="^test[.].*" 备份整个test库
- 使用--tables-file选项
- 使用 --databases 和 --databases-file选项 #### prepare 部分备份 会用--prepare选项进行部分备份的时候，你会看到相关表不存在的报警，原因是这些表存在于InnoDB的数据字典中但是对应的.ibd文件不存在，他们没有被拷贝到备份目录中去，这些表将会从数据字典中移除，但是当你还原备份并且启动InnoDB的时候，他们讲不会存在并在日志文件中报错
压缩备份
不包含辅助索引页，占用更少磁盘空间，缺点是prepare的时间更长因为需要重建辅助索引
注意：压缩备份不支持系统表空间，所以应该打开innodb-file-per-table选项
创建压缩备份
通过--compact选项
xtrabackup --bakcup --compact --target-dir=/data/backups
检查target-dir目录下的xtrabackup-checkpoints文件。如下:
backup_type = full-backuped
from_lsn = 0
to_lsn = 2888984349
last_lsn = 2888984349
compact = 1
如果不使用--compact的话--value的值为0，这个方法可以快速检测备份是否包含辅助索引页
prepare 压缩备份
通过--rebuild-indexes和--apply-logs一起使用
xtrabackup --prepare --rebuild-indexes /data/backups
通过--rebuild-threads选项多线程重建索引
xtrabackup --prepare --rebuild-indexes --rebuild-threads=16 /data/backups/
还原压缩备份
没有现成工具，可以通过rsync或者cp完成，需要检查还原文件是否有正确权限
高级特性:
throttling备份
xtrabackup不会阻塞数据库读写，backup增加系统压力，可以通过--throttle选项，这个选项限制IO操作的数量为每秒每MB
在--backup模式，这个选项限制了xtrabackup每秒执行的对（read和write）。如果你创建一个增量备份。然后限制每秒读IO的数量
默认，no throttling，xtrabackup最快的读写数据，如果你IO限制过于严格，备份会非常慢并且追不上innodb写事务日志的速度，备份将永远无法完成
编写备份脚本
suspending after copying
在备份模式中，xtarbackup在后台拷贝日志文件，前端线程拷贝数据文件，，之后停止日志线程并完成。如果你使用--suspend-at-end选项而不是停止日志线程并完成。xtrabacup会继续拷贝日志文件，并在target目录生成一个xtrabackup_suspended文件，之后要这个文件存在，xtrabackup会继续观察事务日志并把他们拷贝到target目录中xtrabackup_logfile文件。当这个文件移除的时候，xtrabackup会停止拷贝事务日志并退出
该功能协调备份Innodb数据和其他动作时非常有用，最明显的是拷贝表定义文件(.frm)以便备份能被还原，你可以后台启动xtrabakcup，等待xtrabackup_suspended文件被创建，然后拷贝所有你需要完成这个备份的任何文件。。这个就是innobakcupex工具做的工作
生成元数据
备份包含任何你需要还原备份时候需要的信息是个好主意，xtarbackup能打印my.cnf文件中需要还原的数据和日志文件的内容，如果增加--print-param选项。会打印如下内容:
```
This MySQL options file was generated by XtraBackup.
[mysqld]
datadir = /data/mysql/
innodb_data_home_dir = /data/innodb/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /data/innodb-logs/
```
可以重定向输出到backup的target目录
协商source目录
配置文件或者其他因素会导致xtrabackup从不同的位置备份数据。为了防止这些，你可以用--print-param来查找从哪里copy数据。你可以用输出来保证xtrabackup和你的脚本处理同样的数据集
log streaming
可以通过--log-stream 让xtrabackup将redo log文件streaming而不是拷贝，这样会自动添加--suspend-at-end选项。你的脚本可以执行
stream远程备份并通过管道将log文件传给ssh并且通过rsync或者xbstream等工具将数据拷贝到远程服务器上
分析表统计信息
xtrabackup以只读模式分析InnoDB数据文件并提供给统计。可以通过--stats选项。可以同--ables选项一起使用限制检查的的文件。还有--use-memory选项。
你可以在一台运行实例的机器上执行分析，在分析期间数据更改会有出错的几率。或者可以分析备份的拷贝。如果需要使用统计的特性，你需要一个干净的拷贝包括正确的Logfile大小，，所以你需要在一次备份上执行--prepare两次
使用binlog
xtrabakcup提取了innodb事务日志关于对应已提交事务的binlog pos，这个可以打印出backup对应的binlog pos，你可以通过搭建一些列从库或者进行基于时间点的恢复
找到binlog pos
一旦backup prepare之后你可以找到binlog pos，通过运行xtrabakcup --prepare或者innobackupex --apply-log都可以完成。如果bakcup是来源打开binlog的实例。xtrabackup会在target目录创建一个xtrabakcup_binglog_info的文件。这个文件包含了与prepare对应的binlog名字和pos点位
输出的信息在xtrabakcup_binlog_pos_info文件中找到，只有使用innodb引擎才会准确
其他引擎，比如myisam,你应该使用xtrabackup_binlog_info文件获得位置
基于时间点恢复
从一份xtrabackup的备份里基于时间点的恢复，你需要prepare并且还原备份，之后重放xtrabackup_binlog_info中记录的点开始的binlog
搭建一个新的从库
需要先prepare,然后在新从库的data目录中还原，之后使用change master to命令，使用xtrabackup_binlog_info文件的binlog和pos启动复制
还原单独表
在5.6版本之前，即使打开innodb_file_per_table选项，仍然不可能通过在实例之间通过拷贝文件来拷贝表。然而，通过Xtrabackup你可以从任何InnoDB数据库中导出单表，并且导入到5.6中去（source不必是5.6但是destination必须是！！！！！）只在独立.ibd文件生效，如果没有独立ibd文件是不能够导出单表的！！！！！
导出单表
这个表必须在打开innodb_file_per_table模式下创建。所以在在--bakcup创建一份备份之后，.ibd文件应该已经存在于target目录中
当你prepare的时候，需要额外加--export命令:
xtrabacup --prepare --export --target-dir=/data/backups/mysql5711
现在你可以在target目录找到.exp文件
$ find /data/backups/mysql5711/ -name export_test.*
/data/backups/mysql5711/test/export_test.exp
/data/backups/mysql5711/test/export_test.ibd
/data/backups/mysql711/test/export_test.cfg
这三个文件是你将表导入5.6的所有文件
说明：mysql使用cfg文件，这个文件包含了Innodb字典dump。这种格式不同于xtrabDB的.exp文件。严格来讲，.cfg文件在5.6以及之后是不在需要的。如果存在cfg文件，那么Innodb会通过cfg文件做schema验证
导入表
在5.6，以同样表结构创建一张表，然后执行以下步骤：
- 执行alter table test.export_test discard tablespace;需要打开innodb_file_per_table
- 拷贝之前导出到文件目的服务器的数据目录test/子目录
- 执行alter table test.export_test import tablespace; 这张表现在已经导入，你可以通过select命令查看导入数据 ### LRU dump备份 这个特性减少了通过在实例重启之后从ib_lru_dump文件还原buffer pool状态的预热时间。xtrabakcup自动发现ib_lru_dump并且自动备份 如果my.cnf中开启buffer还原选项，buffer pool会在从备份还原之后自动预热。只在Percona server中有这个选项。mysql没有
实施
xtrabakcup的限制
有以下需要注意:
* 如果xtrabakcup_logfile超过4G，32位系统上的xtrabakcup在--prepare阶段会失败
* xtrabackup在第一次--prepare的不会生成新的redo log文件，必须--prepare两次，在第二次的时候才会生成
* 不支持my.cnf里有--set-variable这种格式设置
实施细节
文件权限
xtrabacup以读写方式打开源数据文件，但不更改这些文件，意味着你必须以有写这些文件权限的用户来运行xtrabackup。以读写模式打开文件的原因是xtrabakcup使用内置的Innodb库来打开读写文件，并且Innodb以读写模式打开因为正常假设是需要写这些文件了
调整os buffers
因为xtrabackup读取文件系统的大量数据，可能它使用posix_fadvise()指导操作系统不要尝试缓存从磁盘读取的block。没有这个提示。假设xtrabackup很快再次需要这些块，操作系统更愿意缓存这些块。缓存如此大的文件会给操作系统的虚拟内存增加压力并到底其他进程，比如数据库swap out。xtrabakcup工具通过source和destination如下提示来避免这种情况发生:
posix_fadvise(file，0，0，POSIX_FADV_DONTNEED)
另外，xtrabackup让操作系统在源文件上来执行更挑战性的read-ahead优化
posix_fadvise(file, 0, 0, POSIX_FADV_SEQUENTIAL)
拷贝数据文件
当向target目录拷贝数据文件的时候，xtrabakcup一次读写1MB数据。这是不可配置的。当拷贝事务日志，xtrabackup一次读写512字节。着同样不能配置。是符合Innodb的（percona server的解决办法是有额外的参数innodb_log_block_size）
读取文件之后，xtrabackup一次1MBbuffer遍历page。并通过innodb buf_page_is corrupted()函数检查每个Page的corruption。如果page损坏，便会重读并且每个page重试10次，二次写buffer会跳过这个检查
手册
xtrabackup选项
选项
- --apply-log-only
prepare备份的时候只执行redo阶段，对增量备份非常重要 - --backup
创建备份并且放入--target-dir目录中 - --close-files
不保持文件打开状态，xtrabackup打开表空间的时候通常不会关闭文件句柄目的是为了正确处理DDL操作。然而，如果表空间数量非常巨大并且不适合任何限制，一旦文件不在被访问的时候这个选项可以关闭文件句柄.打开这个选项会产生不一致的备份。自己评估风险。。 - --compact
创建一份没有辅助索引的紧凑备份 - --compress
压缩所有输出数据，包括事务日志文件和元数据文件，通过指定的压缩算法，目前唯一支持的算法是quicklz.结果文件是qpress归档格式，每个xtrabackup创建的*.qp文件都可以通过qpress程序提取或者解压缩 - --compress-chunk-size=#
压缩线程工作buffer的字节大小，默认是64K - --compress-threads=#
xtrabackup进行并行数据压缩时的worker线程的数量，该选项默认值是1，并行压缩（'compress-threads'）可以和并行文件拷贝('parallel')一起使用。例如:'--parallel=4 --compress --compress-threads=2'会创建4个IO线程读取数据并通过管道传送给2个压缩线程 - --create-ib-logfile
这个选项目前还没有实现，目前创建Innodb事务日志，你还是需要prepare两次bakcup - --datadir=DIRECTORY
backup的源目录，mysql实例的数据目录。从my.cnf中读取，或者命令行指定 - --defaults-extra-file=[MY.CNF]
在global files文件之后读取，必须在命令行的第一选项位置指定 - --defaults-file=[MY.CNF]
唯一从给定文件读取默认选项，必须是个真实文件，必须在命令行第一个选项位置指定 - --defaults-group=GROUP-NAME
从配置文件读取的组，innobakcupex多个实例部署时使用 - --export
为导出的表创建必要的文件 - --extra-lsndir=DIRECTORY
(for --bakcup):在指定目录创建一份xtrabakcup_checkpoints文件的额外的备份 - --incremental-basedir=DIRECTORY
创建一份增量备份时，这个目录是增量别分的一份包含了full bakcup的Base数据集 - --incremental-dir=DIRECTORY
prepare增量备份的时候，增量备份在DIRECTORY结合full backup创建出一份新的full backup - --incremental-force-scan
创建一份增量备份时，强制扫描所有增在备份中的数据页即使完全改变的page bitmap数据可用 - --incremetal-lsn=LSN
创建增量备份的时候指定lsn。 - --innodb-log-arch-dir
指定包含归档日志的目录。只能和xtrabackup --prepare选项一起使用 - --innodb-miscellaneous
从My.cnf文件读取的一组Innodb选项。以便xtrabackup以同样的配置启动内置的Innodb。通常不需要显示指定 - --log-copy-interval=#
这个选项指定了log拷贝线程check的时间间隔（默认1秒） - --log-stream
xtrabakcup不拷贝数据文件，将事务日志内容重定向到标准输出直到--suspend-at-end文件被删除。这个选项自动开启--suspend-at-end - --no-defaults
不从任何选项文件中读取任何默认选项,必须在命令行第一个选项 - --databases=#
指定了需要备份的数据库和表 - --database-file=#
指定包含数据库和表的文件格式为databasename1.tablename1为一个元素，一个元素一行 - --parallel=#
指定备份时拷贝多个数据文件并发的进程数，默认值为1 - --prepare
xtrabackup在一份通过--backup生成的备份执行还原操作，以便准备使用 - --print-default
打印程序参数列表并退出，必须放在命令行首位 - --print-param
使xtrabackup打印参数用来将数据文件拷贝到datadir并还原它们 - --rebuild_indexes
在apply事务日志之后重建innodb辅助索引，只有和--prepare一起才生效 - --rebuild_threads=#
在紧凑备份重建辅助索引的线程数，只有和--prepare和rebuild-index一起才生效 - --stats
xtrabakcup扫描指定数据文件并打印出索引统计 - --stream=name
将所有备份文件以指定格式流向标准输出，目前支持的格式有xbstream和tar - --suspend-at-end
使xtrabackup在--target-dir目录中生成xtrabakcup_suspended文件。在拷贝数据文件之后xtrabackup不是退出而是继续拷贝日志文件并且等待知道xtrabakcup_suspended文件被删除。这项可以使xtrabackup和其他程序协同工作 - --tables=name
正则表达式匹配database.tablename。备份匹配的表 - --tables-file=name
指定文件，一个表名一行 - --target-dir=DIRECTORY
指定backup的目的地，如果目录不存在，xtrabakcup会创建。如果目录存在且为空则成功。不会覆盖已存在的文件 - --throttle=#
指定每秒操作读写对的数量 - --tmpdir=name
当使用--print-param指定的时候打印出正确的tmpdir参数，除此之外没有任何用。。 - --to-archived-lsn=LSN
指定prepare备份时apply事务日志的LSN，只能和xtarbackup --prepare选项一起用 - --user-memory = #
通过--prepare prepare备份时候分配多大内存，目的像innodb_buffer_pool_size。默认值100M如果你有足够大的内存。1-2G是推荐值，支持各种单位(1MB,1M,1GB,1G) - --version
打印xtrabackup版本并退出
xbstream
支持同时压缩和流式化。需要客服传统归档tar,cpio和其他不允许动态streaming生成的文件的限制，例如动态压缩文件，xbstream超越其他传统流式/归档格式的的优点是，并发stream多个文件并且更紧凑的数据存储（所以可以和--parallel选项选项一起使用xbstream格式进行streaming）
像tar一样使用:
* -x 选项 从标准输入stream read中提取文件到当前目录，除非指定其他-C选项
* -c 选项 stream命令行指定的文件到标准输出
目的，通过posix_fadvise()调用减少对OS page cache的影响
xtrabackup开启压缩的时候素有数据被压缩，包括事务日志和元数据文件，通过指定的压缩算法，唯一当前支持度呃算法是quicklz,结果文件是qpress归档个事。每隔xtrabakcup生成的.qp文件可以通过qpress文件归档提取或者解压缩。这就意味着不需要通过tar.gz解压缩整个bakcup来还原一个单表
文件可以通过qpress解压缩，qpress支持多线程解压缩
xtrabakcup工作原理
xtrabackup基于InnoDB crash-recovery功能，拷贝innodb数据文件，这会导致数据内部不一致，，但是之后它在文件上执行crash recovery使数据文件一致
innodb维护redo log又称事务日志。redo log日志中包含innodb数据的每次变动。当innodb启动时会去检查数据文件和事务日志，然后又两个步骤，1，apply应用已提交的事务日志到数据文件，2，已更改但未提交的事务进行undo操作
percona xtrabackup在启动的时候记录LSN，然后拷贝数据文件，这会需要一些时间，，所以如果文件改变了，它反映出不同时间点数据库的状态，。同时，xtrabakcup启动一个后台进行监控事务日志，并拷贝变动（复制修改）.xtrabakcup需要持续运行以上因为事务日志是循环写的，过段时间之后会被复用，xtrabackup需要每次数据文件变化对应的事务日志记录
上述是备份的进程，下一步是prepare的进程，在这个过程中，xtarabakcup通过已拷贝的事务日志在已拷贝的数据文件上执行crash recovery。之后，数据库已经可以进行还原并可以使用了
以上通过编译好的二进制xtrabakcup实施了。
Innobackup在此基础上增加了更多功能，比如备份Myisam表和.frm文件。它启动xtrabakcup并且等待它完成拷贝文件，之后执行FLUSH TABLES WITH READ LOCK防止mysql数据更改，得到表全局锁，然后flush所有的myisam表到磁盘，之后再释放表全局锁
备份的myisam和innodb表最终会一致，因为在prepare(recovery)之后，innodb数据会前滚到备份完成时候的时间点，而不是回滚到备份开始时候的时间点。这个时间点与FLUSH TABLES WITH READ LOCK发生时一致，所有myisam与已prepare过的Innodb数据是同步的
percona xtrabakcup是一些列如下的工具：
innobackupex:xtrabackup的符号连接，innobakcupex支持2.2版本的所有特性和语法，但是现在已经降级并且在以一个主要版本中remove
xtrabackup：编译的C程序提供备份一整个数据库实例myisam和Innodb表
xbstream：以xbstream格式streaming和提取文件