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

来源:https://www.cnblogs.com/ivictor/archive/2022/06/06/16347885.html
-Advertisement-
Play Games

搭建從庫，本質上需要的只是一個一致性備份集及這個備份集對應的位置點信息。之前介紹的幾個備份工具（ MySQL中如何選擇合適的備份策略和備份工具 ）均可滿足。 這裡，我們重點看看如何基於 XtraBackup 搭建從庫。 整個過程其實比較簡單，無非是備份還原。唯一需要註意的是建立複製時位置點的選擇，包 ...


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

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

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

  1. 在基於位置點的複製中，CHANGE MASTER TO 語句中 MASTER_LOG_FILE 和 MASTER_LOG_POS 的選擇。
  2. 在 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 中，我們又該如何搭建從庫呢？

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

  1. 使用 XtraBackup 搭建從庫的一般步驟。
  2. 基於從庫備份搭建從庫時的註意事項。
  3. GTID 複製中，為什麼需要設置 GTID_PURGED？
  4. 設置 GTID_PURGED 時的註意事項。
  5. 使用 XtraBackup 8.0 搭建從庫時的註意事項。
  6. performance_schema.log_status 的作用。
  7. 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/* [email protected]:/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 [email protected] 'cat - | lz4 -d | xbstream -p10 -x -C /data/mysql/3306/data/'
# xtrabackup --prepare --target-dir=/data/mysql/3306/data/

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

  1. 邊備份，邊解壓。相對於備份、傳輸、再解壓，花費的時間更短。
  2. 備份集是直接解壓到從庫伺服器，並不會保存到本地。這樣，對於主庫伺服器，一可減少磁碟空間，二可減小磁碟 IO 壓力。
  3. /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 會加全局讀鎖：

  1. 備份實例中存在 MyISAM 表。

  2. 備份從庫，且命令行中指定了 --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。

參考

[1] LOCK INSTANCE FOR BACKUP and UNLOCK INSTANCE Statements

[2] The log_status Table

[3] log_status has wrong binary_log_position of gtid_executed


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 大數據技術之Flume 第3章 Flume進階
    **前言：**本文將以 Ubuntu Server 22.04 LTS 為例，說明在 VMware 虛擬機中的安裝和配置 Linux 操作系統的步驟。 一、VMWare 安裝配置 1、VMware 下載地址：VMware Workstation Pro 16.x（需要登錄），安裝和配置步驟略。 二、 ...
  • 一個 curl 配置引發的慘案
    nvm 安裝 node 一直報錯，死活解決不了，苦苦 Google 依然無果... ...
  • docker 安裝 oracle
    鏡像下載、功能變數名稱解析、時間同步請點擊 阿裡雲開源鏡像站 背景 在Linux中安裝oracle非常麻煩，相信每個人也會遇到各種坑。為了一次裝好，也方便將來直接可以導出鏡像在各平臺移植使用，所以選擇用docker安裝 拉取鏡像 在 DockerHub 上搜索 Oracle 可以找到 Oracle 的官方鏡 ...
  • 在Linux中使用crontab
    查看已存在的任務 查看crontab 輸入命令：cat /etc/crontab 在設定編輯之前都建議列出服務查看一下：crontab -l 語法： **** user_name command to be executed 前面五位是定時執行的時間周期 說明如下： 第一個 * 表示分鐘：取值範圍 ...
  • VMware網路配置以及找不到VMnet8網路問題的解決方案
    鏡像下載、功能變數名稱解析、時間同步請點擊 阿裡雲開源鏡像站 前言 沒安裝vm的小伙伴們，可來這~VM安裝和配置 可選擇優質模板，享受閱讀 VM設置 下載centso鏡像 阿裡雲：下載 安裝VM 有什麼要註意嗎？沒有，除了存儲路徑外，其他都可以自己下一步直到完成，所以可以直接跳到在這兒，不必浪費寶貴時間，廢 ...
  • 大數據技術之Flume 第1章 Flume概述
    一、函數概述 • PL/SQL中的過程和函數（通常稱為子程式）是PL/SQL塊的一種特殊的類型，這種類型的子程式可以以編譯的形式存放在資料庫中，併為後續的程式塊調用。 • 相同點：完成特定功能的程式 • 不同點：是否用return語句返回值 二、函數語法 CREATE [OR REPLACE] FU ...
  • mysql精簡單機版，免登錄，可複製，不啟動服務,與本機mysql無衝突
    mysql精簡單機版，免登錄，可複製，不啟動服務,與本機mysql無衝突 ...
  • Mysql終端Terminal操作
    datebase管理 1.創建資料庫-create 語法：create database 資料庫名 character set 編碼 # 註意：預設會存在四個資料庫，其資料庫中存儲的是mysql資料庫伺服器的配置的數據 示例：create database firstDB character set ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類