Xtrabackup 2.4.14使用指南

lhrbest發表於2019-07-09

The innobackupex program is a symlink to the xtrabackup C program. It lets you perform point-in-time backups of InnoDB / XtraDB tables together with the schema definitions, MyISAM tables, and other portions of the server. In previous versions innobackupex was implemented as a Perl script.

This manual section explains how to use innobackupex in detail.

Warning: The innobackupex program is deprecated. Please switch to xtrabackup .

yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL //安裝依賴包
yum install cmake gcc gcc-c++ libaio libaio-devel automake autoconf bzr bison libtool ncurses-devel zlib-devel libgcrypt-devel perl-ExtUtils-MakeMaker perl-DBD-MySQL.* perl-Time-HiRes  -y 
[root@LHRDB bin]# xtrabackup2414 --version
xtrabackup2414: error while loading shared libraries: libgcrypt.so.20: cannot open shared object file: No such file or directory
[root@LHRDB bin]# yum list installed|grep libgcrypt
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
libgcrypt.x86_64                      1.4.5-11.el6_4                    @anaconda-RedHatEnterpriseLinux-201311111358.x86_64/6.5
檢視伺服器上的libgcrypt版本，發現是xtrabackup版本下載錯誤，下載對應的libgcrypt的版本的包就可以了.
percona-xtrabackup-2.4.14-Linux-x86_64.libgcrypt145.tar.gz
RHEL6.5：
tar -xvf Percona-XtraBackup-2.2.10-re623acb-el6-x86_64-bundle.tar 
yum install  perl-DBD-MySQL
rpm -ivh percona-xtrabackup-2.2.10-1.el6.x86_64.rpm
注意：XtraBackup-2.2.10不支援MySQL5.7
RHEL6.5：
tar -zxvf percona-xtrabackup-2.4.14-Linux-x86_64.libgcrypt183.tar.gz
mv percona-xtrabackup-2.4.14-Linux-x86_64 /usr/local/percona-xtrabackup-2.4.14-Linux-x86_64
ln -s /usr/local/percona-xtrabackup-2.4.14-Linux-x86_64  /usr/local/xtrabackup-2.4.14
ln -s /usr/local/percona-xtrabackup-2.4.14-Linux-x86_64/bin/innobackupex  /usr/bin/innobackupex2414
ln -s /usr/local/percona-xtrabackup-2.4.14-Linux-x86_64/bin/xtrabackup  /usr/bin/xtrabackup2414
innobackupex --version
xtrabackup --version
innobackupex --help

備份:

建庫：
create database ceshi; 
建表：
create table ceshi.users (id int primary key auto_increment,name varchar(20) not null unique,password varchar(100) not null,address varchar(200)) ENGINE=MyISAM; 
添資料：
insert into ceshi.users (id,name,password,address) values (1,'zhang','1234',null),(2,'wang','4321','湖北武漢'), (3,'li','5678','北京海淀'); 
 
建庫：
create database ceshi2;
建表：
create table ceshi2.articles (id int primary key auto_increment,content longtext not null) ENGINE=InnoDB; 
添資料：
insert into ceshi2.articles (id,content) values (11,'hahahahahaha'),(12,'xixixixixix'),(13,'aiaiaiaia'),(14,'hohoahaoaooo'); 
---完全備份恢復
innobackupex2414 --defaults-file=/etc/my.cnf --host=192.168.59.159 --user=root --password=lhr  --socket=/var/lib/mysql57/mysql5719/mysql.sock --port=3306 --target-dir=/backup/mysql5719_3306/full/ --backup
innobackupex2414 --prepare --target-dir=/backup/mysql5719_3306/full/
innobackupex2414 --copy-back --target-dir=/backup/mysql5719_3306/full/ --datadir=/var/lib/mysql57/mysql5719/data
chown -R mysql:mysql /var/lib/mysql57/mysql5719/data
--- 增量備份恢復
insert into ceshi.users (id,name,password,address) values (4,'zhang','1234',null),(5,'wang','4321','湖北武漢'), (6,'li','5678','北京海淀'); 
insert into ceshi2.articles (id,content) values (21,'hahahahahaha'),(22,'xixixixixix'),(23,'aiaiaiaia'),(24,'hohoahaoaooo'); 
--一級增量
innobackupex2414 --backup --target-dir=/backup/mysql5719_3306/inc1 --incremental-basedir=/backup/mysql5719_3306/full/
innobackupex2414 --prepare --apply-log-only --target-dir=/backup/mysql5719_3306/full/
innobackupex2414 --prepare --apply-log-only --target-dir=/backup/mysql5719_3306/full/ --incremental-dir=/backup/mysql5719_3306/inc1
innobackupex2414 --copy-back --target-dir=/backup/mysql5719_3306/full/ --datadir=/var/lib/mysql57/mysql5719/data
chown -R mysql:mysql /var/lib/mysql57/mysql5719/data
--二級增量
innobackupex2414 --backup --target-dir=/backup/mysql5719_3306/inc1 --incremental-basedir=/backup/mysql5719_3306/full/
innobackupex2414 --backup --target-dir=/backup/mysql5719_3306/inc2 --incremental-basedir=/backup/mysql5719_3306/inc1
innobackupex2414 --prepare --apply-log-only --target-dir=/backup/mysql5719_3306/full/
innobackupex2414 --prepare --apply-log-only --target-dir=/backup/mysql5719_3306/full/ --incremental-dir=/backup/mysql5719_3306/inc1
innobackupex2414 --prepare --apply-log-only --target-dir=/backup/mysql5719_3306/full/ --incremental-dir=/backup/mysql5719_3306/inc2
innobackupex2414 --copy-back --target-dir=/backup/mysql5719_3306/full/ --datadir=/var/lib/mysql57/mysql5719/data
chown -R mysql:mysql /var/lib/mysql57/mysql5719/data

Percona Xtrabackup 2.4.1

編譯及軟體依賴

centos5,6 需要升級cmake至2.8.2版本以上，解決：安裝cmake版本3.4.3測試通過

centos5 gcc g++ 需要升級gcc至4.4以上上，解決：安裝4.4.7測試通過

另外xtrabackcup另外Boost版本需要1.59.0版本或以上，目前centos5,6預設是1.41.0。解決：升級至1.59.0

GTID支援情況

測試5.6,5.7開啟GTID下可以正常備份，還原

對MySQL5.5,MySQL5.6版本支援

5.6在開啟和關閉gtid模式下都可以正常備份還原

5.5可以正常備份還原

5.6部分表匯出還原測試正常

對現有版本結合新特性的建議

目前線上版本大部分在1.6.3和1.5版本。很多需求是通過第三方工具支援。結合2.4.1的新特性和release歷史和目前情況，建議幾點如下：

* xtrabackup支援非Innodb表備份，並且Innobackupex在下一版本中移除，建議通過xtrabackup替換innobackupex

* 流式備份通過--stream指定格式為xbtream而替代tar,支援streaming格式的並行備份和壓縮

* 之前指令碼使用第三方壓縮工具pbzip2進行壓縮。建議通過--compress 和--compress-threads選項進行並行壓縮

* 指定--safe-slave-backup，增加備份的一致性。（這個選項停止SQL執行緒並且等到show status中的slave_open_temp_tables為0的時候開始備份，如果沒有開啟臨時表，bakcup會立刻開始，否則SQL執行緒啟動或者關閉知道沒有開啟的臨時表。如果slave_open_temp_tables在--safe-slave-backup-timeount（預設300秒）秒之後不為0，從庫sql執行緒會在備份完成的時候重啟）

* 指定--rsync選項，加速備份過程 (為了加速備份過程，同時減小FLUSH TBALES WITH READ LOCAK阻塞寫的時間，當該選項指定時innobackupex使用rsync拷貝所有的非InnoDB檔案替換cp。尤其適用於有大量的庫和表的時候會更快。innobackup會呼叫rsync兩次。1、執行flush tables with read lock前後；2、減少讀鎖被持有的時間內。因為第一呼叫在重新整理讀鎖之前，所以它僅僅同步那些非事務的資料的變化)

* 針對緊湊備份和增量備份在雖然某些場景下非常有用，與劉偉商討過暫時繼續先不做計劃做到統一版本中去

release歷史

2.4.1 支援MySQL5.7(5.7.10)

2.3.2 命令列語法跟隨MySQL5.6的變化而變化。另外命令列支援--datadir

2.3.1 innobackupex指令碼用c重寫，並且只是xtrabackup的符號連線。innobackupex支援2.2版本所有的特性，但是目前已降級在下個Major版本中移除，innobackupex將不支援所有新特性的語法，同時xtrabackup現在支援MyISAM的拷貝並且支援innobakcupex的所有特性。innobackupex先前特性的語法xtrabackup同樣支援

2.2.21 支援5.6（基於5.6.24版本）

2.2.8 基於5.6.22 （解決當總redo log超過4G，prepare會失敗的問題）

2.2.6 通過show variables讀取Mysql選項。在初始化表掃描的時候輸出更詳細資訊

2.2.5 基於5.6.21

2.2.1 移除xtrabackup_56 xtrabakcup_55,只保留xtrabakcup.移除Build指令碼，支援cmake編譯。基於5.6.16

2.1.6 innobackupex --force-non-empty-directories

2.1.4 MySQL versions 5.1.70, 5.5.30, 5.6.11

innobackupex --no-lock ,拷貝非Innodb資料時不停止複製執行緒，但是條件是備份期間非事務型表上不能有DDL或者DML操作

innobackupex --decrypt and innobackupex --decompress,

2.1.1 支援緊湊備份，加密備份。不在支援5.0內建Innodb和5.1內建Innoddb。移除--remote-host選項

2.1.0 支援mysql5.6的所有特性（GTID, 可移動表空間，獨立undo表空間，5.6樣式的buffer pool匯出檔案）

支援5.6引入的innodb buffer pool預載。buffer pool dumps可以生成或者匯入加速啟動。在備份時buffer pool dump拷貝到備份目錄，在還原階段拷貝回data目錄，

--log-copy-interval 可配置log拷貝執行緒檢查的間隔時間

如果開啟gtid，xtrabackup_binlog_info儲存gtid的值

支援xtrabackup --export，這個選項生成5.6樣式的後設資料檔案。可以通過alter table import tablespace匯入

2.0.5 --defaults-extra-file 存備份使用者的使用者名稱和密碼的配置檔案

2.0.3 支援--move-back

1.9.1 支援壓縮備份，之前能能streaming備份之後通過外部工具壓縮

支援streaming增量備份

LRU DUMP

1.6.4 innobackupex支援--rsync選項在datadir目錄進行兩階段rsync（首先沒有寫鎖，之後有寫鎖，）減少寫鎖持有的時間

感興趣的可以往後看。。。。。。

————————————————————————————————————————————————————————————————————————————————————————————————————

xtrabackup主要功能測試

innobackupex

建立本地Full Backup(建立，prepare，還原)

之後隱去--defaults-file=/data1/mysql5711/my5711.cnf.bakuse --no-timestamp --slave-info --socket=/tmp/mysql5711.sock --user=mysqlha --password=xxx 等選項

建立一份備份

innobackupex /data1/dbatemp/5711back

160321 10:56:00 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.

At the end of a successful backup run innobackupex

prints "completed OK!" .

160321 10 : 56 : 00 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;port=5711;mysql_socket=/tmp/mysql5711.sock' as 'mysqlha' ( using password : YES).

160321 10 : 56 : 00 version_check Connected to MySQL server

160321 10 : 56 : 00 version_check Executing a version check against the server ...

160321 10 : 56 : 00 version_check Done.

160321 10 : 56 : 00 Connecting to MySQL server host: localhost, user : mysqlha, password : set , port: 5711 , socket: /tmp/mysql5711.sock

Using server version 5.7.11 - log

/usr/ local /xtrabackup/ bin /innobackupex version 2.4.1 based on MySQL server 5.7.10 Linux (x86_64) (revision id : a2dc9d4)

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /data1/mysql5711

xtrabackup: open files limit requested , set to 204800

xtrabackup: using the following InnoDB configuration:

xtrabackup: innodb_data_home_dir = .

xtrabackup: innodb_data_file_path = ibdata1: 100 M : 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

160321 10 : 56 : 01 [ 01 ] Copying ./ibdata1 to /data1/dbatemp/ 5711 back/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/ 5711 back/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/ 5711 back/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/ 5711 back/abc/object_info.ibd

160321 10 : 56 : 02 [ 01 ] ...done

160321 10 : 56 : 02 [ 01 ] Copying ./mysql/time_zone_transition.ibd to /data1/dbatemp/ 5711 back/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/ 5711 back/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/ 5711 back/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/ 5711 back/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/ 5711 back/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/ 5711 back/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/ 5711 back/mysql/time_zone_transition_type.frm

160321 10 : 56 : 04 [ 01 ] ...done

160321 10 : 56 : 04 [ 01 ] Copying ./mysql/func.MYD to /data1/dbatemp/ 5711 back/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/ 5711 back/ 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/ 5711 back/ 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/ 5711 back/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: 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: 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: Starting shutdown...

InnoDB: Shutdown completed; log sequence number 4151336

160321 11:04:32 completed OK!

### 還原全備:

innobackupex --defaults-file=/ data 1/mysql5711_bak/my5711.cnf.bakuse --copy-back / data 1/dbatemp/ 5711 back/

/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= 1 G

/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: 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: 100 M: 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

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: 100 M: 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 = 1 G, instances = 1 , chunk size = 128 M

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 ( %)

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/

其他連線選項

Option	Description
--port	通過TCP/IP連線資料庫的埠號
--socket	本地連線sockect
--host	通過TCP/IP連線的資料庫的IP

許可和許可權
連線資料庫之後，需要server檔案系統層面datadir目錄的讀寫和執行許可權
至於資料庫層面，需要如下許可權:
1,RELOAD和LOCK TABLES許可權
需要在拷貝檔案之前FLUSH TABLES WITH READLOCKS和FLUSH ENGINE LOGS。另外當開啟Backup Locks,執行LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP需要這兩樣許可權
2，REPLICATION CLIENT許可權獲得binlog的點位
3，CREATE TABLESPACE許可權目的是為了匯入tables
4，PROCESS許可權 show processlist
5, SUPER許可權複製環境下start slave 和stop slave
6，CREATE許可權目的是建立PERCONA_SECHEMA.xtrabackup_history資料庫和表
7，INSERT許可權在PERCONA_SCHEAM.xtrabackup_history表中增加歷史記錄
8，SELECT許可權使用innobackupex --incremental-history-name 或者innobackupex --incremental-history-uuid目的是為了查詢PERCONA_SCHEMA.xtrabackup表中innodb_tolsn的值
建立一個能夠full backup最小許可權的資料庫使用者:
mysql> CREATE USER 'bkpuser' @ 'localhost' IDENTIFIED BY 's3cret' ;
mysql> GRANT RELOAD,LOCK TABLES,REPLICATION CLIENT ON *.* TO 'bkpuser' @ 'localhost' ;
mysql> FLUSH PRIVILEGES;
全量備份生命週期-FULL Backups
通過Innobackupex建立一個備份

innobackupex是一個通過xtrabackup結合了xbstream和xbcrypt等來備份一整個資料庫例項的工具

蔣健一個完整備份，除了連線資料庫的選項還只需要一個引數，備份儲存目錄的路徑

$ innobackupex --user=DBUSER --password=DBUSERPASS /path/ to /BACKUP-DIR/

之後檢查確認資訊輸出的最後一行:

innobackupex: Backup created in directory ’/path/to/BACKUP-DIR/ 2013 - 03 - 25 _00- 00 - 09 ’

innobackupex: MySQL binlog position: filename ’mysql-bin .000003 ’, position 1946

111225 00 : 00 : 53 innobackupex: completed OK!

備份會最終儲存在以時間戳命名的目錄內

在底層，在後臺，innobackupex被稱作二進位制xtrabackup來備份Innodb所有表的資料並且拷貝所有的frm表定義檔案，資料，和MyISAM,MERGE,CSV表相關的檔案，觸發器，資料庫配置檔案到一個時間戳的目錄中去

其他需要考慮的選項

--no-timestamp：告訴innobackupex不要建立一個時間戳目錄來儲存備份

--defaults-file：可以提供innobackupex其他的資料庫配置檔案。唯一的限制就是必須放在第一個引數的位置

innobackupex -- defaults - file=/tmp/other - my . cnf -- user=XXX -- password=XXX /path/to/backup

PREPARE階段，用innobackupex prepare Full Backup

在建立了一個backup之後，資料還不能用於還原，因為有未提交的事務未完成或者事務日誌需要重放，做這些待定的操作需要資料檔案一致.這些都是prepare階段的目的，一旦這些完成，資料就可以用了

需要指定選項apply-log：

innobakupex --apply- log /path/to/BACKUP- DIR

如果成功了，innobackupex操作之後，資料是立刻可用的

在後臺，innobackupex通過讀取backup-my.cnf開始prepare程式，在之後，innobackupe重放已提交的事務並回滾未提交的事務，一旦這些操作完成，所有資訊在表空間中(innodb檔案)，Log檔案被重建.這些說明了呼叫xtrabackup --prepare兩次。

注意這個preparation不適合增量備份，如果基於增量備份，將無法'add'增量部分

通過Innobackupex還原Full Backup

--copy-back選項，在server的datadir目錄執行一份備份的還原

innobakupex -- copy -back / path /to/BACKUP- DIR

--copy-back:做資料恢復時將備份資料檔案拷貝到MySQL伺服器的datadir

會跟具體my.cnf檔案裡的配置，拷貝所有資料相關的檔案到datadir。

注意：

1.datadir目錄必須為空。除非指定innobackupex --force-non-empty-directorires選項指定，否則--copy-backup選項不會覆蓋

2.在restore之前,必須shutdown MySQL例項，你不能將一個執行中的例項restore到datadir目錄中

3.由於檔案屬性會被保留，大部分情況下你需要在啟動例項之前將檔案的屬主改為mysql，這些檔案將屬於建立備份的使用者

chown -R my5711:mysql /data1/dbrestore

以上需要在使用者呼叫Innobackupex之前完成

其他型別備份

通過Innobackupex進行增量備份

在每個備份之間並不是所有的資訊都有變化，增量備份的目的是減少需要的儲存容量和建立一份備份的時間

這些可以完成是因為每個InnoDB的頁都有一個LSN，這個LSN相當於一整個資料庫的版本號碼，每次資料庫更改，這個Number就會遞增

增量備份就是拷貝某一個指定LSN開始的所有page

一旦這些pages以他們各自的順序被放到一起，應用這些日誌將重新建立影響資料庫的程式，在建立backup時刻產生資料

通過innobakupex建立一份增量備份

首先，建立一份全量備份作為基礎用於之後的增量備份

innobackupex /data1/ dbbackup

將會在/data1/dbbackup目錄生成一個帶有時間戳的目錄，比如假裝置份是在上個月月底最後一天建立.BASEDIR是/data1/dbbackup/2016-02-29_23-01-18

可以通過innobackupex --no-timestamp選項覆蓋這種行為，備份將會被建立在指定的目錄中

如果檢查BASE-DIR目錄中的xtrabackup-checkpoints檔案，你能看到如下：

backup_type = full-backuped

from_lsn = 0

to_lsn = 1291135

第二天建立一份增量備份,通過--incremental選項並提供BASEDIR:

innobackupex -- incremental /data1/backups -- incremental - basedir=BASEDIR

會在/data1/backups目錄裡生成另一份帶有時間戳的目錄，就是/data1/backups/2016-03-01_23-01-18,該目錄包含了增量備份，我們稱之為INCREMENTAL-DIR-1,如果檢查該目錄的xtrabackup-checkpoints檔案。會看到如下:

backup_type = incremental

from_len = 1291135

to_lsn = 1352113

類似的，第三天建立另一份增量備份。但是第二天的增量備份變成了BASEDIR

innobackupex --incremental / data / backups --incremental- basedir=INCRENMENTAL-DIR-1

結果生成/data1/backups/2016-03-02_23-01-18，用INCREMENTAL-DIR-2來表示:

backup_type = incremental

from_lsn = 1352113

to_lsn = 1358967

像我們之前所說，增量備份只拷貝LSN大於一個指定值的pages，提供LSN會產生相同資料的目錄：

innobackupex -- incremental /data/backups -- incremental - lsn=1291135

innobackupex -- incremental /data/bakcups -- incremental - lsn=1358967

因為全備或上一個增備並不是總在系統中（如備份後傳輸到遠端）,用這種方法做增量備份非常有用。這種過程只能影響XtraDB和InnoDB表，其他引擎的表如MyISAM.在做增量備份的過程中時候會拷貝全部。

通過innobakupex prepare一份增量備份

prepare增量備份與全量備份不同。這裡需要額外注意：

首先只有提交過的事務需要在每份備份中個重放 (apply-log BASEDIR)
這些將增量的部分合併到全量備份的base中去()
然後，未提交的事務必須回滾，為了有一個隨時可用的備份

如果在基於base backup中重放提交事務回滾未提交事務，是不能add增量的。如果對於增量的這樣做，是不能add從那刻起的資料和其餘的增量。

--redo-only --apply-log:

強制備份日誌時只redo ,跳過rollback。這在做增量備份時非常必要

innobackupex --apply- log -- redo - only BASE-DIR

然後，第一個增量Backup能apply給base backup:

innobackupex --apply- log --redo-only BASE- DIR --incremental- dir =INCRENMENTAL- DIR -1

如果沒有--incremental-dir被設定了，innobackupex會選擇在basedir裡最近建立的一個子目錄

此時，BASE-DIR包含了一直到第一次增量備份的資料，注意全備永遠都在base backup目錄裡

然後在第二個增量備份上重複這個過程:

innobackupex --apply- log BASE- DIR --incremental- dir =INCREMENTAL- DIR -2

如果出現'complete ok'，最終的資料會都merge到base backup目錄中去（BASE-DIR）

注意：--redo-only用於merging所有的增量除了最後一個

你可以通過以上的過程給base增加更多的增量，只要按照備份的完成的時間順序依次即可。如果用錯誤的順序Merge增量，備份就完全無用了。如果對apply的順序有疑問，可以檢查每個目錄的xtrabackup_checkpoints檔案

一旦你對base backup目錄merge完所有的增量，接下來prepare，回滾未提交的事務:

innobackupex --apply- log BASE- DIR (innobackupex回滾未提交的事務)

此時的backup可以立刻用於還原了，此步preparation是可選的，然和，如果你還原沒有這步，database server會開始rollback未提交的事務。如果發生crash時，database server會做同樣的工作。這會延遲db server的啟動時間，如果此步prepare則會避免

注意innobacupex不會建立iblog*這些檔案，如果想要建立，用xtrabackup -prepare作用於該目錄，否則，這些檔案在server啟動的時候被建立

通過innobackupex還原增量備份

preparing增量備份之後，base dir就是一個full backup,還原方式:

innobackupex -- copy -back BASE- DIR

通過xbstream和tar進行增量流式備份

使用xbstream streaming選項，備份可以被打包成自定義的xbstream格式，同樣需要一個Base backup

innobakcupex / data /bakcups

本地備份：

innobackupex -- incremental -- incremental - lsn=LSN - number -- stream=xbstream . / > incremental . xbstream

解壓備份:

xbstream -x < incremental.xbstream

做一份本地備份並streaming到遠端伺服器然後解壓:

innobackupex --incremental --incremental-lsn=LSN-number --stream=xbstream . / | /

ssh user@hostname " cat - | xbstream -x -C > /backup-dir/"

--stream=[tar]

備份檔案輸出格式, tar時使用tar4ibd , 該檔案可在XtarBackup binary檔案中獲得.如果備份時有指定--stream=tar, 則tar4ibd檔案所處目錄一定要在$PATH中(因為使用的是tar4ibd去壓縮, 在XtraBackup的binary包中可獲得該檔案)。

在使用引數stream=tar備份的時候，你的xtrabackup_logfile可能會臨時放在/tmp目錄下，如果你備份的時候併發寫入較大的話 xtrabackup_logfile可能會很大(5G+)，很可能會撐滿你的/tmp目錄，可以通過引數--tmpdir指定目錄來解決這個問題

部分備份

只備份部分的表或者db，前提是開啟innodb_file_per_table選項，每張表有獨立的表空間。你不能通過簡單地將prepared的部分備份使用--copy-back選項直接複製回資料目錄，而是要通過匯入表的方向來實現還原。當然，有些情況下，部分備份也可以直接通過--copy-back進行還原，但這種方式還原而來的資料多數會產生資料不一致的問題，因此，無論如何不推薦使用這種方式。

建立部分備份

有三種方法指定備份那部分資料

--include選項使用正規表示式方式時，要求為其指定匹配要備份的表的完整名稱，即databasename.tablename

innobackupex --include= '^mydatabase[.]mytable' /path/ to/backup

上面的指令只備份表名相匹配的資料。--include選項傳遞給xtrabackup --tables，對每個庫中的每個表逐一匹配，因此會建立所有的庫，不過是空的目錄。

--tables-file選項此選項的引數需要是一個檔名，此檔案中每行包含一個要備份的表的完整名稱，格式為databasename.tablename。

echo "mydatabase.mytable" > /tmp/tables.txt

innobackupex --tables-file=/tmp/tables.txt /path/to/backup

該選項傳遞給xtrabackup --tables-file，與--table選項不同，只有要備份的表的庫才會被建立

--databases選項此選項接受的引數為資料名，如果要指定多個資料庫，彼此間需要以空格隔開；同時，在指定某資料庫時，也可以只指定其中的某張表。此外，此選項也可以接受一個檔案為引數，檔案中每一行為一個要備份的物件

innobackupex --databases= "mydatabase.mytable mysql" /path/ to/backup

該選項對innodb引擎表無效，還是會備份的

prepare部分備份

prepare部分備份的過程類似於匯出表的過程，要使用--export選項進行：

innobackupex --apply-log --export /path/to/partial/backup

此命令執行過程中，innobackupex會呼叫xtrabackup命令從資料字典中移除缺失的表，因此，會顯示出許多關於“表不存在”類的警告資訊。同時，也會顯示出為備份檔案中存在的表建立.exp檔案的相關資訊。

還原部分備份

還原部分備份的過程跟匯入表的過程相同。當然，也可以通過直接複製prepared狀態的備份直接至資料目錄中實現還原，不要此時要求資料目錄處於一致狀態。

壓縮備份

備份innodb表的時候可能會忽略輔助索引，會使備份更緊湊並且節約磁碟空間。缺點是輔助索引重建導致backup prepare的過程會需要更長的時間。備份大小區別取決於輔助索引大小的區別。。例如沒有加--compat選項的full backup.

注意：壓縮備份不支援系統表空間，，所以需要開啟innodb-file-per-table選項

建立壓縮備份

innobackupex --compact /data/backups

會在/data/backups目錄下建立個時間戳目錄

如果檢查BASE-DIR裡面的xtrabackup_checkpoints檔案，能看到如下:

backup_type = full-backuped
from_lsn = 0
to_lsn = 2888984349
last_lsn = 2888984349
compact = 1

沒有--compact選項compact的值為0，這種方法方便的檢查備份是否包含輔助索引

preparing壓縮備份

preparing壓縮備份需要重建索引，prepare backup需要--rebuild-index跟隨--apply-logs

innobackupex --apply-log --rebuild-indexes /data/backups/2016-03-14_10-29-48

命令輸出，除了標準innobackupex輸出，還包含了索引重建的資訊

還原壓縮備份

innnobackupex有一個--copy-back選項。作用是講一份backup還原到server的datadir目錄中去

innobackupex --copy-back /path/to/backup-dir

會將所有資料相關的所有檔案拷貝到datadir目錄，由my.cnf配置檔案定義

加密備份

2.1版本引入，加密或者解密本地備份或者由xbstream選項備份的流式備份，加密由libgcrypt庫實現

建立加密備份

加密需要指定以下選項（--encrypt-key和--encrypt-key-file只需指定其中之一即可）

--encryption=ALGORITHM 目前支援的演算法有ASE128,AES192,AES256
--encrypt-key=ENCRYPTION_KEY 使用合適長度加密key，因為會記錄到命令列，所以不推薦使用
--encrypt-key-file=KEYFILE 檔案必須是一個簡單二進位制或者文字檔案加密key可通過以下命令列命令生成,生成的值可用於Key openssl rand -base64 24

--encrypt-key選項使用栗子:

innobackupex --encrypt=AES256 --encrypt-key="GCHFLrDFVx6UAsRb88uLVbAVWbK+Yzfs" /data/backups

優化加密過程

引入兩個新的選項加速加密過程，--encrypt-threads和--encrypt-chunk-size

--encrypt-threads選項並行加密,--encrypt-chunk-size指定每個加密執行緒buffer的大小（位元組，預設64K）

解密加密備份

可通過xbcrypt二進位制解密，以下一行解密所有目錄:

for i in ‘find . -iname "*\.xbcrypt"‘; do xbcrypt -d --encrypt-key-file=/root/secret_key --encrypt-

prepare加密備份

在備份解密之後，可以通過full backup一樣的方式通過--apply-logs prepare

innobackupex --apply-log /data/backups/2016-03-14_08-31-35/

注意，xtrabackup不會自動移除加密檔案，為了清理Backup目錄，需要使用者手動rm *.xbcrypt檔案

還原加密備份

--copy-back選項，通過拷貝檔案到datadir目錄還原備份

innobackupex --copy-back /path/to/BACKUP-DIR

高階特性

流式和壓縮備份

streaming模式，傳送backup以tar或者xbstream格式到標準輸出，取代拷貝檔案到backup目錄，這樣允許你使用其他程式過濾bakcup的輸出提供更靈活的備份，比如，通過管道將backup的輸出壓縮工具進行壓縮，流式備份其中的一項好處是是通過unix管道備份可以自動加密

使用streaming特性，需要使用--stream選項並提供stream的格式（tar或者stream），和在哪裡存臨時檔案

innobackpex --stream=tar /tmp

innobackup以--log-stream模式在子程式中啟動xtrabackup,並且重定向日誌到臨時檔案，之後使用xbstream以特殊的xbstream格式將所有資料檔案stream到標準輸出。

開啟壓縮時，xtrabakup以指定的壓縮演算法，壓縮所有資料，除了後設資料和非innodb檔案等不被壓縮檔案，目前演算法只支援quicklz。結果檔案為qpress歸檔檔案

使用xbstream作為stream選項，備份可以並行拷貝和壓縮，大大的加速了備份過程，以防止備份同時壓縮和加密。需要首先先解密之後再解壓縮

使用xbstream栗子

儲存完整備份到單一檔案

innobackupex --stream=xbstream /root/backup/ > /root/backup/backup.xbtream

stream並且壓縮這個備份:

innobackupex --stream=xbstream --compress /root/backup/ > /root/backup/backup.xbstream

解包到/root/backup/目錄:

xbstream -x < backup.xbstream -C /root/backup/

將壓縮backup傳送到其他host並解壓縮:

innobackupex --compress --stream=xbstream /root/ backup / | ssh user@otherhost "xbstream -x -C / root/

使用tar的栗子

將完整的backup存到一個tar歸檔

innobackupex --stream=tar /root/backup/ > /root/backup/out.tar

將tar歸檔傳送到其他host

innobackupex --stream=tar ./ | ssh user@destination \ "cat - > /data/backups/backup.tar"

注意提取percona xtrabackup歸檔需要指定-i選項

tar -xizf backup.tar.gz

可指定喜歡的壓縮工具:

innobackupex --stream=tar ./ | gzip - > backup.tar.gz
innobackupex --stream=tar ./ | bzip2 - > backup.tar.bz2

需要注意的是，流式備份需要在還原之前Prepare，流模式不需要prepare

複製環境中備份

從庫備份需要指定以下選項:

--slave-info選項
從庫備份，它會列印binlog的點位，還有主庫的名字，同樣會將這些資訊座位change master語句寫入xtrabckup_slave_info檔案
使用場景，可以通過以此備份搭建一個建立這個主庫的從庫。
--safe-slave-backup
為保證一致性複製狀態，這個選項停止SQL執行緒並且等到show status中的slave_open_temp_tables為0的時候開始備份，如果沒有開啟臨時表，bakcup會立刻開始，否則SQL執行緒啟動或者關閉知道沒有開啟的臨時表。如果slave_open_temp_tables在--safe-slave-backup-timeount（預設300秒）秒之後不為0，從庫sql執行緒會在備份完成的時候重啟
強烈推薦

加速備份過程

通過--parallel拷貝和-compress-threads加速當進行本地備份或者通過xbstream選項流式備份時，可以通過--parallel選項多個檔案併發拷貝，這個選項指定xtrabackup建立生成的執行緒數來拷貝資料檔案前提需要開啟innodb_file_per_table和共享表空間存在多個ibdata檔案中，此特性實施級別為檔案級別，在高碎片化的資料檔案做併發檔案轉換會增加IO負載，因為極大的隨機讀請求重疊，你可以考慮對檔案系統調優以獲得最大的效能如果資料存到單一檔案中，這個選項沒有任何影響。使用方法: 本地： innobackupex --parallel=4 /path/to/backup 如果使用xbstream在流式備份中可以通過--compress-threads選項加速壓縮過程。這個選項指定了由並行資料壓縮中xtrabackup建立的執行緒數，預設值為1 使用這個特性，只需加上該選項 innobackupex --stream=xbstream --compress --compress-threads=4 ./ > backup.xbstream

在applying log之前，壓縮檔案需要被解壓縮

通過--rsync選項加速

為了加速備份過程，同時減小FLUSH TBALES WITH READ LOCAK阻塞寫的時間，當該選項指定時，innobackupex使用rsync拷貝所有的非InnoDB檔案替換cp。尤其適用於有大量的庫和表的時候會更快。innobackup會呼叫rsync兩次。1、執行flush tables with read lock之前；2、減少讀鎖被持有的時間內。因為第一呼叫在重新整理讀鎖之前，所以它僅僅同步那些非事務的資料的變化

（它不能和--remote-host、--stream一起使用）

節流（Throttling）備份

雖然innobackupex不會阻塞任何資料庫的操作，但是備份這個過程會給系統增加Load,如果系統沒有更多的IO能力，那麼可以限制innoabckupex讀寫Innodb資料的頻率,通過--throttle選項控制

該選項直接傳給xtrabackup二進位制程式，並僅限制了innodb表的日誌和檔案操作的

iostat命令可以檢查系統上IO操作，

注意innobackup --throttle選項只在備份階段工作，innobackupex --apply-log and innobackupex --copy-back並不工作

--throttle選項很像mysqlbackup中的--sleep選項

還原單表

早於5.6b版本，是不可能在server中間拷貝檔案來拷貝表。然而通過Xtrabackup，你可以任何innodb資料庫中間匯出單個表，並且把它們匯入到MySQL5.6中（source不一定是MySQL5.6,但是destination必須是），並且只對獨立ibd檔案有效

匯出表

exporting不是在建立backup的時候，而是在prepare階段完成，一旦full backup建好，用--export選項prepare它

innobackupex --apply-log --export /path/to/backup

會為每個有獨立表空間的Innodb建立一個.exp擴充套件的檔案。

舉個例子：

find /data/backups/mysql/ -name export_test.*
/data/backups/mysql/test/export_test.exp
/data/backups/mysql/test/export_test.ibd
/data/backups/mysql/test/export_test.cfg

有三個檔案需要匯入線上5.6的表中

MySQL通過dump成一種特別格式的的Innodb字典的.cfg檔案，這種格式不同於.exp。嚴格來說，.cfg檔案不需要匯入mysql5.6表空間。表空間即使從不同的server上也會匯入成功。如果相關的.cfg檔案在同樣的目錄中，innodb會做schema驗證

每個.exp(或者.cfg)用來匯入表

注意：innodb 慢停例項（full purge+change buffer merge）通過on --export,否則表空間會不一致並且不會被匯入。所有常見的效能問題會被考慮：足夠的buffer pool(例如--use-memory,預設100M)和足夠的儲存，否則將會耗費很久完成匯出

匯入表

將一張表匯入到其他伺服器上，首先以同樣的表結構建立一張新表用於匯入：

OTHERSERVER|mysql> CREATE TABLE mytable (...) ENGINE=InnoDB;

然後丟棄表空間:

OTHERSERVER|mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

然後，拷貝mytable.ibd和mytable.exp(如果匯入到5.6則是mytable.cfg)到資料庫家目錄，然後匯入表空間:

OTHERSERVER|mysql> ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

一旦執行完成。匯入表的書庫是立刻可用的

基於時間點恢復

通過innobackupex和二進位制日誌可恢復指定時間點的資料

注意二進位制日誌包含從過去的一個時間點開始資料庫的改變操作，你需要一個full datadir作為base，然後可以從二進位制日誌中apply一系列的操作使資料匹配你想要的那個時間點的操作

做一份snapshot，我們可以通過innobackupex做一份全備full backup

innobackupex /path/to/backup --no-timestamp

出於方便使用--no-timestamp選項。之後我們開始prepare，為了之後做好還原的準備

innobackupex --apply-log /path/to/bakcup

現在，假設過去了一段時間，你希望還原資料庫到過去的某個特定點，想下製作快照時點的限制

想要找出二進位制日誌情況，執行show binary logs和show master status

然後找出快照生成時候的pos點。找到backup目錄下的xtrabackup_binlog_info

cat /path/to/backup/xtrabackup_binlog_info
mysql-bin.000003 57

這會告訴備份的時間點的binlog日誌及Pos點，這個pos點在還原備份時候非常有效

innobackupex --copy-back /path/to/backup

下一步就是從二進位制日誌中用mysqlbinlog從快照的pos點開始提前查詢語句並重定向到一個檔案中

mysqlbinlog /path/to/datadir/mysql-bin.000003 /path/to/datadir/mysql-bin.000004 --start-position=57 > mybinlog.sql

注意如果有多個binlog，需要列出所有

時刻觀察來決定哪個POS點或者時間點是你要還原的那個點。一旦決定好了。管道傳向server，假設時間點是11-12-25 01：00：00:

mysqlbinlog /path/to/datadir/mysql-bin.000003 /path/to/datadir/mysql-bin.000004 \
--start-position=57 --stop-datetime="11-12-25 01:00:00" | mysql -u root -p

提升FLUSH TABLES WITH READ LOCKING handling

備份時，FLUSH TABLES WITH READ LOCK會在備份非innodb檔案之前使用來保證備份的一致性，FLUSH TABLES WITH READ LOCK甚至有查詢執行了幾個小時的時候仍可以執行，這種情況下，任何都會鎖在Waiting for table flush or Waiting for master to send event這兩種狀態下，kill掉也不解決任何問題。只有kill掉導致FLUSH鎖住的慢查才能讓server重新正常執行。這就意味著如果長時間執行的查詢時，FLUSH TABLES WITH READ LOCK會被卡住，

注意，上述情況在backup locks是無效的，Percona Server 5.6+中特性，XtraBackup會自動拷貝非Innodb資料避免阻塞修改InnoDB表的DML查詢

兩件事可以避免上述問題：

innobackupex 等待好時機

innobackupex 可以Kill阻止獲得全域性鎖的查詢（所有或者僅select查詢）

等待查詢完成

獲取全域性鎖的好時機是指所有長查詢都執行完畢，為防止innobackupex等待執行LUSH太長時間。新選項被引入:

innobakcupex --ftwrl-wait-timeout選項，限制等待時間，一旦超時就會報錯退出。預設值為0，關閉此特性

另一個是設定等待查詢的型別，innobackupex --ftwrl-sait-query-type，可選址為all和update,設定為all時，innobackupex會在執行FLUSH TABLES WITH READ LOCK之前等待所有長時查詢完成（執行時間超過innobackupex--ftwrl-wait-threshold），當值為update時會等待UPDATE/ALTER/REPLACE/INSERT查詢完成

--lock-wait-threshold用來定義 --locl-wait-query-type中的長執行查詢，如果超過--lock-wait-threshold都算長執行查詢。

kill掉阻塞查詢

可以通過指定--kill-long-queries-timeout用來指定執行FLUSH TABLES WITH READ LOCK後還可以執行的時間，0為不kill，--kill-long-query-type用來指定超時之後，kill的查詢型別，可以是all或者select

innobackupex --lock-wait-threshold=40 --lock-wait-query-type=all --lock-wait-timeout=180 --kill-long-queries-timeout=20 --kill-long-query-type=all /data/backups/

innobacupex花費不超過3分鐘時間等待超過40秒的查詢完成，FLUSH之後，innobackupex會等待20秒時間獲取全域性鎖，如果超過20秒仍然沒有獲得，會kill所有的執行時間超過FLUSH命令的查詢

innobackupex是如何工作的

2.3起innobackupex用c重寫並且作為xtrabackup的符號連線，innobackupex支援2.2版本的所有特性和語法。但是現在已降級並且在下一個major版本中將被移除，。新的特性語法將加在xtrabakup中，而不是innobackupex中

making a backup

如果沒有模式指定，innobakucpex預設為backup模式

預設的，innobackupex通過--suspend-at-end選項啟動xtrabackup,並且讓它拷貝innodb資料檔案，當xtrabackup完成，innobackupex看著它建立xtarbackup_suspended_2檔案並且執行FLUSH TABLES WITH READ LOCK.

innoabackupex之後檢查MySQL變數來決定server支援哪些特性，特別是backup locks,change page bitmaps,GTID mode等等，如果一切順利，二進位制作為一個子程式啟動

innobackupex在設定--safe-slave-backup選項後等待同步，並且flush所有表with read lock.阻止所有myisam表寫入(除非指定--mo-lock)。

一旦完成，開始備份所有非Innodb檔案，.frm,.MRG,.MYD,.MYI,.CSV,.OPT檔案等等

當所有檔案備份後，執行ibbackup並且等待直到完成備份完成拷貝事務完成。之後，表被解鎖，開啟同步（如果指定--safe-slave-backup）並且與server的連線關閉。之後，移除xtrabackup_suspended_2檔案並允許xtrabackup退出

同時在備份的目錄建立如下檔案:

xtrabackcup_checkpoints 包含備份型別和LSN

xtrabackcup_binlog_info 包含開啟備份時刻的binlog和POS

xtrabackcup_binlog_pos_innodb 包含開始備份InnoDB事務相關的binlog的POS

xtrabackup_slave_info 包含master的binlog和POS（需指定--slave-info）

backup-my.cnf 備份需要的my.cnf中的選項

xtrabackup_binary 包含backup需要的二進位制檔案

mysql-stderr

mysql-stdout

最終binlog pos列印在標準錯誤輸出並且Innobackupex退出碼為0退出

通過備份還原

還原備份通過--copy-back選項

innobackupex讀取my.cnf中的變數並檢查相關目錄是否存在

之後拷貝MyISAM表，索引等等。首先是innodb表其次索引，最後是log檔案。拷貝時保留檔案屬性。

作為替換，--move-back選項用來還原備份。這個選項與--copy-back相似。唯一的區別是它不拷貝檔案，而是移動檔案到目的地。這個選項移除backup檔案，用時候必須小心。使用場景：沒有足夠的磁碟空間同事保留資料檔案和Backup副本

innobackupex 命令列選項

選項

--apply-log
通過apply名叫xtrabackup_logfile的事務日誌來在BACKUP-DIR目錄中Prepare一個backup，同樣，建立新的事務日誌。innodb配置從生成bakcup過程中innobakcupex建立的backup-my.cnf檔案讀取，innobackupex --apply-log 預設使用bakcup-my.cnf中的innodb配置.這裡說的Innodb配置指的是影響資料格式的系統變數，例如：innodb_page_size,innodb_log_block_size等等，本地相關變數例如innodb_log_group_home_dir或者innodb_data_file_path.
一般情況下，在備份完成後，資料尚且不能用於恢復操作，因為備份的資料中可能會包含尚未提交的事務或已經提交但尚未同步至資料檔案中的事務。因此，此時資料檔案仍處理不一致狀態。“準備”的主要作用正是通過回滾未提交的事務及同步已經提交的事務至資料檔案也使得資料檔案處於一致性狀態。
對xtrabackup的--prepare引數的封裝
--backup-locks
僅支援percona server5.6，如果server不支援，開啟不讀私人和產生影響
--close-files
2.2.5引入的新特性
關閉不再訪問的檔案控制程式碼，這個選項直接傳遞給xtrabackup,當xtrabackup開啟表空間通常並不關閉檔案控制程式碼目的是正確的處理DDL操作。如果表空間數量巨大，這是一種可以關閉不再訪問的檔案控制程式碼的方法。使用該選項有風險，會有產生不一致備份的可能
--compact
建立一份沒有輔助索引的緊湊的備份，該選項直接傳遞給xtrabackup
--compress
該選項指導xtrabackup壓縮innodb資料檔案的backup的拷貝，直接傳遞給xtrabackup的子程式
--compress-threads = #
該選項指定並行壓縮的worker執行緒的數量，直接傳遞給xtrabackup的子程式
--compress-chunk-size = #
這個選項指定每個壓縮執行緒的內部worker buffer的大小。單位是位元組，預設是64K。直接傳遞給xtrabackup子程式
--copy-back
執行還原操作，從備份目錄中最近的一份備份中拷貝所有檔案到datadir,innobackupex --copy-back選項除非指定innobackupex --force-non-empty-directories選項，否則不會拷貝覆蓋所有的檔案
--databases=LIST
指定innoabckupex備份的DB列表，該選項接受一個一個字串引數或者包含DB列表的檔案的全路徑。如果沒有指定該選項，所有包含innodb和myam表的DB會被備份，請確認--databases包含所有的innodb資料庫和表，，以便所有的innodb.frm檔案也同樣備份，如果列表非常長的話。可以以檔案代替
--decompress
解壓所有值錢通過--compress選項壓縮成的.qp檔案。innodbakcupex --parallel選項允許多個檔案同時解壓。為了解壓，qpress工具必須有安裝並且訪問這個檔案的許可權。這個程式將在同一個位置移除原來的壓縮/加密檔案
--decrypt=ENCRYPTION-ALGORITHM
解密所有之前通過--encrypt選項加密的.xbcrypt檔案。--innobackup --parallel選項允許同時多個檔案解密
--defaults-file=[MY.CNF]
該選項指定了從哪個檔案讀取MySQL配置，必須放在命令列第一個選項的位置
--defaults-extra-file=[MY.CNF]
指定了在標準defaults-file之前從哪個額外的檔案讀取MySQL配置，必須在命令列的第一個選項的位置
--default-group=GROUP-NAME
這個選項接受了一個字串引數指定讀取配置檔案的group,在一機多例項的時候需要指定
--encrypt=ENCRYPTION_ALGORITHM
該選項指定了xtrabackup通過ENCRYPTION_ALGORITHM的演算法加密innodb資料檔案的備份拷貝，該選項直接傳遞給xtrabackup子程式
--encrypt-key=ENCRYPTION_KEY
指導xtrabackup使用了--encrypt選項時候使用ENCRYPTION_KEY這個KEY,直接傳遞給xtrabackup子程式
--encrypt-key-file=ENCRYPTION_KEY_FILE
這個選項告訴xtrabackup使用--encrypt的時候。Key存在了ENCRYPTION_KEY_FILE這個檔案中
--encrypt-chunk-size=#
這個選項指定了每個加密執行緒內部worker buffer的大小，單位位元組，直接傳遞給xtrabackup子程式
--export=DIRECTORY
這個選項直接傳遞給 xtrabackup --export選項。開啟可匯出單獨的表之後再匯入其他Mysql中
--extra-lsndir=DIRECTORY
這個選項接受一個字串引數指定儲存額外一份xtrabackup_checkpoints檔案的目錄，直接傳遞給xtrabackup --extra-lsndir選項
--force-non-empty-directories
指定該引數時候，使得innobackupex --copy-back或innobackupex --move-back選項轉移檔案到非空目錄，已存在的檔案不會被覆蓋，如果--copy-back和--move-back檔案需要從備份目錄拷貝一個在datadir已經存在的檔案，會報錯失敗
--galera-info
該選項生成了包含建立備份時候本地節點狀態的檔案xtrabackup_galera_info檔案，該選項只適用於備份PXC。
--history=NAME
percona server5.6的備份歷史記錄在percona_schema.xtrabackup_history表
--host=HOST
選項指定了TCP/IP連線的資料庫例項IP
--ibbackup=IBBACKUP-BINARY
這個選項指定了使用哪個xtrabackup二進位制程式。IBBACKUP-BINARY是執行percona xtrabackup的命令，。這個選項適用於xtrbackup二進位制不在你是搜尋和工作目錄，如果指定了該選項,innoabackupex自動決定用的二進位制程式
--include=REGEXP
正規表示式匹配表的名字[db.tb]，直接傳遞給xtrabackup --tables選項。
--incremental
這個選項告訴xtrabackup建立一個增量備份，直接傳遞給xtrabakcup子程式，當這個選項指定，需要同時指定--incremental-lisn或者--incremental-basedir。如果沒有指定，預設傳給xtrabackup --incremental-basedir，值為Backup BASE目錄中的第一個時間戳目錄
--incremental-basedir=DIRECTORY
這個選項接受了一個字串引數指定含有full backup的目錄為增量備份的base目錄，與--incremental同時使用
--incremental-dir=DIRECTORY
指定了增量備份的目錄,結合full backup生成生成一份新的full bakcup
--incremettal-history-name=NAME
這個選項指定了儲存在PERCONA_SCHEMA.xtrabackup_history基於增量備份的歷史記錄的名字。Percona Xtrabackup搜尋歷史表查詢最近（innodb_to_lsn）成功備份並且將to_lsn值作為增量備份啟動出事lsn.與innobackupex--incremental-history-uuid互斥。如果沒有檢測到有效的lsn，xtrabackup會返回error
--incremetal-history-uuid=UUID
這個選項指定了儲存在percona_schema.xtrabackup_history基於增量備份的特定歷史記錄的UUID
--incremental-lsn=LSN
這個選項指定增量備份的LSN，與--incremental選項一起使用
--kill-long-queries-timeout=SECONDS
這個選項指定innobackupex從開始執行FLUSH TABLES WITH READ LOCK到kill掉阻塞它的這些查詢之間等待的秒數，預設值為0.以為著Innobakcupex不會kill任何查詢，使用這個選項xtrabackup需要有Process和super許可權。
--kill-long-query-type=all|select
指定kill的型別，預設是all
--ftwrl-wait-timeout=SECONDS
執行FLUSH TABLES WITH READ LOCK之前，innobackupex等待阻塞查詢執行完成等待秒數，超時的時候如果查詢仍然沒有執行完，innobackupex會終止並報錯，預設為0，innobakcupex不等待查詢完成立刻FLUSH
--ftwrl-wait-threshold=SECONDS
指定innoabckupex檢測到長查詢和 innobackupex --ftwrl-wait-timeount不為0,這個長查詢可以執行的閾值，
--ftwrl-wait-query-type=all|update
指定innobakcupex獲得全域性鎖之前允許那種查詢完成，預設是ALL
--log-copy-interval=#
這個選項指定了每次拷貝log執行緒完成檢查之間的間隔（毫秒）
--move-back
從備份目錄中將最近一份備份中的所有檔案移動到datadir目錄中
--no-lock
關閉FTWRL的表鎖，只有在你所有表都是Innodb表並且你不關心backup的binlog pos點
如果有任何DDL語句正在執行或者非InnoDB正在更新時（包括mysql庫下的表），都不應該使用這個選項，後果是導致備份資料不一致
如果考慮備份因為獲得鎖失敗，，可以考慮--safe-slave-backup立刻停止複製執行緒
--no-timestamp
這個選項阻止在BACKUP-ROOT-DIR裡建立一個時間戳子目錄，指定了該選項的話，備份在BACKUP-ROOT-DIR完成
--no-version-check
這個選項禁用由--version-check開啟的version check
--parallel=NUMBER-OF-THREADS
指定xtrabackup並行複製的子程式數。注意是檔案級別並行，如果有多個ibd檔案，他們會並行拷貝，如果所有的表存在一個表空間檔案中，沒有任何作用。。直接傳遞給xtrabakcup --parallel選項
--password=PASSWORD
--port=PORT
--rebuild-indexes
與--apply-log一起用時候才有效。並且直接傳遞給xtrabackup，在apply log之後重建所有輔助索引，該選項用於Prepare緊湊備份。
--rebuild-threads=NUMBER-OF-THREADS
與--apply-log和--rebuild-index選項一起用時候才生效，重建索引的時候，xtrabacup以指定的執行緒數並行的處理表空間檔案
--redo-only
這個選項在prepare base full backup，往其中merge增量備份（但不包括最後一個）時候使用。傳遞給xtrabackup --apply-log-only的選項。這個強制xtrabackup跳過rollback並且只重做redo
--rsync
通過rsync工具優化本地傳輸，當指定這個選項，innobackupex使用rsync拷貝非Innodb檔案而替換cp，當有很多DB和表的時候會快很多。不能--stream一起使用
--safe-slave-backup
指定的時候innobackupex會在執行FLUSH TABLES WITH READ LOCK停止sql執行緒,並且直到show status裡slave_open_temp_tables的值為0的時候start backup，。如果沒有開啟的臨時表，就開始備份，否則sql執行緒start或者stop直到沒有開啟的臨時表，如果在innobackupex --safe-slave-backup-timeout之後slave_open_temp_tables的值仍沒有變成0備份就會失敗。SQL執行緒會在backup完成之後重啟。
--safe-slave-backup-timeout=SECONDS
innobackupex --safe-slave-backup應該等多少秒等slave_open_temp_tables變成0，預設是300秒
--scpopt=SCP-OPTIONS
當--remost-host指定的時候，指定傳給scp的命令列選項。如果沒有指定，預設為-Cp -c arcfour
--slave-info
對slave進行備份的時候使用，列印出master的名字和binlog pos，同樣將這些資訊以change master的命令寫入xtrabackup_slave_info檔案。可以通過基於這份備份啟動一個從庫並且儲存在xtrabackup_slave_info檔案中的binlog pos點建立一個新的從庫
--socket
連線本地例項的時候使用
--sshopt=SSH-OPTIONS
在指定了--remost-host的時候，指定傳給ssh的命令列選項
--stream=STREAMNAME
流式備份的格式，backup完成之後以指定格式到STDOUT，目前只支援tar和xbstream。使用xbstream為percona xtrabakcup髮型版本，如果在這個選項之後指定了路徑。會理解值為tmpdir
--tables-file=FILE
指定含有表列表的檔案，格式為database.table,該選項直接傳給xtrabackup's --tables-file
--throttle=IOS
指定每秒IO操作的次數，直接傳遞給xtrabackup --throttle選項。只作用於bakcup階段有效。apply-log和--copy-back不生效不要一起用
--tmpdir=DIRECTORY
指定--stream的時候，指定臨時檔案存在哪裡，在streaming和拷貝到遠端server之前，事務日誌首先存在臨時檔案裡。
--use-memory=#
只能和--apply-log選項一起使用，prepare a backup的時候，xtrabackup做crash recovery分配的記憶體大小，單位位元組。也可(1MB,1M,1G,1GB),直接傳給xtrabackup --use-memory選項
--version
顯示Innobackupex版本和版權資訊後退出
--version-check
innobackupex在與server建立連線之後的備份階段進行版本檢查

Xtrabackup 二進位制

get started

配置xtrabackup

xtrabackup讀取配置檔案中的[mysqld]和[xtrabackup]部分，讀取datardir和innodb選項，可以通過將這些都指定在[xtrabackup]部分。越靠後，越優先。

最簡單的在[xtrabackup]部分只指定target_dir,該選項指定backup預設放的目錄，例如:

[xtrabackup]

target_dir = /data/backups/mysql

Xtrabackup-FULL BAKCUPS

建立一個備份

執行xtrabackup指定--backup ，--target_dir,--datadir.

如果不指定target_dir，xtrabacup會建立它。如果目錄存在且為空，xtrabackup會成功，xtrabackup不會覆蓋已有檔案。會報“file exist”的錯誤

這個工具將工作目錄轉換到datadir,並且執行兩項主要的任務:(後臺執行的log掃描執行緒掃描redo log,ibdata1上的檔案拷貝執行緒)

後臺啟動一個拷貝日誌的執行緒，這個執行緒關注innodb日誌檔案，當redo log有變化，這個執行緒拷貝變化的塊到到target目錄成為xtrabackup_logfile的檔案
拷貝Innodb資料檔案到目標目錄，這不是個簡單拷貝檔案那麼簡單，它像Innodb那樣開啟讀取檔案，讀取資料字典並且依次的拷貝一個page
當拷貝完資料檔案，xtrabackup停止log-copying執行緒，並在target目錄生成包含了備份型別和開頭和結尾的lsn號的xtarabckup_checkpoints檔案，
舉例命令如下:

xtrabakcup --backup --datadir=/data1/mysql/ --target-dir=/data/backups/

備份/data1/mysql目錄並儲存在/data/backups/mysql/。如果你指定一個相對路徑,target目錄會關聯到當前路徑
在備份過程期間，你能看到一大堆輸出展示了檔案正在拷貝中，同時log file執行緒重複的掃描redo log，並且檔案拷貝執行緒將innodb資料檔案拷貝到target目錄
最後一件需要關注的事情是，LSN的值在哪裡成為一個數字決定於你的系統
注意：log拷貝執行緒每秒檢查事務日誌去看是否寫入了新的日誌記錄需要拷貝，也有偶然的log拷貝執行緒趕不上大量的寫入事務日誌的速度，redo log在被讀取之前就被覆蓋了，就會報錯！！！！
當Backup結束，target目錄包含了：

/data/backups/ibdata11
/data/backups/test
/data/backups/test/tbl1.ibd
/data/backups/xtrabackup_checkpoints
/data/backups/xtrabackup_logfile

備份會持續時間決定於資料庫大小，在任何時間cancel都是安全的，因為它並不改變資料庫
下一步要讓backup變為可還原:prepare backup

preparing the backup

用--backup生成備份後，下一步就是prepare。資料檔案不是時間點一致的直到他們被prepare，因為他們在程式執行時不同時間拷貝，並且發生時已經改變了，如果你嘗試用這些資料檔案啟動innodb,之後會檢測到崩潰，並且crash自己來防止在損壞的資料上繼續執行。--prepare階段讓這些檔案在任意時間都一致性，所以你可以在上面執行Innodb

注意：innobakcupex --apply-log 自動從bakcup-my.cnf讀取innodb配置，或者--defaults-file=bakcup-my.cnf選項傳遞給xtrabackup。否則會導致不正確還原因為xtrabackup已經用了錯誤的配置選項

你可以在任何機器上執行Prepare操作，不需要在備份機上或者還原機上操作，你可以拷貝backup到一臺專門的中控機並且在prepare

注意：你可以用新版本prepare一個較老版本建立的backup，但反過來不行。在一臺不支援的Mysql server版本上prepare一個bakcup應該用支援該server的最新版本，例如，如果通過1.6版本xtrabackup備份mysql5.0,用2.2prepare是不支援的。因為2.1版本中移除了5.0

在prepare階段，xtarbackup嵌入了修改過的innodb，禁止了innodb的檢查，比如日誌檔案大小是否準確。

prepare階段就是使用這個嵌入的innodb來做通過日誌檔案對資料檔案進行crash恢復

xtrabackup --prepare -- target -dir=/ data /backups/mysql

完成之後，可以看到innodb shutdown的資訊和lsn

你的備份現在是乾淨並且一致的了，並且準備好還原，然而，你可能希望額外的步驟讓還原更快。這需要第二次Prepare。第一次prepare讓資料檔案完美的一致性。但是不常見新鮮的Innodb日誌檔案，如果這時候還原備份並且啟動Mysql,它需要建立新的日誌檔案，這需要一段時間。你也許不想等待。如果你第二次執行--prepare，xtrabackup會建立日誌檔案，redo log的大小決定於mysql的配置檔案

xtrabackup --prepare --target-dir=/data/backups/mysql/

xtrabackup: This target seems to be already prepared.

xtrabackup: notice: xtrabackup_logfile was already used to ’ --prepare’.

101107 16 : 54 : 10 InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib_logfile0 size to <SIZE> MB

InnoDB: Database physically writes the file full: wait ...

101107 16 : 54 : 10 InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib_logfile1 size to <SIZE> MB

InnoDB: Database physically writes the file full: wait ...

101107 16 : 54 : 15 InnoDB: Shutdown completed; log sequence number 1284108

第二次或者第三次prepare不會改變已經Prepare的資料檔案，你可以看輸出:

xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to ’--prepare’.

不推薦prepare的時候中斷xtrabackup程式，會導致資料檔案損壞並且backup不可用，中斷prepare程式不保證backup可用性

如果以後會拿這份這份backup作為基礎而進行增量備份，prepare的時候要使用--apply-log-only選項，否則你無法apply增量備份到這份basic全備。

還原全備

xtrabackup沒有還原備份的功能。由使用者來做，你可以通過rsync或者cp來還原，你應該檢查還原檔案有正確的屬主和許可權

注意：datadir在還原備份之前必須為空，同樣重要的是Mysql server需要還原之前shutdown，你不能在Mysql執行時還原到datadir目錄（除非是匯入部分備份）

rsync命令還原:

rsync -avrP /data1/backup/ /data1/mysql

檔案屬性保留，大多數情況下需要在啟動例項之前改變檔案的屬主

chown -R mysql5711:mysql /data1/mysql5711

注意，xtrabackup只備份Innodb資料，你必須單獨還原mysql系統庫，myisam資料，表定義檔案。或者innobakcupex

其他型別備份

增量備份

xtrabackup和Innobacupex都支援增量備份，意味著可以只拷貝自從上次全備之後變化的資料，你可以在每個full backup之間做很多份增量備份，這樣你可以做這樣一個備份程式一週做一次full backup每天一次增量，或者一天做一次full backup每小時做一次增量

增量備份原理，每個Innodb頁都有一個LSN號，一份增量備份拷貝每個比上次增量備份或者全備LSN更新的page。

有兩個演算法可以找到這樣的需要拷貝的Page的集合

對於所有server和版本可用，通過讀取所有的資料頁檢查page的LSN
僅對Percona Server適用，忽略

增量備份不會不會實際的和上次的備份比較資料檔案。你如果知道LSN的話甚至在沒有先前備份的情況下使用通過--incremental-lsn執行一次增量備份。增量備份簡單的讀取page並且比較他們的LSN與上次備份的LSN。然而你仍然需要一個full bakcup來恢復增量的變化。如果沒有一個full bakcup作為一個base，增量備份是沒有用的

建立一份增量備份

建立一份增量備份，需要從一個full backup開始，xtrabakcup寫一個叫xtrabackup_checkporints的檔案到備份目標目錄，這個檔案包含一行顯示to_lsn（backup結束時候的lsn）

xtrabackup --backup --target-dir=/data/backups/base --datadir=/data1/mysql5711

xtrabakcup_checkpoints檔案包括

backup_type = full-bakcuped
from_lsn =0
to_lsn =1291135

基於這個full backup建立一份增量：

xtrabackup --backup --target-dir=/data/backups/inc1 --incremental-basedir=/data/backups/base --datadir=/data1/mysql5711

/data/backup/inc1/目錄包含了增量的檔案，比如ibdata1.delta和test/table1.idb.delta ，代表了從LSN1291135以來的變化，如果檢查這個目錄的xtrabacup_checkpoints檔案，會看見如下:

bacup_type = incremental
from_lsn = 1291135
to_lsn = 1291340

現在可以拿inc1當做接下來增量備份的base目錄:

xtrabackup --backup --target-dir=/data/backups/inc2 --incremental-basedir=/data/backups/inc1 --datadir=/data1/mysql5711/

prepare增量備份

增量備份的--prepare階段與正常備份不同，在正常備份中，執行兩種型別操作來保證資料庫一致性，已提交的事務會在資料檔案中重放，未提交的事務回滾，prepare備份的時候你需要跳過未提交事務的回滾，因為在備份的那個時刻未提交的事務正在進行中，並且明顯的它們會在下次增量備份的提交。你需要使用--apply-log-only選項來阻止回滾階段

如果你不用--apply-log-only選項阻止回滾，那麼之後的增量備份就無效了。事務如果被回滾，那之後的增量備份就不能被重放

從你開始建立的full backup，你可以Prepare它，之後重放增量的區別，回憶你已經有如下備份base/,inc1/,inc2/

prepare base備份，然後阻止回滾：

xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base

輸出顯示lsn為1291135.

備份如果現在還原是非常安全的，甚至回滾的步驟被跳過了，如果你現在還原並啟動MySQL,InnoDB會檢測到回滾沒有執行，之後再在後臺進行開始crash恢復，通知你資料沒有被正常關閉

重放第一個增量備份給full backup:

xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --incremental-dir=/data/backups/inc1

這樣給/data/backups/base目錄重放delta檔案。將備份的時間前進到增量備份的時間點，之後照常重放事務日誌，最終資料是在/data/backups/base並不在增量目錄裡.

顯示如下：

incremental backup from 1291135 is enabled.
xtrabackup: cd to /data/backups/base/
xtrabackup: This target seems to be already prepared.
xtrabackup: xtrabackup_logfile detected: size=2097152, start_lsn=(1291340)
Applying /data/backups/inc1/ibdata1.delta ...
Applying /data/backups/inc1/test/table1.ibd.delta ...
.... snip
101107 20:56:30 InnoDB: Shutdown completed; log sequence number 1291340

如果通過/data/backups/base目錄還原，你可以看見資料庫的狀態是第一次備份時的狀態

prepare第二次增量備份以同樣的步驟，apply增量到上步的base，將資料的時間點同步到第二次增量備份的時間點

xtrabackup --prepare --target-dir=/data/backups/base --incremental-dir=/data/backups/inc2

--apply-log-only用在merging所有增量除最後一個。最後一步仍然可以用，備份最終也是一直的但是server不會執行回滾步驟

部分備份

需要開啟innodb_file_per_table,有三種方式支援部分備份

注意：如果任何匹配的或者列入的表在備份期間刪除，xtrabackup會失敗

使用--tables選項匹配databasename.tablename xtrabackup --backup --datadir=/data1/mysql5711 --target-dir=/data/backups/ --tables="^test[.].*" 備份整個test庫
使用--tables-file選項
使用 --databases 和 --databases-file選項 #### prepare 部分備份會用--prepare選項進行部分備份的時候，你會看到相關表不存在的報警，原因是這些表存在於InnoDB的資料字典中但是對應的.ibd檔案不存在，他們沒有被拷貝到備份目錄中去，這些表將會從資料字典中移除，但是當你還原備份並且啟動InnoDB的時候，他們講不會存在並在日誌檔案中報錯

壓縮備份

不包含輔助索引頁，佔用更少磁碟空間，缺點是prepare的時間更長因為需要重建輔助索引

注意：壓縮備份不支援系統表空間，所以應該開啟innodb-file-per-table選項

建立壓縮備份

通過--compact選項

xtrabackup --bakcup --compact --target-dir=/data/backups

檢查target-dir目錄下的xtrabackup-checkpoints檔案。如下:

backup_type = full-backuped
from_lsn = 0
to_lsn = 2888984349
last_lsn = 2888984349
compact = 1

如果不使用--compact的話--value的值為0，這個方法可以快速檢測備份是否包含輔助索引頁

prepare 壓縮備份

通過--rebuild-indexes和--apply-logs一起使用

xtrabackup --prepare --rebuild-indexes /data/backups

通過--rebuild-threads選項多執行緒重建索引

xtrabackup --prepare --rebuild-indexes --rebuild-threads=16 /data/backups/

還原壓縮備份

沒有現成工具，可以通過rsync或者cp完成，需要檢查還原檔案是否有正確許可權

高階特性:

throttling備份

xtrabackup不會阻塞資料庫讀寫，backup增加系統壓力，可以通過--throttle選項，這個選項限制IO操作的數量為每秒每MB

在--backup模式，這個選項限制了xtrabackup每秒執行的對（read和write）。如果你建立一個增量備份。然後限制每秒讀IO的數量

預設，no throttling，xtrabackup最快的讀寫資料，如果你IO限制過於嚴格，備份會非常慢並且追不上innodb寫事務日誌的速度，備份將永遠無法完成

編寫備份指令碼

suspending after copying

在備份模式中，xtarbackup在後臺拷貝日誌檔案，前端執行緒拷貝資料檔案，，之後停止日誌執行緒並完成。如果你使用--suspend-at-end選項而不是停止日誌執行緒並完成。xtrabacup會繼續拷貝日誌檔案，並在target目錄生成一個xtrabackup_suspended檔案，之後要這個檔案存在，xtrabackup會繼續觀察事務日誌並把他們拷貝到target目錄中xtrabackup_logfile檔案。當這個檔案移除的時候，xtrabackup會停止拷貝事務日誌並退出

該功能協調備份Innodb資料和其他動作時非常有用，最明顯的是拷貝表定義檔案(.frm)以便備份能被還原，你可以後臺啟動xtrabakcup，等待xtrabackup_suspended檔案被建立，然後拷貝所有你需要完成這個備份的任何檔案。。這個就是innobakcupex工具做的工作

生成後設資料

備份包含任何你需要還原備份時候需要的資訊是個好主意，xtarbackup能列印my.cnf檔案中需要還原的資料和日誌檔案的內容，如果增加--print-param選項。會列印如下內容:

```

This MySQL options file was generated by XtraBackup.

[mysqld]

datadir = /data/mysql/

innodb_data_home_dir = /data/innodb/

innodb_data_file_path = ibdata1:10M:autoextend

innodb_log_group_home_dir = /data/innodb-logs/

```

可以重定向輸出到backup的target目錄

協商source目錄

配置檔案或者其他因素會導致xtrabackup從不同的位置備份資料。為了防止這些，你可以用--print-param來查詢從哪裡copy資料。你可以用輸出來保證xtrabackup和你的指令碼處理同樣的資料集

log streaming

可以通過--log-stream 讓xtrabackup將redo log檔案streaming而不是拷貝，這樣會自動新增--suspend-at-end選項。你的指令碼可以執行

stream遠端備份並通過管道將log檔案傳給ssh並且通過rsync或者xbstream等工具將資料拷貝到遠端伺服器上

分析表統計資訊

xtrabackup以只讀模式分析InnoDB資料檔案並提供給統計。可以通過--stats選項。可以同--ables選項一起使用限制檢查的的檔案。還有--use-memory選項。

你可以在一臺執行例項的機器上執行分析，在分析期間資料更改會有出錯的機率。或者可以分析備份的拷貝。如果需要使用統計的特性，你需要一個乾淨的拷貝包括正確的Logfile大小，，所以你需要在一次備份上執行--prepare兩次

使用binlog

xtrabakcup提取了innodb事務日誌關於對應已提交事務的binlog pos，這個可以列印出backup對應的binlog pos，你可以通過搭建一些列從庫或者進行基於時間點的恢復

找到binlog pos

一旦backup prepare之後你可以找到binlog pos，通過執行xtrabakcup --prepare或者innobackupex --apply-log都可以完成。如果bakcup是來源開啟binlog的例項。xtrabackup會在target目錄建立一個xtrabakcup_binglog_info的檔案。這個檔案包含了與prepare對應的binlog名字和pos點位

輸出的資訊在xtrabakcup_binlog_pos_info檔案中找到，只有使用innodb引擎才會準確

其他引擎，比如myisam,你應該使用xtrabackup_binlog_info檔案獲得位置

基於時間點恢復

從一份xtrabackup的備份裡基於時間點的恢復，你需要prepare並且還原備份，之後重放xtrabackup_binlog_info中記錄的點開始的binlog

搭建一個新的從庫

需要先prepare,然後在新從庫的data目錄中還原，之後使用change master to命令，使用xtrabackup_binlog_info檔案的binlog和pos啟動複製

還原單獨表

在5.6版本之前，即使開啟innodb_file_per_table選項，仍然不可能通過在例項之間通過拷貝檔案來拷貝表。然而，通過Xtrabackup你可以從任何InnoDB資料庫中匯出單表，並且匯入到5.6中去（source不必是5.6但是destination必須是！！！！！）只在獨立.ibd檔案生效，如果沒有獨立ibd檔案是不能夠匯出單表的！！！！！

匯出單表

這個表必須在開啟innodb_file_per_table模式下建立。所以在在--bakcup建立一份備份之後，.ibd檔案應該已經存在於target目錄中

當你prepare的時候，需要額外加--export命令:

xtrabacup --prepare --export --target-dir=/data/backups/mysql5711

現在你可以在target目錄找到.exp檔案

$ find /data/backups/mysql5711/ -name export_test.*
/data/backups/mysql5711/test/export_test.exp
/data/backups/mysql5711/test/export_test.ibd
/data/backups/mysql711/test/export_test.cfg

這三個檔案是你將表匯入5.6的所有檔案

說明：mysql使用cfg檔案，這個檔案包含了Innodb字典dump。這種格式不同於xtrabDB的.exp檔案。嚴格來講，.cfg檔案在5.6以及之後是不在需要的。如果存在cfg檔案，那麼Innodb會通過cfg檔案做schema驗證

匯入表

在5.6，以同樣表結構建立一張表，然後執行以下步驟：

執行alter table test.export_test discard tablespace;需要開啟innodb_file_per_table
拷貝之前匯出到檔案目的伺服器的資料目錄test/子目錄
執行alter table test.export_test import tablespace; 這張表現在已經匯入，你可以通過select命令檢視匯入資料 ### LRU dump備份這個特性減少了通過在例項重啟之後從ib_lru_dump檔案還原buffer pool狀態的預熱時間。xtrabakcup自動發現ib_lru_dump並且自動備份如果my.cnf中開啟buffer還原選項，buffer pool會在從備份還原之後自動預熱。只在Percona server中有這個選項。mysql沒有

實施

xtrabakcup的限制

有以下需要注意:

* 如果xtrabakcup_logfile超過4G，32位系統上的xtrabakcup在--prepare階段會失敗

* xtrabackup在第一次--prepare的不會生成新的redo log檔案，必須--prepare兩次，在第二次的時候才會生成

* 不支援my.cnf裡有--set-variable這種格式設定

實施細節

檔案許可權

xtrabacup以讀寫方式開啟源資料檔案，但不更改這些檔案，意味著你必須以有寫這些檔案許可權的使用者來執行xtrabackup。以讀寫模式開啟檔案的原因是xtrabakcup使用內建的Innodb庫來開啟讀寫檔案，並且Innodb以讀寫模式開啟因為正常假設是需要寫這些檔案了

調整os buffers

因為xtrabackup讀取檔案系統的大量資料，可能它使用posix_fadvise()指導作業系統不要嘗試快取從磁碟讀取的block。沒有這個提示。假設xtrabackup很快再次需要這些塊，作業系統更願意快取這些塊。快取如此大的檔案會給作業系統的虛擬記憶體增加壓力併到底其他程式，比如資料庫swap out。xtrabakcup工具通過source和destination如下提示來避免這種情況發生:

posix_fadvise(file，0，0，POSIX_FADV_DONTNEED)

另外，xtrabackup讓作業系統在原始檔上來執行更挑戰性的read-ahead優化

posix_fadvise(file, 0, 0, POSIX_FADV_SEQUENTIAL)

拷貝資料檔案

當向target目錄拷貝資料檔案的時候，xtrabakcup一次讀寫1MB資料。這是不可配置的。當拷貝事務日誌，xtrabackup一次讀寫512位元組。著同樣不能配置。是符合Innodb的（percona server的解決辦法是有額外的引數innodb_log_block_size）

讀取檔案之後，xtrabackup一次1MBbuffer遍歷page。並通過innodb buf_page_is corrupted()函式檢查每個Page的corruption。如果page損壞，便會重讀並且每個page重試10次，二次寫buffer會跳過這個檢查

手冊

xtrabackup選項

選項

--apply-log-only
prepare備份的時候只執行redo階段，對增量備份非常重要
--backup
建立備份並且放入--target-dir目錄中
--close-files
不保持檔案開啟狀態，xtrabackup開啟表空間的時候通常不會關閉檔案控制程式碼目的是為了正確處理DDL操作。然而，如果表空間數量非常巨大並且不適合任何限制，一旦檔案不在被訪問的時候這個選項可以關閉檔案控制程式碼.開啟這個選項會產生不一致的備份。自己評估風險。。
--compact
建立一份沒有輔助索引的緊湊備份
--compress
壓縮所有輸出資料，包括事務日誌檔案和後設資料檔案，通過指定的壓縮演算法，目前唯一支援的演算法是 quicklz .結果檔案是qpress歸檔格式，每個xtrabackup建立的*.qp檔案都可以通過qpress程式提取或者解壓縮
--compress-chunk-size=#
壓縮執行緒工作buffer的位元組大小，預設是64K
--compress-threads=#
xtrabackup進行並行資料壓縮時的worker執行緒的數量，該選項預設值是1，並行壓縮（'compress-threads'）可以和並行檔案拷貝('parallel')一起使用。例如:'--parallel=4 --compress --compress-threads=2'會建立4個IO執行緒讀取資料並通過管道傳送給2個壓縮執行緒
--create-ib-logfile
這個選專案前還沒有實現，目前建立Innodb事務日誌，你還是需要prepare兩次bakcup
--datadir=DIRECTORY
backup的源目錄，mysql例項的資料目錄。從my.cnf中讀取，或者命令列指定
--defaults-extra-file=[MY.CNF]
在global files檔案之後讀取，必須在命令列的第一選項位置指定
--defaults-file=[MY.CNF]
唯一從給定檔案讀取預設選項，必須是個真實檔案，必須在命令列第一個選項位置指定
--defaults-group=GROUP-NAME
從配置檔案讀取的組，innobakcupex多個例項部署時使用
--export
為匯出的表建立必要的檔案
--extra-lsndir=DIRECTORY
(for --bakcup):在指定目錄建立一份xtrabakcup_checkpoints檔案的額外的備份
--incremental-basedir=DIRECTORY
建立一份增量備份時，這個目錄是增量別分的一份包含了full bakcup的Base資料集
--incremental-dir=DIRECTORY
prepare增量備份的時候，增量備份在DIRECTORY結合full backup建立出一份新的full backup
--incremental-force-scan
建立一份增量備份時，強制掃描所有增在備份中的資料頁即使完全改變的page bitmap資料可用
--incremetal-lsn=LSN
建立增量備份的時候指定lsn。
--innodb-log-arch-dir
指定包含歸檔日誌的目錄。只能和xtrabackup --prepare選項一起使用
--innodb-miscellaneous
從My.cnf檔案讀取的一組Innodb選項。以便xtrabackup以同樣的配置啟動內建的Innodb。通常不需要顯示指定
--log-copy-interval=#
這個選項指定了log拷貝執行緒check的時間間隔（預設1秒）
--log-stream
xtrabakcup不拷貝資料檔案，將事務日誌內容重定向到標準輸出直到--suspend-at-end檔案被刪除。這個選項自動開啟--suspend-at-end
--no-defaults
不從任何選項檔案中讀取任何預設選項,必須在命令列第一個選項
--databases=#
指定了需要備份的資料庫和表
--database-file=#
指定包含資料庫和表的檔案格式為 databasename1.tablename1 為一個元素，一個元素一行
--parallel=#
指定備份時拷貝多個資料檔案併發的程式數，預設值為1
--prepare
xtrabackup在一份通過--backup生成的備份執行還原操作，以便準備使用
--print-default
列印程式引數列表並退出，必須放在命令列首位
--print-param
使xtrabackup列印引數用來將資料檔案拷貝到datadir並還原它們
--rebuild_indexes
在apply事務日誌之後重建innodb輔助索引，只有和--prepare一起才生效
--rebuild_threads=#
在緊湊備份重建輔助索引的執行緒數，只有和--prepare和rebuild-index一起才生效
--stats
xtrabakcup掃描指定資料檔案並列印出索引統計
--stream=name
將所有備份檔案以指定格式流向標準輸出，目前支援的格式有xbstream和tar
--suspend-at-end
使xtrabackup在--target-dir目錄中生成xtrabakcup_suspended檔案。在拷貝資料檔案之後xtrabackup不是退出而是繼續拷貝日誌檔案並且等待知道xtrabakcup_suspended檔案被刪除。這項可以使xtrabackup和其他程式協同工作
--tables=name
正規表示式匹配database.tablename。備份匹配的表
--tables-file=name
指定檔案，一個表名一行
--target-dir=DIRECTORY
指定backup的目的地，如果目錄不存在，xtrabakcup會建立。如果目錄存在且為空則成功。不會覆蓋已存在的檔案
--throttle=#
指定每秒操作讀寫對的數量
--tmpdir=name
當使用--print-param指定的時候列印出正確的tmpdir引數，除此之外沒有任何用。。
--to-archived-lsn=LSN
指定prepare備份時apply事務日誌的LSN，只能和xtarbackup --prepare選項一起用
--user-memory = #
通過--prepare prepare備份時候分配多大記憶體，目的像innodb_buffer_pool_size。預設值100M如果你有足夠大的記憶體。1-2G是推薦值，支援各種單位(1MB,1M,1GB,1G)
--version
列印xtrabackup版本並退出

xbstream

支援同時壓縮和流式化。需要客服傳統歸檔tar,cpio和其他不允許動態streaming生成的檔案的限制，例如動態壓縮檔案，xbstream超越其他傳統流式/歸檔格式的的優點是，併發stream多個檔案並且更緊湊的資料儲存（所以可以和--parallel選項選項一起使用xbstream格式進行streaming）

像tar一樣使用:

* -x 選項從標準輸入stream read中提取檔案到當前目錄，除非指定其他-C選項

* -c 選項 stream命令列指定的檔案到標準輸出

目的，通過posix_fadvise()呼叫減少對OS page cache的影響

xtrabackup開啟壓縮的時候素有資料被壓縮，包括事務日誌和後設資料檔案，通過指定的壓縮演算法，唯一當前支援度呃演算法是quicklz,結果檔案是qpress歸檔個事。每隔xtrabakcup生成的.qp檔案可以通過qpress檔案歸檔提取或者解壓縮。這就意味著不需要通過tar.gz解壓縮整個bakcup來還原一個單表

檔案可以通過qpress解壓縮，qpress支援多執行緒解壓縮

xtrabakcup工作原理

xtrabackup基於InnoDB crash-recovery功能，拷貝innodb資料檔案，這會導致資料內部不一致，，但是之後它在檔案上執行crash recovery使資料檔案一致

innodb維護redo log又稱事務日誌。redo log日誌中包含innodb資料的每次變動。當innodb啟動時會去檢查資料檔案和事務日誌，然後又兩個步驟，1，apply應用已提交的事務日誌到資料檔案，2，已更改但未提交的事務進行undo操作

percona xtrabackup在啟動的時候記錄LSN，然後拷貝資料檔案，這會需要一些時間，，所以如果檔案改變了，它反映出不同時間點資料庫的狀態，。同時，xtrabakcup啟動一個後臺進行監控事務日誌，並拷貝變動（複製修改）.xtrabakcup需要持續執行以上因為事務日誌是迴圈寫的，過段時間之後會被複用，xtrabackup需要每次資料檔案變化對應的事務日誌記錄

上述是備份的程式，下一步是prepare的程式，在這個過程中，xtarabakcup通過已拷貝的事務日誌在已拷貝的資料檔案上執行crash recovery。之後，資料庫已經可以進行還原並可以使用了

以上通過編譯好的二進位制xtrabakcup實施了。

Innobackup在此基礎上增加了更多功能，比如備份Myisam表和.frm檔案。它啟動xtrabakcup並且等待它完成拷貝檔案，之後執行FLUSH TABLES WITH READ LOCK防止mysql資料更改，得到表全域性鎖，然後flush所有的myisam表到磁碟，之後再釋放表全域性鎖

備份的myisam和innodb表最終會一致，因為在prepare(recovery)之後，innodb資料會前滾到備份完成時候的時間點，而不是回滾到備份開始時候的時間點。這個時間點與 FLUSH TABLES WITH READ LOCK 發生時一致，所有myisam與已prepare過的Innodb資料是同步的

percona xtrabakcup是一些列如下的工具：

innobackupex:xtrabackup的符號連線，innobakcupex支援2.2版本的所有特性和語法，但是現在已經降級並且在以一個主要版本中remove

xtrabackup：編譯的C程式提供備份一整個資料庫例項myisam和Innodb表

xbstream：以xbstream格式streaming和提取檔案

About Me

........................................................................................................................

● 本文作者：小麥苗，部分內容整理自網路，若有侵權請聯絡小麥苗刪除

● 本文在itpub（

http://blog.itpub.net/26736162

）、部落格園（

http://www.cnblogs.com/lhrbest

）和個人weixin公眾號（

xiaomaimiaolhr

）上有同步更新

● 本文itpub地址：

http://blog.itpub.net/26736162

● 本文部落格園地址：

http://www.cnblogs.com/lhrbest

● 本文pdf版、個人簡介及小麥苗雲盤地址：

http://blog.itpub.net/26736162/viewspace-1624453/

● 資料庫筆試面試題庫及解答：

http://blog.itpub.net/26736162/viewspace-2134706/

● DBA寶典今日頭條號地址：

http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826

........................................................................................................................

● QQ群號：

230161599

（滿）

、618766405

● weixin群：可加我weixin，我拉大家進群，非誠勿擾

● 聯絡我請加QQ好友

（

646634621

）

，註明新增緣由

● 於 2019-07-01 06:00 ~ 2019-07-31 24:00 在西安完成

● 最新修改時間：2019-07-01 06:00 ~ 2019-07-31 24:00

● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解

● 版權所有，歡迎分享本文，轉載請保留出處

........................................................................................................................

●

小麥苗的微店

：

https://weidian.com/s/793741433?wfr=c&ifr=shopdetail

●

小麥苗出版的資料庫類叢書

：

http://blog.itpub.net/26736162/viewspace-2142121/

●

小麥苗OCP、OCM、高可用網路班

：

http://blog.itpub.net/26736162/viewspace-2148098/

●

小麥苗騰訊課堂主頁

：

https://lhr.ke.qq.com/

........................................................................................................................

使用

weixin客戶端

掃描下面的二維碼來關注小麥苗的weixin公眾號（

xiaomaimiaolhr

）及QQ群（DBA寶典）、新增小麥苗weixin，

學習最實用的資料庫技術。

........................................................................................................................

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26736162/viewspace-2649981/，如需轉載，請註明出處，否則將追究法律責任。

基於percona xtrabackup 2.4.14的增量備份恢復還原mysql 5.6
2019-11-04
MySql
MySQL DBA備份工具Xtrabackup使用指南（轉）
2011-10-10
MySql
2.4.14 Step 13: 備份資料庫
2020-03-03
資料庫
【Xtrabackup】Xtrabackup備份基礎知識
2021-01-08
xtrabackup: Error: cannot open /../../base/xtrabackup_checkpoints
2016-02-29
Error
XtraBackup工具詳解 Part 2 xtrabackup安裝
2019-07-16
XtraBackup工具詳解 Part 3 XtraBackup工作原理
2019-07-17
安裝xtrabackup
2016-01-26
【Xtrabackup】Xtrabackup全備、增量備份及恢復示例
2021-01-08
XtraBackup工具詳解 Part 4 XtraBackup許可權及配置
2019-07-17
MySQL：xtrabackup備份
2023-05-16
MySql
RHEL安裝Xtrabackup
2018-04-12
MySQL Percona XtraBackup
2017-10-26
MySql
XtraBackup備份MySQL
2014-02-17
MySql
Percona XtraBackup 2.4 xtrabackup全量、增量備份恢復流程
2016-08-18
MySQL 備份軟體 Xtrabackup 的 xtrabackup_binlog_pos_innodb和xtrabackup_binlog_info 檔案區別
2014-10-09
MySql
MySQL8.0之XtraBackup
2019-09-27
MySql
xtrabackup備份mysql innodb
2014-03-19
MySql
Xtrabackup安裝及使用
2015-05-12
XtraBackup實踐(一)備份
2018-01-05
mysql xtrabackup 遭遇嚴重bug
2011-06-13
MySql
Xtrabackup備份恢復原理
2016-03-09
XtraBackup 搭建從庫的一般步驟及 XtraBackup 8.0 的注意事項
2022-06-06
SQLT 使用指南
2020-03-16
SQL
Lombok使用指南
2020-08-12
Lombok
Rundeck使用指南
2019-04-09
git使用指南
2018-08-05
Git
gulp 使用指南
2018-10-15
SOAR 使用指南
2018-10-26
FontAwesome使用指南
2018-07-18
OpenSUSE 使用指南
2021-01-04
gulp使用指南
2022-11-24
JMH 使用指南
2021-11-04
GPG 使用指南
2021-11-27
nmap使用指南
2022-03-26
Vim使用指南
2018-03-23
Charles使用指南
2017-11-12
CppUnit使用指南
2017-11-15

Xtrabackup 2.4.14使用指南

相關文章