上一篇簡單介紹了percona-xtrabackup的安裝，percona-xtrabackup安裝（一），這篇主要介紹innobackupex的工作以及實現原理和具體的使用等。
xtrabackup包含兩個工具：xtrabackup和innobackupex。
1 xtrabackup只能備份innodb和xtradb兩種引擎的表，不能備份myisam引擎的表；
2 innobackupex是一個封裝了xtrabackup的Perl腳本，支持同時備份innodb和myisam引擎的表，但在對myisam引擎的表備份時需要加一個全局的讀鎖。還有就是對於myisam引擎的表不支持增量備份。
innobackupex is a script written in Perl that wraps the xtrabackup and performs the tasks where the performance and efficiency of C program isn’t needed. In this way, it provides a convenient and integrated approach to backing up in many common scenarios.
1.Making a Backup If no mode is specified, innobackupex will assume the backup mode.
2.By default, it starts xtrabackup with the --suspend-at-end option, and lets it copy the InnoDB data files. When xtrabackup finishes that, innobackupex sees it create the xtrabackup_suspended_2 file and executes FLUSH TABLES WITH READ LOCK. Then it begins copying the rest of the files.
3.innobackupex will then check MySQL variables to determine which features are supported by server. Special interest are backup locks, changed page bitmaps, GTID mode, etc. If everything goes well, the binary is started as a child process.
4.innobackupex will wait for slaves in a replication setup if the option --safe-slave-backup is set and will flush all tables with READ LOCK, preventing all MyISAM tables from writing (unless option --no-lock is specified).
Note: Locking is done only for MyISAM and other non-InnoDB tables, and only after Percona XtraBackup is finished backing up all InnoDB/XtraDB data and logs.
5.Once this is done, the backup of the files will begin. It will backup .frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM,.ARZ, .CSM, .CSV, .par, and .opt files.
6.When all the files are backed up, it resumes ibbackup and wait until it finishes copying the transactions done while the backup was done. Then, the tables are unlocked, the slave is started (if the option --safe-slave-backup was used) and the connection with the server is closed. Then, it removes the xtrabackup_suspended_2 file and permits xtrabackup to exit.
上述步驟完成之後，會在目標目錄生產以下文件
xtrabackup_checkpoints containing the LSN and the type of backup;
xtrabackup_binlog_info containing the position of the binary log at the moment of backing up;
xtrabackup_binlog_pos_innodb containing the position of the binary log at the moment of backing up relative to InnoDB transactions;
xtrabackup_slave_info containing the MySQL binlog position of the master server in a replication setup via SHOW SLAVE STATUS if the --slave-info option is passed;
backup-my.cnf containing only the my.cnf options required for the backup. For example, innodb_data_file_path, innodb_log_files_in_group, innodb_log_file_size, innodb_fast_checksum, innodb_page_size, innodb_log_block_size;
xtrabackup_binary containing the binary used for the backup;
mysql-stderr containing the STDERR of mysqld during the process and
mysql-stdout containing the STDOUT of the server.
Note that the STDERR of innobackupex is not written in any file. You will have to redirect it to a file, e.g., innobackupex OPTIONS 2> backupout.log.
innobackupex備份時候會讀取my.cnf中的配置選項datadir, innodb_data_home_dir, innodb_data_file_path,innodb_log_group_home_dir
一、使用xtrabackup進行備份
創建備份用戶
mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 's3cret'; Query OK, 0 rows affected (0.49 sec) mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT,PROCESS ON *.* TO 'bkpuser'@'localhost'; Query OK, 0 rows affected (0.00 sec) mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.35 sec)
1.1備份類型 （全備）
Creating a Backup
[root@ora12c backup]# xtrabackup --user=bkpuser --password=s3cret --socket=/tmp/mysql.sock --backup --target-dir=/oracle/app/backup/base ...... xtrabackup: Transaction log of lsn (2536404) to (2536413) was copied. 170726 17:11:44 completed OK! [root@ora12c backup]# ls -l base/ total 12340 -rw-r----- 1 root root 426 Jul 26 17:11 backup-my.cnf -rw-r----- 1 root root 313 Jul 26 17:11 ib_buffer_pool -rw-r----- 1 root root 12582912 Jul 26 17:11 ibdata1 drwxr-x--- 2 root root 4096 Jul 26 17:11 mysql drwxr-x--- 2 root root 4096 Jul 26 17:11 performance_schema drwxr-x--- 2 root root 12288 Jul 26 17:11 sys drwxr-x--- 2 root root 4096 Jul 26 17:11 test drwxr-x--- 2 root root 4096 Jul 26 17:11 xtra -rw-r----- 1 root root 21 Jul 26 17:11 xtrabackup_binlog_info -rw-r----- 1 root root 113 Jul 26 17:11 xtrabackup_checkpoints -rw-r----- 1 root root 526 Jul 26 17:11 xtrabackup_info -rw-r----- 1 root root 2560 Jul 26 17:11 xtrabackup_logfile
1.2準備備份
Preparing the backup
這個過程就是使得備份達到一致性。類似oracle的recover過程，但是根據prepare時使用參數的不同有所不同，--apply-log 和--apply-log-only
After you make a backup with --backup, the next step is to prepare it. The data files are not point-in-time consistent until they’ve been prepared, because they were copied at different times as the program ran, and they might have been changed while this was happening. If you try to start InnoDB with these data files, it will detect corruption and crash itself to prevent you from running on damaged data. The --prepare step makes the files perfectly consistent at a
single instant in time, so you can run InnoDB on them.
[root@ora12c backup]# xtrabackup --user=bkpuser --password=s3cret --socket=/tmp/mysql.sock --prepare --target-dir=/oracle/app/backup/base ...... InnoDB: Shutdown completed; log sequence number 2536488 170726 17:31:13 completed OK!
上述步驟執行完之後，備份就是一致的，可以用來進行恢復。如果應用的基礎是增量備份，應該使用-apply-log-only參數
1.3恢復備份
Restoring a Backup
拷貝備份到目標數據目錄（使用cp或者rsync）
如：rsync -avrP /data/backup/ /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
注意;xtrabackup備份的只是InnoDB 數據.
詳細操作步驟如下所示;
[root@ora12c backup]# xtrabackup --user=bkpuser --password=s3cret --socket=/tmp/mysql.sock --backup --target-dir=/oracle/app/backup/base [root@ora12c backup]# xtrabackup --user=bkpuser --password=s3cret --socket=/tmp/mysql.sock --prepare --target-dir=/oracle/app/backup/base mysql> show variables like 'datadir'; +---------------+-----------------------------+ | Variable_name | Value | +---------------+-----------------------------+ | datadir | /oracle/app/mysql-5.7/data/ | +---------------+-----------------------------+ 1 row in set (0.12 sec) mysql> show databases ; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | sys | | test | | xtra | +--------------------+ 6 rows in set (0.16 sec) [root@ora12c backup]# service mysqld stop Shutting down MySQL.... [ OK ] [root@ora12c backup]# mv /oracle/app/mysql-5.7/data/ /oracle/app/mysql-5.7/data-bak [root@ora12c backup]# cp -r /oracle/app/backup/base /oracle/app/mysql-5.7/data/ [root@ora12c backup]# chown -R mysql.mysql /oracle/app/mysql-5.7/data [root@ora12c backup]# service mysqld start Starting MySQL.. [ OK ] mysql> show databases ; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | sys | | test | | xtra | +--------------------+ 6 rows in set (0.00 sec)
二、其他類型備份
增量備份
xtrabackup 和innobackupex都支持增量備份，意味着可以備份自從上次全備之後的改變的數據。因此可以設置每週一全備，其餘天增量備份，或者每天全備，每小時增量備份。
之所以可以進行增量備份，原理如下：
Incremental backups work because each InnoDB page (usually 16kb in size) contains a log sequence number, or LSN.The LSN is the system version number for the entire database. Each page’s LSN shows how recently it was changed.An incremental backup copies each page whose LSN is newer than the previous incremental or full backup’s LSN.There are two algorithms in use to find the set of such pages to be copied. The first one, available with all the server types and versions, is to check the page LSN directly by reading all the data pages. The second one, available with Percona Server, is to enable the changed page tracking feature on the server, which will note the pages as they are being changed. This information will be then written out in a compact separate so-called bitmap file. The xtrabackup binary will use that file to read only the data pages it needs for the incremental backup, potentially saving many read
requests. The latter algorithm is enabled by default if the xtrabackup binary finds the bitmap file. It is possible to specify --incremental-force-scan to read all the pages even if the bitmap data is available.
2.1創建增量備份
增量備份的創建是基於一個全備的，xtrabackup會在備份目錄創建一個xtrabackup_checkpoints文件，包含了to_lsn（數據庫備份結束時的LSN）。
全備
[root@ora12c backup]# xtrabackup -ubkpuser -ps3cret -S/tmp/mysql.sock --backup --target-dir=/oracle/app/backup/base
......
xtrabackup: Transaction log of lsn (2536507) to (2536516) was copied.
170727 10:27:45 completed OK!
[root@ora12c backup]# more base/xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 2536507
last_lsn = 2536516
compact = 0
recover_binlog_info = 0
創建測試數據庫、表
mysql> create database test_increment default character set utf8 ;
Query OK, 1 row affected (0.36 sec)
mysql> create table test (id int(11) NOT NULL AUTO_INCREMENT,email varchar(100) DEFAULT NULL,name varchar(10) DEFAULT NULL,PRIMARY KEY (id)) ;
Query OK, 0 rows affected (0.10 sec)
mysql> insert into test (email,name) values ('[email protected]','a') ;
Query OK, 1 row affected (0.01 sec)
mysql> insert into test (email,name) values ('[email protected]','b') ;
Query OK, 1 row affected (0.67 sec)
mysql> select * from test ;
+----+---------------+------+
| id | email | name |
+----+---------------+------+
| 1 | [email protected] | a |
| 2 | [email protected] | b |
+----+---------------+------+
2 rows in set (0.00 sec)
增量備份一
[root@ora12c backup]# xtrabackup -ubkpuser -ps3cret -S/tmp/mysql.sock --backup --target-dir=/oracle/app/backup/incr1 --incremental-basedir=/oracle/app/backup/base
xtrabackup: Transaction log of lsn (2555122) to (2555131) was copied.
170727 10:41:06 completed OK!
/oracle/app/backup/incr1包含delta files,類似ibdata1.delta 和test/table1.ibd.delta，這些代表從
上次LSN之後的變化
[root@ora12c backup]# more incr1/xtrabackup_checkpoints
backup_type = incremental
from_lsn = 2536507
to_lsn = 2555122
last_lsn = 2555131
compact = 0
recover_binlog_info = 0
表更新
mysql> insert into test (email,name) values ('[email protected]','c') ;
Query OK, 1 row affected (0.35 sec)
mysql> insert into test (email,name) values ('[email protected]','d') ;
Query OK, 1 row affected (0.02 sec)
mysql> select * from test ;
+----+---------------+------+
| id | email | name |
+----+---------------+------+
| 1 | [email protected] | a |
| 2 | [email protected] | b |
| 3 | [email protected] | c |
| 4 | [email protected] | d |
+----+---------------+------+
4 rows in set (0.00 sec)
mysql> delete from test where id = 1 ;
^[[AQuery OK, 1 row affected (0.42 sec)
mysql> select * from test ;
+----+---------------+------+
| id | email | name |
+----+---------------+------+
| 2 | [email protected] | b |
| 3 | [email protected] | c |
| 4 | [email protected] | d |
+----+---------------+------+
3 rows in set (0.00 sec)
增量備份二
[root@ora12c backup]# xtrabackup -ubkpuser -ps3cret -S/tmp/mysql.sock --backup --target-dir=/oracle/app/backup/incr2 --incremental-basedir=/oracle/app/backup/incr1
.....
xtrabackup: Transaction log of lsn (2560224) to (2560233) was copied.
170727 10:55:09 completed OK!2.2準備增量備份
Preparing the Incremental Backups
The --prepare step for incremental backups is not the same as for normal
backups. In normal backups, two types of operations are performed to make the database consistent: committed transactions are replayed from the log file against the data files, and uncommitted transactions are rolled back. You must skip the rollback of uncommitted transactions when preparing a backup, because transactions that were uncommitted
at the time of your backup may be in progress, and it’s likely that they will be committed in the next incremental backup. You should use the --apply-log-only option to prevent the rollback phase.
對於增量備份，在prepare的時候，使用--apply-log-only參數阻止事務回滾階段。
[root@ora12c backup]# xtrabackup -ubkpuser -ps3cret -S/tmp/mysql.sock --prepare --apply-log-only --target-dir=/oracle/app/backup/base ...... InnoDB: Shutdown completed; log sequence number 2536525 InnoDB: Number of pools: 1 170727 11:00:47 completed OK! 應用第一次增量備份至全備上 [root@ora12c backup]# xtrabackup -ubkpuser -ps3cret -S/tmp/mysql.sock --prepare --apply-log-only --target-dir=/oracle/app/backup/base --incremental-dir=/oracle/app/backup/incr1 ...... InnoDB: Allocated tablespace ID 21 for sys/sys_config, old maximum was 0 xtrabackup: page size for /oracle/app/backup/incr1//ibdata1.delta is 16384 bytes Applying /oracle/app/backup/incr1//ibdata1.delta to ./ibdata1... xtrabackup: page size for /oracle/app/backup/incr1//sys/sys_config.ibd.delta is 16384 bytes ...... 170727 11:10:33 completed OK! [root@ora12c backup]# ls -l base/ total 20536 -rw-r----- 1 root root 426 Jul 27 10:27 backup-my.cnf -rw-r----- 1 root root 313 Jul 27 10:27 ib_buffer_pool -rw-r----- 1 root root 12582912 Jul 27 11:10 ibdata1 drwxr-x--- 2 root root 4096 Jul 27 11:10 mysql drwxr-x--- 2 root root 4096 Jul 27 11:10 performance_schema drwxr-x--- 2 root root 12288 Jul 27 11:10 sys drwxr-x--- 2 root root 4096 Jul 27 11:10 test drwxr-x--- 2 root root 4096 Jul 27 11:10 test_increment drwxr-x--- 2 root root 4096 Jul 27 11:10 xtra -rw-r----- 1 root root 22 Jul 27 11:10 xtrabackup_binlog_info -rw-r--r-- 1 root root 22 Jul 27 11:10 xtrabackup_binlog_pos_innodb -rw-r----- 1 root root 111 Jul 27 11:10 xtrabackup_checkpoints -rw-r----- 1 root root 562 Jul 27 11:10 xtrabackup_info -rw-r----- 1 root root 8388608 Jul 27 11:00 xtrabackup_logfile 可以看到全備目錄已經有了第一次全備之後創建的數據庫test_increment。 如果此時從/oracle/app/backup/base恢復備份，你應該可以看到第一次增量備份之後的數據庫狀態。 應用第二次增量備份至全備上 [root@ora12c backup]# xtrabackup -ubkpuser -ps3cret -S/tmp/mysql.sock --prepare --target-dir=/oracle/app/backup/base --incremental-dir=/oracle/app/backup/incr2
Note: --apply-log-only should be used when merging all incrementals except the last one. That’s why the previous line doesn’t contain the --apply-log-only option. Even if the --apply-log-only was used on the last step, backup would still be consistent but in that case server would perform the rollback phase.
2.3恢復備份
[root@ora12c backup]# service mysqld stop Shutting down MySQL..... [ OK ] [root@ora12c backup]# mv /oracle/app/mysql-5.7/data /oracle/app/mysql-5.7/data-bak [root@ora12c backup]# cp -r /oracle/app/backup/base /oracle/app/mysql-5.7/data [root@ora12c backup]# chown -R mysql.mysql /oracle/app/mysql-5.7/data [root@ora12c backup]# service mysqld start Starting MySQL... [ OK ] mysql> select * from test ; ERROR 2006 (HY000): MySQL server has gone away No connection. Trying to reconnect... Connection id: 2 Current database: test_increment +----+---------------+------+ | id | email | name | +----+---------------+------+ | 2 | [email protected] | b | | 3 | [email protected] | c | | 4 | [email protected] | d | +----+---------------+------+ 3 rows in set (0.45 sec)