「转」xtrabackup新版详细说明
声明：本文由个人同事@fiona514编写，是我看过的最用心的中文说明介绍，强烈推荐你们学习使用。前端
Percona Xtrabackup 2.4.1mysql
编译及软件依赖ios
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.0sql
GTID支持状况数据库
测试5.6,5.7开启GTID下能够正常备份，还原centos
对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两次。一、执行flush tables with read lock先后 ；二、减小读锁被持有的时间内。由于第一调用在刷新读锁以前，因此它仅仅同步那些非事务的数据的变化)
* 针对紧凑备份和增量备份在虽然某些场景下很是有用，与刘伟商讨过暂时继续先不作计划作到统一版本中去
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两次。一、执行flush tables with read lock以前；二、减小读锁被持有的时间内。由于第一调用在刷新读锁以前，因此它仅仅同步那些非事务的数据的变化
（它不能和--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和提取文件
- 1. Percona XtraBackup 备份原理说明【转】
- 2. DBMS_XPLAN详细说明
- 3. URLConnection 详细说明
- 4. Vagrantfile详细说明
- 5. dubbo 详细说明
- 6. HBase详细说明
- 7. Request.ServerVariables详细说明
- 8. FutterMateriApp详细说明
- 9. filebeat.yml详细说明
- 10. explain 详细说明
- 更多相关文章...
- • Eclipse 窗口说明 - Eclipse 教程
- • PHP EOF(heredoc) 使用说明 - PHP教程
- • Github 简明教程
- • 为了进字节跳动，我精选了29道Java经典算法题，带详细讲解
-
每一个你不满意的现在，都有一个你没有努力的曾经。