「轉」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經典算法題，帶詳細講解
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. js中 charCodeAt
- 2. Android中通過ViewHelper.setTranslationY實現View移動控制（NineOldAndroids開源項目）
- 3. 【Android】日常記錄：BottomNavigationView自定義樣式，修改點擊後圖片
- 4. maya 文件檢查 ui和數據分離 （一）
- 5. eclipse 修改項目的jdk版本
- 6. Android InputMethod設置
- 7. Simulink中Bus Selector出現很多? ? ?
- 8. 【Openfire筆記】啓動Mac版Openfire時提示「系統偏好設置錯誤」
- 9. AutoPLP在偏好標籤中的生產與應用
- 10. 數據庫關閉的四種方式