Percona XtraBackup 備份還原篇

 

Percona XtraBackup 安裝介紹篇已經對Percona XtraBackup的功能和安裝作了比較詳細的介紹，那麼本篇咱們直接進入主題，如何使用XtraBackup作備份、還原，下面主要介紹XtraBackup備份還原操做的細節和場景，疏漏之處不免存在，若有不足，敬請指出。本篇暫時不作原理介紹，後續篇章"Percona XtraBackup 原理分析篇"再作介紹。

 

 

 

 

XtraBackup完整備份

 

備份的權限

 

    使用XtraBack作備份，須要鏈接到數據庫服務器並在服務器上有相關目錄操做權限，因此必需要有數據庫的相關操做權限以及相關目錄執行READ、WRITE以及EXECUTE（執行innobackupex 或xtrabackup 命令）的系統權限。下面咱們來簡單介紹一下：

 

    數據庫所需的一些權限請參考下面表格，細節部分能夠參考官方文檔。此處不詳細闡述！

   

   

MySQL 數據庫權限	權限描述
RELOAD/ LOCK TABLES	RELOAD權限是管理員級別權限，用來執行flush-hosts, flush-logs, flush-privileges, flush-status, flush-tables,flush-threads, refresh, reload等命令的權限。XtraBackup在複製文件以前，必須先執行 FLUSH TABLES WITH READ LOCK和 FLUSH ENGINE LOGS等
REPLICATION CLIENT	此權限是爲了獲取二進制日誌位置（Position）
CREATE TABLESPACE	此權限是爲了導入表
PROCESS	此權限是由於要運行SHOW ENGINE INNODB STATUS命令，以及查看服務器上全部運行的線程。
SUPER	此權限是爲了開啓、關閉複製環境中的slave threads
CREATE	不是必須，Percon Server數據庫才須要的。建立PERCONA_SCHEMA.xtrabackup_history的須要
INSERT	不是必須，跟上面權限同樣，須要往PERCONA_SCHEMA.xtrabackup_history插入記錄
SELECT	不是必須，跟上面權限同樣，須要查詢ERCONA_SCHEMA.xtrabackup_history中的記錄

   

 

固然所需的最小權限以下所示，注意：這個僅僅是最小權限，實際狀況中最好根據實際需求授予最小權限。不要放大沒必要要的權限。

 

 

mysql> use mysql;

Database changed

mysql> CREATE USER 'backuser'@'localhost' IDENTIFIED BY 'kkk123456';

Query OK, 0 rows affected (0.00 sec)

mysql> GRANT RELOAD, LOCK TABLES,PROCESS, REPLICATION CLIENT ON *.* TO 'backuser'@'localhost';

Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;

Query OK, 0 rows affected (0.00 sec)

mysql> 

 

 

若是上面的權限不夠的話，可使用下面受權語句。

 

 

GRANT RELOAD, LOCK TABLES,PROCESS, REPLICATION CLIENT, CREATE TABLESPACE,SUPER ON *.* TO 'backuser'@'localhost';

 

 

系統帳號受權相關目錄的操做權限。以下所示：

 

 

[root@DB-Server ~]# chown -R mysql:mysql /data

[root@DB-Server ~]# su - mysql

-bash-3.2$ 

 

 

 

完整備份

 

 

 經常使用的完整備份（全備）命令以下所示

 

innobackupex  --user=backuser --password=kkk123456  /u02/mysql_backup/full/

innobackupex  --user=root --password=123456  /u02/mysql_backup/full/

innobackupex --defaults-file=/usr/my.cnf --user=backuser --password=kkk123456  /u02/mysql_backup/full

innobackupex --defaults-file=/usr/my.cnf --socket=/var/lib/mysql/mysql.sock --user=backuser --password=kkk123456  /u02/mysql_backup/full

參數--no-timestamp 表示不生成帶時間戳的目錄

innobackupex  --user=backuser --password=kkk123456  /u02/mysql_backup/full/ --no-timestamp

 

 注意：若是你指定了參數--defaults-file，那麼此參數就必須位於第一個，不然就會報「--defaults-file must be specified first on the command line」

 

 

 咱們先在測試數據庫MyDB建立一個測試表，插入幾條數據，後面作還原測試驗證使用。

 

mysql> use MyDB;

Database changed

mysql> create table test(id  int primary key);

Query OK, 0 rows affected (0.13 sec)

mysql> insert into test

    -> values(1000);

Query OK, 1 row affected (0.01 sec)

mysql> insert into test

    -> values(2000);

Query OK, 1 row affected (0.01 sec)

mysql> insert into test

    -> values(3000);

Query OK, 1 row affected (0.01 sec)

mysql> 

 

 咱們使用下面命令對MySQL作了一個完整備份，那麼默認就會在目錄/u02/mysql_backup/full/下生成一個日期時間格式的全備文件2017-07-19_17-22-45

 

   $ innobackupex --defaults-file=/usr/my.cnf --user=backuser --password=kkk123456  /u02/mysql_backup/full

 

 

 

 

 那麼備份出來的文件以及內容是什麼樣的呢？ 以下所示，你能夠檢查xtrabackup_checkpoints、xtrabackup_binlog_info、xtrabackup_info三個文件瞭解備份的一些詳細信息，例如備份類型、是否壓縮等等。

 

 

[root@DB-Server 2017-07-19_17-39-56]# ls -lrt

total 12380

drwxr-x--- 2 mysql mysql     4096 Jul 19 17:39 test

drwxr-x--- 2 mysql mysql     4096 Jul 19 17:39 performance_schema

drwxr-x--- 2 mysql mysql     4096 Jul 19 17:39 mysql

drwxr-x--- 2 mysql mysql     4096 Jul 19 17:39 MyDB

-rw-r----- 1 mysql mysql 12582912 Jul 19 17:39 ibdata1

-rw-r----- 1 mysql mysql     2560 Jul 19 17:39 xtrabackup_logfile

-rw-r----- 1 mysql mysql      545 Jul 19 17:39 xtrabackup_info

-rw-r----- 1 mysql mysql      113 Jul 19 17:39 xtrabackup_checkpoints

-rw-r----- 1 mysql mysql       25 Jul 19 17:39 xtrabackup_binlog_info

-rw-r----- 1 mysql mysql      418 Jul 19 17:39 backup-my.cnf

[root@DB-Server 2017-07-19_17-39-56]# more xtrabackup_checkpoints 

backup_type = full-backuped

from_lsn = 0

to_lsn = 1637691

last_lsn = 1637691

compact = 0

recover_binlog_info = 0

[root@DB-Server 2017-07-19_17-39-56]# more xtrabackup_binlog_info 

DB-Server-bin.000001    871

[root@DB-Server 2017-07-19_17-39-56]# more xtrabackup_info 

uuid = cfb5c2d8-6cca-11e7-8113-b083fe5532e5

name = 

tool_name = innobackupex

tool_command = --defaults-file=/usr/my.cnf --user=backuser --password=... /u02/mysql_backup/full

tool_version = 2.4.6

ibbackup_version = 2.4.6

server_version = 5.6.20-enterprise-commercial-advanced-log

start_time = 2017-07-19 17:39:56

end_time = 2017-07-19 17:39:58

lock_time = 0

binlog_pos = filename 'DB-Server-bin.000001', position '871'

innodb_from_lsn = 0

innodb_to_lsn = 1637691

partial = N

incremental = N

format = file

compact = N

compressed = N

encrypted = N

 

 

 

 xtrabackup_checkpoints     ： 備份類型信息（徹底備份或增量備份）、LSN(日誌序列號)範圍信息、備份是否壓縮

 xtrabackup_binlog_info     ： 二進制日誌信息,MySQL當前正在使用的二進制日誌文件及至備份這一刻爲止二進制日誌事件的位置。若是沒有開啓二進制日誌，那麼就不會有xtrabackup_binlog_info這個文件。

 xtrabackup_info         ： xtrabackup工具的版本信息、詳細命令、參數以及備份的開始、結束時間。以及備份詳細信息等。

 xtrabackup_logfile      ：

 backup-my.cnf           ： 備份命令用到的配置選項信息。

 

 

如何使用全備恢復還原呢？  以下步驟所示：

 

 

Step 1：Prepare the Backup。

 

 

 

innobackupex  --defaults-file=/usr/my.cnf   --apply-log  /u02/mysql_backup/full/2017-07-19_17-39-56/

 

 

 

Step 2：關閉MySQL服務，備份數據目錄或刪除數據目錄

 

 

 2.1 :  /etc/init.d/mysql stop

 

 2.2 : mv /data/mysql/   /data/mysql_20170719_bak

 

 

Step 3: 恢復數據，將備份數據文件拷貝到數據目錄

 

 

 

 innobackupex  --defaults-file=/usr/my.cnf  --copy-back  /u02/mysql_backup/full/2017-07-19_17-39-56/

 

 若是執行上面命令是在mysql用戶下，而且有權限建立對應目錄，那麼就不須要作任何操做，若是是root帳號，那麼就必須修改對應目錄的Owner，不然啓動MySQL服務會報錯。

 

    chown -R mysql:mysql /data/mysql/*

 

 注意，若是這裏權限沒有處理好，有時候會出現一些莫名其妙的錯誤，例如，設置文件權限時，因爲上面腳本處理的是/data/mysql下面的文件，沒有處理/data/mysql這個目錄的權限，啓動MySQL的時候就報這個錯誤

 

[root@DB-Server data]# ls -lrt

total 40

drwxr-xr-x 6 mysql mysql 4096 Jul 21  2017 mysql_20170719_bak

drwxr-x--- 8 root  root  4096 Jun 25 12:09 mysql

[root@DB-Server data]# service mysql start

Starting MySQL.. ERROR! The server quit without updating PID file (/data/mysql/DB-Server.localdomain.pid).

 

[root@DB-Server data]# chown -R mysql:mysql /data/mysql

[root@DB-Server data]# service mysql start

Starting MySQL... SUCCESS!

 

 

 

Step 4: 測試數據的完整性：

 

[root@DB-Server ~]# service mysql start

Starting MySQL.....[  OK  ]

[root@DB-Server ~]# mysql -u root -p

Enter password: 

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 1

Server version: 5.6.20-enterprise-commercial-advanced-log MySQL Enterprise Server - Advanced Edition (Commercial)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use MyDB;

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

Database changed

mysql> select * from test;

+------+

| id   |

+------+

| 1000 |

| 2000 |

| 3000 |

+------+

3 rows in set (0.00 sec)

 

 

XtraBackup增量備份

 

 

 在闡述Xtrabackup增量備份前，咱們先來看看下面這個增量備份，你能看出其問題嗎？這個備份有啥不妥呢？ 固然在作增量備份前，都有對數據庫進行了一些測試操做。

 

 

完整備份

 

innobackupex --defaults-file=/usr/my.cnf --user=backuser --password=kkk123456  /u02/mysql_backup/full

 

增量備份1

 

innobackupex --defaults-file=/usr/my.cnf --user=root --password=123456 --incremental  --incremental-basedir=/u02/mysql_backup/full/2017-07-24_09-38-32/  /u02/mysql_backup/incr/

 

增量備份2

 

innobackupex --defaults-file=/usr/my.cnf --user=root --password=123456 --incremental  --incremental-basedir=/u02/mysql_backup/full/2017-07-24_09-32-22/   /u02/mysql_backup/incr/

 

 

其實第一次完整備份時，生成了備份目錄2017-07-24_09-38-32； 第一次增量備份時，生成了增量備份目錄2017-07-24_09-40-11，關鍵在於第二次增量備份，--incremental-basedir這個參數的值不該該是第一次完成備份的目錄，而應是增量備份1的備份目錄2017-07-24_09-40-11，以下所示，若是使用了錯誤的參數，增量備份2其實包含了增量備份1的變化部分。

 

 

[root@DB-Server 2017-07-24_09-40-11]# more xtrabackup_info 

uuid = 9f916d24-7075-11e7-8f2e-b083fe5532e5

name = 

tool_name = innobackupex

tool_command = --defaults-file=/usr/my.cnf --user=root --password=... --incremental --incremental-basedir=/u02/mysql_backup/full/2017-07-24_09-38-32/ /u02/mysql_backup/incr/

tool_version = 2.4.6

ibbackup_version = 2.4.6

server_version = 5.6.20-enterprise-commercial-advanced

start_time = 2017-07-24 09:40:12

end_time = 2017-07-24 09:40:14

lock_time = 0

binlog_pos = 

innodb_from_lsn = 1650510

innodb_to_lsn = 1660277

partial = N

incremental = Y

format = file

compact = N

compressed = N

encrypted = N

[root@DB-Server 2017-07-24_09-40-11]# cd ../2017-07-24_09-40-25/

[root@DB-Server 2017-07-24_09-40-25]# more xtrabackup_info 

uuid = a790b642-7075-11e7-8f2e-b083fe5532e5

name = 

tool_name = innobackupex

tool_command = --defaults-file=/usr/my.cnf --user=root --password=... --incremental --incremental-basedir=/u02/mysql_backup/full/2017-07-24_09-38-32/ /u02/mysql_backup/incr/

tool_version = 2.4.6

ibbackup_version = 2.4.6

server_version = 5.6.20-enterprise-commercial-advanced

start_time = 2017-07-24 09:40:25

end_time = 2017-07-24 09:40:28

lock_time = 0

binlog_pos = 

innodb_from_lsn = 1650510

innodb_to_lsn = 1664130

partial = N

incremental = Y

format = file

compact = N

compressed = N

encrypted = N

[root@DB-Server 2017-07-24_09-40-25]# 

 

增量備份注意事項

 

1：--incremental-basedir   

 

    第一次增量備份，--incremental-basedir確定是全備目錄，第二次增量備份，--incremental-basedir爲第一次增量備份目錄，依此類推！

 

2：增量備份僅能應用於InnoDB或XtraDB表，對於MyISAM表而言，執行增量備份時其實進行的是徹底備份。

 

 

3：應用增量備份的時候只能按照備份的順序來應用。若是應用順序錯誤，那麼備份就不可用。若是沒法肯定順序，能夠查看xtrabackup-checkpoints來肯定順序。

 

 

那麼咱們來用案例測試一下增量備份的還原，具體步驟以下所示（這裏咱們使用root帳號來）

 

 

Step 1： 完整備份

 

mysql> use MyDB;

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

Database changed

mysql> create table test (id int, name varchar(12));

Query OK, 0 rows affected (0.01 sec)

mysql> insert into test values(1000, 'kerry');

Query OK, 1 row affected (0.00 sec)

mysql> 

 

執行完整備份

 

innobackupex --default-files=/usr/my.cnf   --user=root --password=123456  /u02/mysql_backup/full/

 

 

 

 

Step 2： 增量備份1

 

mysql> insert into test values(2000, 'ken');

Query OK, 1 row affected (0.00 sec)

 

注意 --incremental-basedir參數應該根據實際狀況肯定

 

innobackupex  --defaults-file=/usr/my.cnf  --user=root --password=123456  --incremental --incremental-basedir=/u02/mysql_backup/full/2017-07-24_16-15-59/ /u02/mysql_backup/incr/

 

 

Step 3：增量備份2:

 

 

mysql> create table big_table (id  int);

Query OK, 0 rows affected (0.13 sec)

mysql> insert into big_table values(10000);

Query OK, 1 row affected (0.00 sec)

mysql> insert into big_table values(20000);

Query OK, 1 row affected (0.00 sec)

mysql> 

 

注意 --incremental-basedir參數應該根據實際狀況肯定

 

innobackupex  --defaults-file=/usr/my.cnf  --user=root --password=123456  --incremental --incremental-basedir=/u02/mysql_backup/incr/2017-07-24_16-17-39/ /u02/mysql_backup/incr/

 

 

 

 

注意：Xtrabackup增量備份時，須要設置參數--incremental-basedir 其實這個參數不是必須的。能夠用--incremental-lsn來替代。

 

 

完整備份後，檢查備份目錄下的xtrabackup_checkpoints文件，找到to_lsn，而後使用下面腳本作增量備份。

 

innobackupex  --user=backuser --password=kkk123456  /u02/mysql_backup/full/

 

[root@DB-Server 2017-07-25_12-49-57]# more xtrabackup_checkpoints

backup_type = full-backuped

from_lsn = 0

to_lsn = 1733142

last_lsn = 1733142

compact = 0

recover_binlog_info = 0

 

innobackupex --user=backuser  --password=kkk123456  --incremental --incremental-lsn=1733142 /u02/mysql_backup/incr/

 

 

而後，咱們先刪除或DROP掉一些數據，模擬數據被誤刪的狀況，而後還原測試驗證。 以下所示：

 

 

mysql> drop table test;

Query OK, 0 rows affected (0.00 sec)

mysql> delete from big_table where id=10000;

Query OK, 1 row affected (0.01 sec)

mysql> 

 

 

Step 1： 恢復徹底備份

 

innobackupex --defaults-file=/usr/my.cnf  --apply-log --redo-only /u02/mysql_backup/full/2017-07-24_16-15-59/

 

 

注意若是後續必須應用增量備份，則必須加上--redo-only. 不然後續不能應用增量備份。這個若是對SQL Server備份還原熟悉的話，原理也是如此。

 

--redo-only

 

If you replay the committed transactions and rollback the uncommitted ones on the base backup, you will not be able

to add the incremental ones. If you do this on an incremental one, you won’t be able to add data from that moment

and the remaining increments。

 

Note: --redo-only should be used when merging all incrementals except the last one. That’s why the previous

line doesn’t contain the --redo-only option. Even if the --redo-only was used on the last step, backup would

still be consistent but in that case server would perform the rollback phase.

 

以下截圖所示，若是在恢復全備時沒有應用參數--redo-only ，後面應用增量備份時就會遇到下面錯誤。只有當最後一個增量備份時，纔不須要--redo-only

 

 

 

 

Step 2：增量備份還原

 

 innobackupex --apply-log --redo-only --incremental /u02/mysql_backup/full/2017-07-24_16-15-59/ \

              --incremental-dir=/u02/mysql_backup/incr/2017-07-24_16-17-39/

 

 

 

注意：增量備份必須按必定順序Apply，不然後面的增量備份都無效了！

 

 

Step 3：增量備份還原

 

innobackupex --apply-log  --incremental /u02/mysql_backup/full/2017-07-24_16-15-59/ \

          --incremental-dir=/u02/mysql_backup/incr/2017-07-24_16-18-57/

 

 

 

 

 

 

 

Step 4： 關閉MySQL服務並移除數據目錄。

 

 

[root@DB-Server ~]# service mysql stop

Shutting down MySQL..[  OK  ]

 

 

 

 

Step 5： 將備份文件拷貝回MySQL數據目錄。

 

 

innobackupex  --defaults-file=/usr/my.cnf  --copy-back /u02/mysql_backup/full/2017-07-24_16-15-59/

 

[root@DB-Server ~]# chown -R mysql:mysql /data/mysql/*

 

 

Step 6： 檢查驗證數據數據恢復狀況。

 

 

[root@DB-Server mysql]# service mysql start

Starting MySQL..........[  OK  ]

mysql> select * from test;

+------+-------+

| id   | name  |

+------+-------+

| 1000 | kerry |

| 2000 | ken   |

+------+-------+

2 rows in set (0.00 sec)

mysql> select * from big_table;

+-------+

| id    |

+-------+

| 10000 |

| 20000 |

+-------+

2 rows in set (0.00 sec)

 

 

 

XtraBackup備份高級選項

 

 

Compact Backups

 

 

 

1:緊湊型備份（compact backups）指在備份InnoDB tables時， 能夠不備份二級索引（Secondary index)數據頁，這樣使得備份更加緊湊，從而能夠減小備份的大小。缺點是備份準備過程（Prepare）須要更長的時間才能重建這些二級索引(secondary indexes)。

 

 

2：系統表空間不支持緊湊型備份（Compact backups）,因此若是要使用Compact backups，那麼就必須設置變量innodb_file_per_table爲ON

 

innobackupex --user=backuser  --password=kkk123456  --compact  /u02/mysql_backup/full/

 

以下所示，你檢查xtrabackup_checkpoints 就會發現compact爲1， xtrabackup_info裏面compact值爲Y

 

 

 

注意：

發現Xtrabackup有個有意思的現象，例以下面備份腳本，參數 --compat弄錯了，執行也不報錯，只是緊湊型備份沒有生效。

 

 

 

 

Partial Backups

 

Percona Xtrabackup提供部分備份，這意味着你能夠只備份一些特定表或數據庫，不過部分備份（Partial Backups）是有諸多限制和前提的。

 

1： 若是要使用部分備份（Partial Backups），前提條件是你備份的表必須在單獨的表空間中。你必須在服務器上啓動innodb_file_per_table。

 

2： 部分備份（Partial Backups）是不支持--stream選項，即不支持將數據經過管道傳輸給其它程序進行處理。

 

3： 還原部分備份跟還原完整備份也有所不一樣，即你不能經過簡單地將prepared的部分備份使用--copy-back選項直接複製回數據目錄，而是要經過導入表的方向來實現還原。儘管有時簡單的拷貝備份文件能夠成功，可是這種方法很容易致使數據庫的不一致，所以不推薦你們這麼作。

 

 

 

建立部分備份（Creating Partial Backups）

 

 

部分備份共有三種方式，分別是：1. 用正則表達式表示要備份的庫名及表名（參數爲--include）；2. 將要備份的表名或庫名都寫在一個文本文件中（參數爲--tables-file）以及 3. 將要備份表名或庫名完整的寫在命令行中（參數爲：--databases）。（譯者注：無論你備份哪一個庫或是哪張表，強烈推薦把mysql庫也一塊兒備份，恢復的時候要用。）

 

對數據庫進行部分備份有三種方式：正則表達式(--include), 枚舉表文件(--tables-file)和列出要備份的數據庫(--databases)

 

方法1：使用正則表達式

 

innobackupex --defaults-file=/usr/my.cnf  --user=backuser  --password=kkk123456  --include='^MyDB[.]kkk'   /u02/mysql_backup/part/

 

 

 

方法2：枚舉表文件(--tables-file)

 

# cat >back_table.txt

MyDB.test

MyDB.kkk

 

innobackupex --defaults-file=/usr/my.cnf  --user=backuser  --password=kkk123456   --tables-file=/u02/mysql_backup/back_table.txt  /u02/mysql_backup/part

 

 

 

方法3： 經過參數--database 指定須要備份的表

 

–database選項能夠直接指定須要備份的」表」和」庫」名,或指定一個包含所需備份表名的列表文件。

 

innobackupex --defaults-file=/usr/my.cnf  --user=backuser  --password=kkk123456   --databases="MyDB.test MyDB.kkk"  /u02/mysql_backup/part

 

 

準備部分備份（Preparing Partial Backups）

 

 

innobackupex  --apply-log --export /u02/mysql_backup/part/2018-06-27_16-49-59

 

 

 

 

恢復部分備份（Restoring Partial Backups）

 

innobackupex  --apply-log --export /u02/mysql_backup/part/2018-06-27_16-49-59

 

此時就會生成對應表的exp文件

 

 

導入表操做：

 

假設因爲誤操做，將表TEST的數據TRUNCATE掉了。

 

mysql> select * from test;

+------+-------+

| id   | name  |

+------+-------+

| 1000 | kerry |

| 2000 | ken   |

+------+-------+

2 rows in set (0.00 sec)

mysql> truncate table test;

Query OK, 0 rows affected (0.12 sec)

mysql> 

 

2:咱們discard tablespace

 

mysql> alter table test discard tablespace;

Query OK, 0 rows affected (0.03 sec)

 

3: copy test表的ibd、cfg、exp文件

 

# cp  /u02/mysql_backup/part/2018-06-27_16-49-59/MyDB/test.ibd  /data/mysql/MyDB

# cp  /u02/mysql_backup/part/2018-06-27_16-49-59/MyDB/test.cfg  /data/mysql/MyDB

# cp  /u02/mysql_backup/part/2018-06-27_16-49-59/MyDB/test.exp  /data/mysql/MyDB

 

4： 導入表空間

 

mysql> alter table test import tablespace;

Query OK, 0 rows affected (0.03 sec)

 

5：驗證測試是否成功

 

 

 

 

 

基於tar格式備份

 

流備份打包

innobackupex --user=backuser --password=kkk123456   --stream=tar /tmp  > /u02/mysql_backup/full/backup_20170725.tar

xbstream流備份打包壓縮

innobackupex --user=root  --password=123456  --stream=tar /tmp  | gzip >  /u02/mysql_backup/full/backup_20170725.tar.gz

備份到遠程

 

 

  中間還有很長一段內容，被我刪除了，文章寫得太長、太冗餘，有點相似於技術手冊了，估計也沒有人看；另一方面，不少細節問題尚未仔細驗證過， 因此放在本身的筆記本中，慢慢完善！

 

 

Innobackupex部分參數介紹

 

 

查看innobackupex與xtrabackup的參數，可使用下面命令：

 

#innobackupex --help

#xtrabackup

 

innobackupex的的部分參數介紹以下（有些不經常使用參數沒來及整理，後續再慢慢補充）

 

 

 

  -v, --version          

    輸出xtrabackup的版本信息

  -?, --help          

    輸出、顯示幫助信息而後退出

--defaults-file

    默認配置文件的路徑，若是不指定該參數，xtrabackup將從依次從如下位置查找配置文件/etc/my.cnf、/etc/mysql/my.cnf、/usr/local/etc/my.cnf、~/.my.cnf，並讀取配置文件中的[mysqld]和[xtrabackup]配置段。[mysqld]中只須要指定datadir、innodb_data_home_dir、innodb_data_file_path、innodb_log_group_home_dir、innodb_log_files_in_group、innodb_log_file_size6個參數便可讓xtrabackup正常工做。

    注意：指定要備份的mysql實例的my.cnf文件，必須爲第一個選項

  --apply-log         

    該參數是對xtrabackup的參數--prepare的封裝。 通常狀況下,在備份完成後，數據尚且不能用於恢復操做，由於備份的數據中可能會包含還沒有提交的事務或已經提交但還沒有同步至數據文件中的事務。所以，此時數據文件仍處理不一致狀態。--apply-log的做用是經過回滾未提交的事務及同步已經提交的事務至數據文件使數據文件處於一致性狀態。

  --redo-only

    這個選項在prepare base full backup，往其中merge增量備份（但不包括最後一個）時候使用。This forces xtrabackup to skip the "rollback" phase and do a "redo" only

  --copy-back

    作數據恢復時將備份數據文件拷貝到MySQL服務器的datadir目錄;

  --move-back  

    將全部文件從之前建立的備份目錄移動到事情數據目錄， 使用此選項必須當心， 由於它會刪除備份文件。

  --galera-info  

    該選項建立xtrabackup_galera_info文件， 其中包含備份當時的本地節點狀態。 執行Percona-XtraDB-Cluster備份時應使用此選項。 

  --slave-info  

    該選項表示對slave進行備份的時候使用，打印出master的名字和binlog pos，一樣將這些信息以change master的命令寫入xtrabackup_slave_info文件。能夠經過基於這份備份啓動一個從庫。

  --incremental 

    創建增量備份

  --no-lock

    該選項表示關閉FTWRL的表鎖，只有在全部表都是Innodb表而且不關心backup的binlog pos點，若是有任何DDL語句正在執行或者非InnoDB正在更新時（包括mysql庫下的表），都不該該使用這個選項，後果是致使備份數據不一致，若是考慮備份由於得到鎖失敗，能夠考慮--safe-slave-backup馬上中止複製線程。 

    不容許使用flush tables with read lock表鎖。若是你的全部表示INNODB而且你不關心二進制日誌備份的位置。若是有任何DDL語句被執行或任何非INNODB表上的update操做，這個選項就不能使用

  --safe-slave-backup 

    中止從SQL進程並等待啓動備份直到slave_open_temp_tables的值爲0。若是沒有打開臨時表，備份會進行，不然SQL進程將啓動並直到沒有打開的臨時表時中止。若是slave_open_temp_tables在--

safe-slave-backup-timeout秒後沒有變成0，則備份會失敗。備份結束後，從SQL進程將從新啓動。

  --rsync

表示經過rsync工具優化本地傳輸，當指定這個選項，innobackupex使用rsync拷貝非Innodb文件而替換cp，當有不少DB和表的時候會快不少，不能--stream一塊兒使用。

  --force-non-empty-directories 

 使用此選項，就能夠經過--copy-back或--move-back 將文件拷貝或移動到非空目錄。

                 This option, when specified, makes --copy-back or

                      --move-back transfer files to non-empty directories. Note

                      that no existing files will be overwritten. If

                      --copy-back or --nove-back has to copy a file from the

                      backup directory which already exists in the destination

                      directory, it will still fail with an error.

  --no-timestamp

該選項能夠表示要不要建立一個時間戳目錄來存儲備份，指定到本身想要的備份文件夾。指定了這個選項，備份會直接備份在BACKUP-DIR，再也不建立時間戳文件夾

  --no-version-check

禁止版本檢查

  --no-backup-locks

  --decompress

  -u, --user=name 

該選項表示備份帳號。

  -H, --host=

該選項表示備份數據庫的地址。

  -p, --password

該選項表示備份帳號的密碼。

  -P, --port=#

該選項表示當前須要備份數據庫的使用的端口。

  -S, --socket

此選項指定鏈接本地數據庫時使用的套接字，此選項接受一個字符串參數。

  --incremental-history-name=name 

該選項表示存儲在PERCONA_SCHEMA.xtrabackup_history基於增量備份的歷史記錄的名字。Percona Xtrabackup搜索歷史表查找最近（innodb_to_lsn）成功備份而且將to_lsn值做爲增量備份啓動出事lsn.與innobackupex--incremental-history-uuid互斥。若是沒有檢測到有效的lsn，xtrabackup會返回error。

  --incremental-history-uuid=name 

  --decrypt=name 

  --ftwrl-wait-query-type=name

  --kill-long-query-type=name 

  --history[=name] 

  --include=name

  --databases

該選項表示須要備份的數據庫,若是沒有指定該參數，表示備份所有數據庫。若是要指定多個數據庫，彼此間須要以空格隔開；如："mydb1 mydb2"，同時，在指定某數據庫時，也能夠只指定其中的某張表。如："mydatabase.mytable"。該選項對innodb引擎表無效，仍是會備份全部innodb表。此外，此選項也能夠接受一個文件爲參數，文件中每一行爲一個要備份的對象。

  --kill-long-queries-timeout=#

  --ftwrl-wait-timeout=# 

  --ftwrl-wait-threshold=# 

  --debug-sleep-before-unlock=#

  --safe-slave-backup-timeout=# 

  --close-files  

  --compact

該選項表示建立一份沒有輔助索引的緊湊的備份。

指在備份InnoDB tables時， 能夠不備份二級索引（Secondary index)數據頁，這樣使得備份更加緊湊，從而能夠減小備份的大小。缺點是備份準備過程（Prepare）須要更長的時間才能重建這些二級索引(secondary indexes)。

  --compress[=name]

對備份數據進行行壓縮

  --compress-threads=# 

指定備份壓縮的線程數量。

  --compress-chunk-size=#

  --encrypt=name 

  --encrypt-key=name 

  --encrypt-key-file=name 

  --encrypt-threads=#

  --encrypt-chunk-size=# 

  --export 

  --extra-lsndir=name

  --incremental-basedir=name 

    指定一個全庫備份的目錄做爲增量備份的基礎數據庫 。

與--incremental同時使用。

  --incremental-dir=name

    該選項表示增量備份的目錄。

  --incremental-force-scan 

    該選項表示建立一份增量備份時，強制掃描全部增量備份中的數據頁。

  --log-copy-interval=# 

  --incremental-lsn=name 

    該選項表示指定增量備份的LSN，與--incremental選項一塊兒使用。

  --parallel

  --rebuild-indexes 

  --rebuild-threads=#  

  --stream

    該選項表示流式備份的格式，backup完成以後以指定格式到STDOUT，目前只支持tar和xbstream。

    備份文件輸出格式, tar時使用tar4ibd , 該文件可在XtarBackup binary文件中得到.若是備份時有指定--stream=tar, 則tar4ibd文件所處目錄必定要在$PATH中(由於使用的是tar4ibd去壓縮, 在XtraBackup的binary包中可得到該文件)。

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

  --tables-file

    該選項表示指定含有表列表的文件，格式爲database.table，該選項直接傳給--tables-file。

  --throttle

    每秒IO次數,限制backup時使用的I/O操做量，使備份對數據庫正常業務的影響最小化

  -t, --tmpdir=name 

  --use-memory

    指定備份所用內存大小。

 

 

 

 

XtraBackup問題集合

 

 

1：沒有開啓二進制日誌，那麼Xtrabackup有什麼問題沒？

 

 

2：xtrabackup:  Check 'to_lsn' of the target and 'from_lsn' of the incremental.

 

 

[root@DB-Server ~]# innobackupex --apply-log  --incremental /u02/mysql_backup/full/2017-07-24_12-58-25/  --incremental-dir=/u02/mysql_backup/incr/2017-07-24_13-02-32/

170724 13:27:34 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!".

innobackupex version 2.4.6 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 8ec05b7)

incremental backup from 1685892 is enabled.

xtrabackup: cd to /u02/mysql_backup/full/2017-07-24_12-58-25/

xtrabackup: This target seems to be already prepared with --apply-log-only.

xtrabackup: error: This incremental backup seems not to be proper for the target.

xtrabackup:  Check 'to_lsn' of the target and 'from_lsn' of the incremental.

 

 

 

 

注意紅色部分，因爲粗心，路徑錯誤，致使出現下面錯誤信息：

 

[root@DB-Server full]# innobackupex --defaults-file=/usr/my.cnf --user=root  --password=123456 \

       --stream=tar /tmp  | gzip >  u02/mysql_backup/full/backup_20170725.tar.gz

-bash: u02/mysql_backup/full/backup_20170725.tar.gz: No such file or directory

170725 16:57:35 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!".

 

170725 16:57:35  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup' as 'root'  (using password: YES).

170725 16:57:35  version_check Connected to MySQL server

170725 16:57:35  version_check Executing a version check against the server...

170725 16:57:35  version_check Done.

170725 16:57:35 Connecting to MySQL server host: localhost, user: root, password: set, port: not set, socket: not set

Using server version 5.6.20-enterprise-commercial-advanced-log

innobackupex version 2.4.6 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 8ec05b7)

xtrabackup: uses posix_fadvise().

xtrabackup: cd to /data/mysql

xtrabackup: open files limit requested 0, set to 1024

xtrabackup: using the following InnoDB configuration:

xtrabackup:   innodb_data_home_dir = .

xtrabackup:   innodb_data_file_path = ibdata1:12M:autoextend

xtrabackup:   innodb_log_group_home_dir = ./

xtrabackup:   innodb_log_files_in_group = 2

xtrabackup:   innodb_log_file_size = 50331648

InnoDB: Number of pools: 1

170725 16:57:35 >> log scanned up to (1737354)

xtrabackup: Generating a list of tablespaces

InnoDB: Allocated tablespace ID 4 for mysql/slave_master_info, old maximum was 0

innobackupex: Error writing file 'UNOPENED' (Errcode: 32 - Broken pipe)

archive_write_header() failed.

[01] xtrabackup: error: cannot open the destination stream for ibdata1

[01] xtrabackup: Error: xtrabackup_copy_datafile() failed.

[01] xtrabackup: Error: failed to copy datafile.

 

 

The datadir must be empty before restoring the backup. Also it’s important to note that MySQL server needs

to be shut down before restore is performed. You can’t restore to a datadir of a running mysqld instance (except when

importing a partial backup).

 

 

3：版本不支持的狀況，例如 Percona-XtraBackup-2.3.4 不支持MySQL 5.7.21

 

 

# innobackupex  --default-file=/usr/my.cnf --user=root --password="QwEr@123456" --app-log /tmp/fullbackup/

180613 16:36:39 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!".

180613 16:36:39  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/var/lib/mysql/mysql.sock' as 'root'  (using password: YES).

180613 16:36:39  version_check Connected to MySQL server

180613 16:36:39  version_check Executing a version check against the server...

180613 16:36:39  version_check Done.

180613 16:36:39 Connecting to MySQL server host: localhost, user: root, password: set, port: 0, socket: /var/lib/mysql/mysql.sock

Error: Unsupported server version: '5.7.21'. Please report a bug at https://bugs.launchpad.net/percona-xtrabackup

 

 

 

 

 

 

後續感言：一直想全面總結XtraBackup備份，就一直在拖拖拉拉，原本2017年7月份就總結了這篇文章的大部分知識點，可是老是感受這部分的知識點沒有總結，那部分知識點沒有測試，一直拖拖拉拉，其實哪裏可能面面俱到的總結到位，可以涵蓋大部分就能夠。不完美才是技術文章的哲學形態！後續遇到了相關案例，再慢慢完善。