XtraBackup 搭建從庫的一般步驟及 XtraBackup 8.0 的注意事項

iVictor發表於2022-06-06

搭建從庫，本質上需要的只是一個一致性備份集及這個備份集對應的位置點資訊。之前介紹的幾個備份工具（ MySQL中如何選擇合適的備份策略和備份工具）均可滿足。

這裡，我們重點看看如何基於 XtraBackup 搭建從庫。

整個過程其實比較簡單，無非是備份還原。唯一需要注意的是建立複製時位置點的選擇，包括：

在基於位置點的複製中，CHANGE MASTER TO 語句中 MASTER_LOG_FILE 和 MASTER_LOG_POS 的選擇。
在 GTID 複製中，在執行 CHANGE MASTER TO 命令之前，必須首先設定 GTID_PURGED。

尤其是在 MySQL 8.0 中，得益於 performance_schema.log_status 的引入（注意，不是備份鎖），XtraBackup 8.0 在備份的過程中不再加全域性讀鎖。

而備份集對應的位置點資訊，是 XtraBackup 8.0 在備份結束時查詢 performance_schema.log_status 獲取的，包括 GTID 和 Binlog 的位置點。

理論上，備份集裡儲存的 GTID 和 Binlog 位置點，指向的應該是同一個事務。

但在 XtraBackup 8.0 中，卻並非如此。

由此帶來的問題是，在 GTID 複製中，如果我們還是按照 MySQL 5.6，5.7（對應 XtraBackup 2.4 ）中的方法來搭建從庫，大概率會導致主從資料不一致，甚至主從複製中斷。

So，在 XtraBackup 8.0 中，我們又該如何搭建從庫呢？

本文主要包括以下幾部分：

使用 XtraBackup 搭建從庫的一般步驟。
基於從庫備份搭建從庫時的注意事項。
GTID 複製中，為什麼需要設定 GTID_PURGED？
設定 GTID_PURGED 時的注意事項。
使用 XtraBackup 8.0 搭建從庫時的注意事項。
performance_schema.log_status 的作用。
XtraBackup 8.0 中哪些場景會加全域性讀鎖？

使用 XtraBackup 搭建從庫的一般步驟

以下是測試環境資訊。

角色	IP地址
主庫	10.0.0.118
從庫	10.0.0.195

下面我們看看具體的搭建步驟。

1. 主庫上建立複製賬號

mysql> create user 'repl'@'%' identified by 'repl123';
Query OK, 0 rows affected (0.01 sec)

mysql> grant replication slave on *.* TO 'repl'@'%';
Query OK, 0 rows affected (0.00 sec)

2. 對主庫進行備份

在 10.0.0.118 上執行備份命令。

# xtrabackup --user=backup_user --password=backup_pass --socket=/data/mysql/3306/data/mysql.sock --backup --parallel=10 --slave-info --target-dir=/data/backup/full

3. 將備份檔案傳輸到從庫上

# scp -r /data/backup/full/* root@10.0.0.195:/data/backup/full

4. 從庫上準備好 MySQL 安裝包及引數檔案

# tar xvf mysql-8.0.27-linux-glibc2.12-x86_64.tar.xz -C /usr/local/
# cd /usr/local/
# ln -s mysql-8.0.27-linux-glibc2.12-x86_64 mysql

5. 在從庫上進行 Prepare 和恢復

# xtrabackup --prepare --target-dir=/data/backup/full
# xtrabackup --defaults-file=/etc/my.cnf --copy-back --parallel=10 --target-dir=/data/backup/full

恢復命令中的 /etc/my.cnf 是從庫的配置檔案。

其中，第 2，3，5 步可以簡化為下面這兩條命令。

# xtrabackup \
--user=backup_user --password=backup_pass --socket=/data/mysql/3306/data/mysql.sock \
--backup --stream=xbstream --slave-info --parallel=10 | lz4 | \
ssh mysql@10.0.0.195 'cat - | lz4 -d | xbstream -p10 -x -C /data/mysql/3306/data/'
# xtrabackup --prepare --target-dir=/data/mysql/3306/data/

第一條命令是線上搭建從庫時的一條常用命令，它將流式備份、管道結合在一起，具有以下優點：

邊備份，邊解壓。相對於備份、傳輸、再解壓，花費的時間更短。
備份集是直接解壓到從庫伺服器，並不會儲存到本地。這樣，對於主庫伺服器，一可減少磁碟空間，二可減小磁碟 IO 壓力。
/data/mysql/3306/data/ 是從庫的資料目錄，在恢復時，無需 --copy-back，直接 Prepare 即可。

6. 啟動例項

# chown -R mysql.mysql /data/mysql/3306/data/
# /usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf &

很多人有個誤區，認為搭建從庫，需要提前建立個空白例項。對於邏輯備份確實如此，但對於物理備份，則無此必要，直接使用 mysqld_safe 啟動還原後的備份檔案即可。

7. 建立複製

這裡需要區分兩種場景：GTID 複製和基於位置點的複製。

首先檢視備份集中的xtrabackup_binlog_info 檔案的內容。

# cat xtrabackup_binlog_info
mysql-bin.000002 882880068 2cbdc21a-db11-11ec-83bf-020017003dc4:1-223148

如果 xtrabackup_binlog_info 中存在 GTID 資訊，則代表備份例項開啟了 GTID，這個時候就需要建立 GTID 複製。

7.1 GTID 複製

對於 GTID 複製，在建立複製前，必須首先設定 GTID_PURGED。

設定 GTID_PURGED 時，注意備份例項的版本。

MySQL 5.7

在 MySQL 5.7 中，因為引入了 mysql.gtid_executed。

從庫例項啟動後，會基於該表的值來初始化 GTID_EXECUTED 和 GTID_PURGED。

mysql> select * from mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid                          | interval_start | interval_end |
+--------------------------------------+----------------+--------------+
| 2cbdc21a-db11-11ec-83bf-020017003dc4 |              1 |         2124 |
+--------------------------------------+----------------+--------------+
1 row in set (0.00 sec)

mysql> show global variables where variable_name in ('gtid_executed', 'gtid_purged');
+---------------+---------------------------------------------+
| Variable_name | Value                                       |
+---------------+---------------------------------------------+
| gtid_executed | 2cbdc21a-db11-11ec-83bf-020017003dc4:1-2124 |
| gtid_purged   | 2cbdc21a-db11-11ec-83bf-020017003dc4:1-2124 |
+---------------+---------------------------------------------+
2 rows in set (0.00 sec)

但很明顯，GTID_PURGED 與 xtrabackup_binlog_info 中的 GTID 資訊相差甚遠。

關於這一點，不難理解，因為主庫的 mysql.gtid_executed，在 MySQL 8.0.17 之前，只有在日誌切換和例項關閉時更新。

下面我們基於 xtrabackup_binlog_info 中的 GTID 資訊重新設定 GTID_PURGED。

mysql> reset master;
Query OK, 0 rows affected (0.00 sec)

mysql> set global gtid_purged='2cbdc21a-db11-11ec-83bf-020017003dc4:1-223148';
Query OK, 0 rows affected (0.01 sec)

因為 GTID_EXECUTED 有值，所以在設定 GTID_PURGED 之前，必須首先通過 RESET MASTER 命令清空 GTID_EXECUTED。

MySQL 5.6

可直接基於 xtrabackup_binlog_info 中的 GTID 資訊設定 GTID_PURGED。

mysql> set global gtid_purged='2cbdc21a-db11-11ec-83bf-020017003dc4:1-223148';

為什麼在 MySQL 5.6 中無需執行 RESET MASTER 呢？

因為 MySQL 5.6 中還沒有引入 mysql.gtid_executed，例項恢復後，GTID_EXECUTED 和 GTID_PURGED 均為空。

MySQL 8.0

在 MySQL 8.0 中，無需設定 GTID_PURGED。

至於為什麼不用設定，後面會有詳細介紹。這裡，大家記住這個結論就可以了。

設定完 GTID_PURGED，接下來執行 CHANGE MASTER TO 命令。

CHANGE MASTER TO
  MASTER_HOST='10.0.0.118',
  MASTER_USER='repl',
  MASTER_PASSWORD='repl123',
  MASTER_PORT=3306,
  MASTER_AUTO_POSITION = 1;

對於 GTID 複製，需將 MASTER_AUTO_POSITION 設定為 1。

在 MySQL 8.0 中，CHANGE MASTER TO 語句中還需新增 GET_MASTER_PUBLIC_KEY = 1。

7.2 基於位置點的複製

如果 xtrabackup_binlog_info 沒有 GTID 資訊，則代表備份例項沒有開啟 GTID，這個時候就無需設定 GTID_PURGED，直接執行 CHANGE MASTER TO 命令即可。

CHANGE MASTER TO
  MASTER_HOST='10.0.0.118',
  MASTER_USER='repl',
  MASTER_PASSWORD='repl123',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='mysql-bin.000002',
  MASTER_LOG_POS=882880068;

CHANGE MASTER TO 語句中的 MASTER_LOG_FILE 和 MASTER_LOG_POS 的值分別取自 xtrabackup_binlog_info 中的 filename 和 position。

8. 開啟複製

mysql> start slave;

9. 檢查主從複製是否正常

mysql> show slave status\G

Slave_IO_Running 和 Slave_SQL_Running 均為 Yes 代表複製正常。

以上就是使用 XtraBackup 搭建從庫的基本步驟。

基於從庫備份搭建從庫時的注意事項

不過線上上，我們很少會對主庫進行備份，一般是備份從庫。所以，基於從庫的備份來搭建一個新的從庫是一個更為常見的場景。

對於這種場景，上面的搭建步驟同樣適用，不過有以下幾點需要注意：

1. 對從庫進行備份，需指定 --slave-info。這個時候備份集中會生成一個 xtrabackup_slave_info 檔案，該檔案記錄了備份時備份例項對應主庫的一致性位置點資訊，如，

# cat xtrabackup_slave_info 
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000004', MASTER_LOG_POS=6263314;

如果從庫開啟了 GTID，則只會記錄 GTID 資訊，如，

SET GLOBAL gtid_purged='2cbdc21a-db11-11ec-83bf-020017003dc4:1-2049780';
CHANGE MASTER TO MASTER_AUTO_POSITION=1;

其實，對主庫備份，也可指定 --slave-info，只不過此時的 xtrabackup_slave_info 內容為空。

所以，上面搭建步驟中的備份命令都帶上了 --slave-info。

2. 在基於位置點的複製中，CHANGE MASTER TO 語句中的 MASTER_LOG_FILE 和 MASTER_LOG_POS 必須取自 xtrabackup_slave_info，而不是 xtrabackup_binlog_info。

對於 GTID 複製，則沒關係，因為 xtrabackup_slave_info 和 xtrabackup_binlog_info 中的 GTID 資訊是一致的。

3. 只要是基於從庫的備份來搭建從庫，在執行 CHANGE MASTER TO 之前，都必須首先執行 RESET SLAVE ALL 清空 mysql.slave_master_info 和 mysql.slave_relay_log_info 表中的內容。

設定 GTID_PURGED 時的注意事項

在 GTID 複製中，為什麼需要設定 GTID_PURGED 呢？

實際上，設定 GTID_PURGED 只是手段，最終目的還是為了設定 GTID_EXECUTED。

GTID_EXECUTED

GTID_EXECUTED 代表了例項中已經執行過的 GTID 集。在建立複製後，從庫會自動跳過 GTID_EXECUTED 相關的事務。如果這個值設定不準確，會導致事務丟失，或者已經重放過的操作重複執行。

但 GTID_EXECUTED 是個只讀引數，不能直接修改。

mysql> set global gtid_executed='411693c9-d512-11ec-9e11-525400d51a16:1-10369';
ERROR 1238 (HY000): Variable 'gtid_executed' is a read only variable

如果我們要修改它，必須通過修改 GTID_PURGED 來間接修改它。

GTID_PURGED

GTID_PURGED 代表了例項中已經執行過，但 Binlog 中不存在的 GTID 集。所以 GTID_PURGED 一定是 GTID_EXECUTED 的子集。

在 MySQL 8.0 之前，如果要修改 GTID_PURGED，GTID_EXECUTED 必須為空。

mysql> set global gtid_purged='411693c9-d512-11ec-9e11-525400d51a16:1-10369';
ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

而要 GTID_EXECUTED 為空，只能執行 RESET MASTER 操作。

mysql> reset master;
Query OK, 0 rows affected (0.02 sec)

mysql> show global variables where variable_name in ('gtid_executed', 'gtid_purged');
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_executed |       |
| gtid_purged   |       |
+---------------+-------+
2 rows in set (0.00 sec)

mysql> set global gtid_purged='411693c9-d512-11ec-9e11-525400d51a16:1-10369';
Query OK, 0 rows affected (0.00 sec)

mysql> show global variables where variable_name in ('gtid_executed', 'gtid_purged');
+---------------+----------------------------------------------+
| Variable_name | Value                                        |
+---------------+----------------------------------------------+
| gtid_executed | 411693c9-d512-11ec-9e11-525400d51a16:1-10369 |
| gtid_purged   | 411693c9-d512-11ec-9e11-525400d51a16:1-10369 |
+---------------+----------------------------------------------+
2 rows in set (0.00 sec)

可以看到，調整完 GTID_PURGED 後，GTID_EXECUTED 也隨之更改。

在 MySQL 8.0 中，則剔除了這一限制，即設定 GTID_PURGED 時，無需 GTID_EXECUTED 為空。但也不能隨便設定，設定時需滿足以下要求：

1. 設定的 GTID_PURGED 不能與 gtid_subtract(@@gtid_executed, @@gtid_purged) 存在交集。

看下面這個示例。

mysql> show global variables where variable_name in ('gtid_executed', 'gtid_purged');
+---------------+------------------------------------------+
| Variable_name | Value                                    |
+---------------+------------------------------------------+
| gtid_executed | a028d418-ccce-11ec-bf07-525400d51a16:1-8 |
| gtid_purged   | a028d418-ccce-11ec-bf07-525400d51a16:1-4 |
+---------------+------------------------------------------+
2 rows in set (0.00 sec)

mysql> select gtid_subtract(@@gtid_executed, @@gtid_purged);
+-----------------------------------------------+
| gtid_subtract(@@gtid_executed, @@gtid_purged) |
+-----------------------------------------------+
| a028d418-ccce-11ec-bf07-525400d51a16:5-8      |
+-----------------------------------------------+
1 row in set (0.00 sec)

mysql> set global gtid_purged='a028d418-ccce-11ec-bf07-525400d51a16:1-5';
ERROR 3546 (HY000): @@GLOBAL.GTID_PURGED cannot be changed: the added gtid set must not overlap with @@GLOBAL.GTID_EXECUTED

2. 設定的 GTID_PURGED 必須是當前 GTID_PURGED 的超集。

mysql> show global variables where variable_name in ('gtid_executed', 'gtid_purged');
+---------------+------------------------------------------+
| Variable_name | Value                                    |
+---------------+------------------------------------------+
| gtid_executed | a028d418-ccce-11ec-bf07-525400d51a16:1-8 |
| gtid_purged   | a028d418-ccce-11ec-bf07-525400d51a16:1-4 |
+---------------+------------------------------------------+
2 rows in set (0.00 sec)

mysql> set global gtid_purged='a028d418-ccce-11ec-bf07-525400d51a16:1-3';
ERROR 3546 (HY000): @@GLOBAL.GTID_PURGED cannot be changed: the new value must be a superset of the old value

mysql> set global gtid_purged='a028d418-ccce-11ec-bf07-525400d51a16:1-4,9b481834-de85-11ec-9045-020017003dc4:1-10';
Query OK, 0 rows affected (0.01 sec)

mysql> show global variables where variable_name in ('gtid_executed', 'gtid_purged')\G
*************************** 1. row ***************************
Variable_name: gtid_executed
        Value: 9b481834-de85-11ec-9045-020017003dc4:1-10,
a028d418-ccce-11ec-bf07-525400d51a16:1-8
*************************** 2. row ***************************
Variable_name: gtid_purged
        Value: 9b481834-de85-11ec-9045-020017003dc4:1-10,
a028d418-ccce-11ec-bf07-525400d51a16:1-4
2 rows in set (0.00 sec)

可以看到，新新增的 GTID 集同樣也新增到 GTID_EXECUTED 中了。

除了直接指定，在 MySQL 8.0 中還支援通過 + 號新增新的 GTID 集。如，

mysql> set global gtid_purged='+9b481834-de85-11ec-9045-020017003dc4:1-10';
Query OK, 0 rows affected (0.01 sec)

使用 XtraBackup 8.0 搭建從庫時的注意事項

XtraBackup 8.0 中沒有加全域性讀鎖，備份結束時的位置點資訊查詢的是 performance_schema.log_status。

該表的內容如下，

mysql> select * from performance_schema.log_status\G
*************************** 1. row ***************************
    SERVER_UUID: d310871c-db0c-11ec-a557-020017003dc4
          LOCAL: {"gtid_executed": "d310871c-db0c-11ec-a557-020017003dc4:1-352559", "binary_log_file": "mysql-bin.000022", "binary_log_position": 9698237}
    REPLICATION: {"channels": []}
STORAGE_ENGINES: {"InnoDB": {"LSN": 912297234, "LSN_checkpoint": 912297234}}
1 row in set (0.00 sec)

需要注意的是，LOCAL 中的 gtid_executed 和 binary_log_file + binary_log_position 對應的並不總是同一個事務。

這一點很容易模擬出來，對一張表持續進行插入操作即可。

下面我們看一個具體的案例。

備份過程中，持續對一張表進行插入操作。最後備份集中 xtrabackup_binlog_info 的內容如下。

# cat xtrabackup_binlog_info
mysql-bin.000024 507 d310871c-db0c-11ec-a557-020017003dc4:1-388482

接下來我們基於 Binlog 的位置點資訊 "mysql-bin.000024 507" 查詢對應的事務。

# mysqlbinlog -v --base64-output=decode-rows --stop-position=507 mysql-bin.000024
# The proper term is pseudo_replica_mode, but we use this compatibility alias
# to make the statement usable on server versions 8.0.24 and older.
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#220529 11:19:07 server id 1  end_log_pos 126 CRC32 0xdcc54ec7  Start: binlog v 4, server v 8.0.28 created 220529 11:19:07
# at 126
#220529 11:19:07 server id 1  end_log_pos 197 CRC32 0x5d440f7c  Previous-GTIDs
# d310871c-db0c-11ec-a557-020017003dc4:1-388482
# at 197
#220529 11:19:07 server id 1  end_log_pos 276 CRC32 0x0dd893b5  GTID last_committed=0 sequence_number=1 rbr_only=yes original_committed_timestamp=1653823147539722 immediate_commit_timestamp=1653823147539722 transaction_length=310
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1653823147539722 (2022-05-29 11:19:07.539722 GMT)
# immediate_commit_timestamp=1653823147539722 (2022-05-29 11:19:07.539722 GMT)
/*!80001 SET @@session.original_commit_timestamp=1653823147539722*//*!*/;
/*!80014 SET @@session.original_server_version=80028*//*!*/;
/*!80014 SET @@session.immediate_server_version=80028*//*!*/;
SET @@SESSION.GTID_NEXT= 'd310871c-db0c-11ec-a557-020017003dc4:388483'/*!*/;
# at 276
#220529 11:19:07 server id 1  end_log_pos 365 CRC32 0xa49dc290  Query thread_id=262 exec_time=0 error_code=0
...
BEGIN
/*!*/;
# at 365
#220529 11:19:07 server id 1  end_log_pos 425 CRC32 0x824f6309  Table_map: `slowtech`.`t1` mapped to number 157
# at 425
#220529 11:19:07 server id 1  end_log_pos 476 CRC32 0x5a6fe6ec  Write_rows: table id 157 flags: STMT_END_F
### INSERT INTO `slowtech`.`t1`
### SET
###   @1=1483132
###   @2='aaaaaaaaaa'
# at 476
#220529 11:19:07 server id 1  end_log_pos 507 CRC32 0x66a401f6  Xid = 4108904
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

可以看到，該事務對應的 GTID 是 d310871c-db0c-11ec-a557-020017003dc4:388483，不是 xtrabackup_binlog_info 中的 388482。

如果我們像在 MySQL 5.6，5.7 中那樣，基於 xtrabackup_binlog_info 中的 GTID 資訊來設定 GTID_PURGED，在我們這個 case 中，會導致同一個 INSERT 操作執行兩次，進而會出現主鍵衝突，主從複製中斷。

如此來看，問題的根源還是出在 performance_schema.log_status 中的 gtid_executed 和 binary_log_file + binary_log_position 指向的不是同一個事務。

這是一個 Bug 嗎？其實不然。

XtraBackup 8.0 在查詢完 performance_schema.log_status 後，會基於查詢到的 binary_log_file 和 binary_log_position 拷貝對應的 Binlog 。

下面是備份集中拷貝的 Binlog。

# ll /data/backup/full/
...
-rw-r-----. 1 root root      507 May 29 11:19 mysql-bin.000024
-rw-r-----. 1 root root       19 May 29 11:19 mysql-bin.index
...

Binlog 中記錄了 "mysql-bin.000024 507" 這個位置點的事務所對應的 GTID 值。

例項啟動時，會自動基於 Binlog 中的 GTID 資訊來初始化 GTID_EXECUTED 和 GTID_PURGED。

mysql> show global variables where variable_name in ('gtid_executed', 'gtid_purged');
+---------------+-----------------------------------------------+
| Variable_name | Value                                         |
+---------------+-----------------------------------------------+
| gtid_executed | d310871c-db0c-11ec-a557-020017003dc4:1-388483 |
| gtid_purged   | d310871c-db0c-11ec-a557-020017003dc4:1-388482 |
+---------------+-----------------------------------------------+
2 rows in set (0.00 sec)

所以，例項起來後，我們看到的 GTID_EXECUTED 就已經是正確值，就已經能正確反映備份結束時的一致性位置點資訊了。

這個時候，直接執行 CHANGE MASTER TO 操作就可以了。

performance_schema.log_status 的作用

關於 performance_schema.log_status 的作用，其實官方文件中也提到了，是提供位置點資訊，供備份工具拷貝所需的 Binlog。查詢的過程中也會阻塞日誌和相關管理操作。不過阻塞的時間很短，填充完表中的資料就會釋放資源。

The log_status table provides information that enables an online backup tool to copy the required log files without locking those resources for the duration of the copy process.

When the log_status table is queried, the server blocks logging and related administrative changes for just long enough to populate the table, then releases the resources. 

The log_status table informs the online backup which point it should copy up to in the source's binary log and gtid_executed record, and the relay log for each replication channel. 

It also provides relevant information for individual storage engines, such as the last log sequence number (LSN) and the LSN of the last checkpoint taken for the InnoDB storage engine.

XtraBackup 8.0 中哪些場景會加全域性讀鎖

下面兩種場景，XtraBackup 8.0 會加全域性讀鎖：

備份例項中存在 MyISAM 表。
備份從庫，且命令列中指定了 --slave-info，且從庫 SHOW SLAVE STATUS 中的 Auto_Position 不為 1。

Auto_Position 不為 1 意味著從庫沒有開啟 GTID 複製，或者開啟了 GTID 複製，但未將 MASTER_AUTO_POSITION 設定為 1。

總結

1. 備份鎖引入的初衷是為了阻塞備份過程中的 DDL，不是為了替代全域性讀鎖。在 XtraBackup 8.0 中，我們可以指定 --skip-lock-ddl 禁用備份鎖，這並不影響 XtraBackup 的正常使用。

2. 基於物理備份搭建從庫時，無需提前建立空白例項。

3. 在基於位置點的複製中，注意 CHANGE MASTER TO 語句中 MASTER_LOG_FILE 和 MASTER_LOG_POS 的選擇。

以一個簡單的主從複製拓撲為例：master -> slave1。

如果是基於 master 的備份新增一個 master 的從庫，或者，基於 slave1 的備份新增一個 slave1 的從庫。建立複製時，應使用 xtrabackup_binlog_info 的位置點資訊。
如果是基於 slave1 的備份新增 master 的一個從庫，應使用 xtrabackup_slave_info 的位置點資訊。

4. 基於從庫的備份搭建從庫時，在執行 CHANGE MASTER TO 操作之前，必須首先執行 RESET SLAVE ALL。

5. 無論是對主庫還是從庫進行備份，都可指定 --slave-info，此時都會生成 xtrabackup_slave_info。只不過如果是對主庫進行備份，該檔案會為空。

6. 在 GTID 複製中，設定 GTID_PURGED 時，注意備份例項的版本。如果是 MySQL 5.6，5.7，可直接基於 xtrabackup_binlog_info 中的 GTID 資訊設定 GTID_PURGED。如果是 MySQL 8.0，無需再設定 GTID_PURGED。