MySQL :: MySQL 8.4 參考手冊 :: 20.5.6 將 MySQL Enterprise Backup 與群組複製搭配使用

版本 8.4

8.0 日文

MySQL 8.4 參考手冊 / ... / 將 MySQL Enterprise Backup 與群組複製搭配使用

20.5.6 將 MySQL Enterprise Backup 與群組複製搭配使用

MySQL Enterprise Backup 是一個用於 MySQL 伺服器的商業授權備份公用程式，可透過 MySQL 企業版取得。本節說明如何使用 MySQL Enterprise Backup 來備份及後續還原群組複製成員。相同的技術可用於快速將新成員新增至群組。

使用 MySQL Enterprise Backup 備份群組複製成員

備份群組複製成員與備份獨立 MySQL 執行個體類似。下列指示假設您已熟悉如何使用 MySQL Enterprise Backup 執行備份；如果不是這樣，請檢閱備份資料庫伺服器。另請注意授與 MySQL 權限給備份管理員和將 MySQL Enterprise Backup 與群組複製搭配使用中描述的需求。

考量以下具有三個成員的群組，s1、s2 和 s3，在具有相同名稱的主機上執行

mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s1          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s3          |        3306 | ONLINE       |
+-------------+-------------+--------------+

使用 MySQL Enterprise Backup，透過在其主機上發出例如以下命令，建立 s2 的備份

s2> mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/backups/my.mbi_`date +%d%m_%H%M` \
		      --backup-dir=/backups/backup_`date +%d%m_%H%M` --user=root -p \
--host=127.0.0.1 backup-to-image

還原失敗的成員

假設其中一個成員（以下範例中的 s3）已無法修復地損毀。群組成員 s2 的最新備份可用於還原 s3。以下是執行還原的步驟

將 s2 的備份複製到 s3 的主機上。 複製備份的確切方式取決於作業系統和您可用的工具。在此範例中，我們假設主機都是 Linux 伺服器，並使用 SCP 在它們之間複製檔案
```
s2/backups> scp my.mbi_2206_1429 s3:/backups
```
還原備份。 連線至目標主機（在此案例中為 s3 的主機），並使用 MySQL Enterprise Backup 還原備份。以下是步驟
1. 停止損毀的伺服器（如果它仍在執行）。例如，在使用 systemd 的 Linux 發行版上
```
s3> systemctl stop mysqld
```
2. 將損毀伺服器資料目錄中的兩個組態檔 auto.cnf 和 mysqld-auto.cnf（如果存在）複製到資料目錄外的安全位置，藉此保留它們。這是為了保留伺服器的 UUID 和第 7.1.9.3 節，「持續系統變數」（如果使用），這些在以下步驟中是必要的。
3. 刪除 s3 資料目錄中的所有內容。例如
```
s3> rm -rf /var/lib/mysql/*
```
  如果系統變數 innodb_data_home_dir、innodb_log_group_home_dir 和 innodb_undo_directory 指向資料目錄以外的任何目錄，它們也應該清空；否則，還原作業會失敗。
4. 將 s2 的備份還原到 s3 的主機上
```
s3> mysqlbackup --defaults-file=/etc/my.cnf \
  --datadir=/var/lib/mysql \
  --backup-image=/backups/my.mbi_2206_1429  \
--backup-dir=/tmp/restore_`date +%d%m_%H%M` copy-back-and-apply-log
```
  注意
  
  上述指令假設 s2 和 s3 上的二進位日誌和中繼日誌具有相同的基本名稱，且位於這兩台伺服器上的相同位置。如果這些條件不滿足，您應該使用 --log-bin 和 --relay-log 選項，將二進位日誌和中繼日誌還原到 s3 上的原始檔案路徑。例如，如果您知道在 s3 上，二進位日誌的基本名稱是 s3-bin，而中繼日誌的基本名稱是 s3-relay-bin，您的還原指令應該如下所示
```
mysqlbackup --defaults-file=/etc/my.cnf \
  --datadir=/var/lib/mysql \
  --backup-image=/backups/my.mbi_2206_1429  \
  --log-bin=s3-bin --relay-log=s3-relay-bin \
  --backup-dir=/tmp/restore_`date +%d%m_%H%M` copy-back-and-apply-log
```
  能夠將二進位日誌和中繼日誌還原到正確的檔案路徑，可使還原過程更加容易；如果由於某些原因而無法實現，請參閱將失敗的成員重建以作為新成員重新加入。
還原 s3 的 auto.cnf 檔案。為了重新加入複製群組，還原的成員必須具有它之前加入群組時所使用的相同server_uuid。透過將上述步驟 2 中保存的 auto.cnf 檔案複製到還原成員的資料目錄中，來提供舊的伺服器 UUID。

注意

如果您無法透過還原舊的 auto.cnf 檔案，向還原的成員提供失敗成員的原始 server_uuid，則必須讓還原的成員作為新成員加入群組；請參閱下方的將失敗的成員重建以作為新成員重新加入中的說明，了解如何執行此操作。
還原 s3 的 mysqld-auto.cnf 檔案（僅在 s3 使用持久系統變數時才需要）。用於設定失敗成員的第 7.1.9.3 節「持久系統變數」的設定，必須提供給還原的成員。這些設定可在失敗伺服器的 mysqld-auto.cnf 檔案中找到，您應該已在上述步驟 2 中保存該檔案。將該檔案還原到還原伺服器的資料目錄。請參閱還原持久系統變數，了解如果您沒有該檔案的副本時該怎麼辦。
啟動還原的伺服器。例如，在使用 systemd 的 Linux 發行版上
```
systemctl start mysqld
```
注意

如果您還原的伺服器是主要成員，請在啟動還原的伺服器之前執行還原主要成員中描述的步驟。

重新啟動 Group Replication。使用例如 mysql 用戶端連線到重新啟動的 s3，並發出以下指令

mysql> START GROUP_REPLICATION;

在還原的執行個體可以成為群組的線上成員之前，它需要套用備份後群組發生的任何交易；這是透過使用 Group Replication 的分散式復原機制來實現的，且該程序會在發出 START GROUP_REPLICATION 陳述式後啟動。若要檢查還原執行個體的成員狀態，請發出

mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s1          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s3          |        3306 | RECOVERING   |
+-------------+-------------+--------------+

這顯示 s3 正在套用交易，以趕上群組的進度。一旦它趕上群組的其他部分，其 member_state 將變更為 ONLINE

mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s1          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s3          |        3306 | ONLINE       |
+-------------+-------------+--------------+

注意

如果您還原的伺服器是主要成員，一旦它與群組同步並變成 ONLINE，請執行還原主要成員末尾所述的步驟，以還原您在啟動伺服器之前對伺服器所做的組態變更。

該成員現在已從備份中完全還原，並作為群組的常規成員運作。

將失敗的成員重建以作為新成員重新加入

有時，無法執行上述還原失敗的成員中概述的步驟，例如，由於二進位日誌或中繼日誌已損壞，或者它只是從備份中遺失。在這種情況下，請使用備份來重建成員，然後將其作為新成員新增至群組。在以下步驟中，我們假設重建的成員命名為 s3，如同失敗的成員，並且它與 s3 在相同主機上執行

將 s2 的備份複製到 s3 的主機上。複製備份的確切方式取決於作業系統和您可使用的工具。在此範例中，我們假設主機都是 Linux 伺服器，並使用 SCP 在它們之間複製檔案
```
s2/backups> scp my.mbi_2206_1429 s3:/backups
```
還原備份。 連線至目標主機（在此案例中為 s3 的主機），並使用 MySQL Enterprise Backup 還原備份。以下是步驟
1. 停止損毀的伺服器（如果它仍在執行）。例如，在使用 systemd 的 Linux 發行版上
```
s3> systemctl stop mysqld
```
2. 如果損毀伺服器的資料目錄中找到組態檔案 mysqld-auto.cnf，請將其複製到資料目錄外的安全位置，以保存此檔案。這是為了保存伺服器的第 7.1.9.3 節「持久系統變數」，稍後會需要這些變數。
3. 刪除 s3 資料目錄中的所有內容。例如
```
s3> rm -rf /var/lib/mysql/*
```
  如果系統變數 innodb_data_home_dir、innodb_log_group_home_dir 和 innodb_undo_directory 指向資料目錄以外的任何目錄，它們也應該清空；否則，還原作業會失敗。
4. 將 s2 的備份還原到 s3 的主機上。透過這種方法，我們正在將 s3 重建為新成員，為此我們不需要或不希望使用備份中的舊二進位日誌和中繼日誌；因此，如果這些日誌已包含在您的備份中，請使用 --skip-binlog 和 --skip-relaylog 選項排除它們
```
s3> mysqlbackup --defaults-file=/etc/my.cnf \
  --datadir=/var/lib/mysql \
  --backup-image=/backups/my.mbi_2206_1429  \
  --backup-dir=/tmp/restore_`date +%d%m_%H%M` \
  --skip-binlog --skip-relaylog \
copy-back-and-apply-log
```
  注意
  
  如果您在備份中有健全的二進位日誌和中繼日誌，可以毫無問題地傳輸到目標主機，建議您遵循上述還原失敗的成員中描述的較簡單程序。
還原 s3 的 mysqld-auto.cnf 檔案（僅在 s3 使用持久系統變數時才需要）。用於設定失敗成員的第 7.1.9.3 節「持久系統變數」的設定，必須提供給還原的伺服器。這些設定可在失敗伺服器的 mysqld-auto.cnf 檔案中找到，您應該已在上述步驟 2 中保存該檔案。將該檔案還原到還原伺服器的資料目錄。請參閱還原持久系統變數，了解如果您沒有該檔案的副本時該怎麼辦。

注意

請勿將損毀伺服器的 auto.cnf 檔案還原到新成員的資料目錄—當重建的 s3 作為新成員加入群組時，會被指派新的伺服器 UUID。
啟動還原的伺服器。例如，在使用 systemd 的 Linux 發行版上
```
systemctl start mysqld
```
注意

如果您還原的伺服器是主要成員，請在啟動還原的伺服器之前執行還原主要成員中描述的步驟。
重新設定還原的成員以加入 Group Replication。使用 mysql 用戶端連線到還原的伺服器，並使用以下指令重設來源和複本資訊
```
mysql> RESET BINARY LOGS AND GTIDS;

mysql> RESET REPLICA ALL;
```
為了讓還原的伺服器能夠使用 Group Replication 的內建分散式復原機制自動復原，請設定伺服器的 gtid_executed 變數。若要執行此操作，請使用 s2 備份中包含的 backup_gtid_executed.sql 檔案，該檔案通常會還原到還原成員的資料目錄下。停用二進位日誌記錄，使用 backup_gtid_executed.sql 檔案設定 gtid_executed，然後透過您的 mysql 用戶端發出以下陳述式來重新啟用二進位日誌記錄
```
mysql> SET SQL_LOG_BIN=OFF;
mysql> SOURCE datadir/backup_gtid_executed.sql
mysql> SET SQL_LOG_BIN=ON;
```
然後，在成員上設定 Group Replication 使用者認證
```
mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', 
    ->   SOURCE_PASSWORD='password'
    ->   FOR CHANNEL 'group_replication_recovery';
```

重新啟動 Group Replication。使用您的 mysql 用戶端對還原的伺服器發出以下指令

mysql> START GROUP_REPLICATION;

mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s3          |        3306 | RECOVERING   |
| s2          |        3306 | ONLINE       |
| s1          |        3306 | ONLINE       |
+-------------+-------------+--------------+

這顯示 s3 正在套用交易，以趕上群組的進度。一旦它趕上群組的其他部分，其 member_state 將變更為 ONLINE

mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members;
+-------------+-------------+--------------+
| member_host | member_port | member_state |
+-------------+-------------+--------------+
| s3          |        3306 | ONLINE       |
| s2          |        3306 | ONLINE       |
| s1          |        3306 | ONLINE       |
+-------------+-------------+--------------+

注意

該成員現在已作為新成員還原到群組。

還原持久系統變數。 mysqlbackup 不支援備份或保存第 7.1.9.3 節「持久系統變數」—備份中不包含檔案 mysqld-auto.cnf。若要使用其持久變數設定啟動還原的成員，您需要執行下列其中一項操作

保存損毀伺服器的 mysqld-auto.cnf 檔案副本，並將其複製到還原伺服器的資料目錄。
如果群組中另一個成員具有與損毀成員相同的持久系統變數設定，請將該成員的 mysqld-auto.cnf 檔案複製到還原伺服器的資料目錄。
在啟動還原的伺服器之後，且在您重新啟動 Group Replication 之前，透過 mysql 用戶端手動將所有系統變數設定為其持久值。

還原主要成員。 如果還原的成員是群組中的主要成員，則必須謹慎，以防止在 Group Replication 分散式復原過程中寫入還原的資料庫。根據用戶端存取群組的方式，還原的成員在網路可存取之後，且在成員完成其在離開群組時錯過之活動的趕上進度之前，有可能會在該成員上執行 DML 陳述式。為避免這種情況，在啟動還原的伺服器之前，請在伺服器選項檔案中設定下列系統變數

group_replication_start_on_boot=OFF
super_read_only=ON
event_scheduler=OFF

這些設定確保成員在啟動時成為唯讀，並且在成員於分散式復原過程中趕上群組進度時，關閉事件排程器。客戶端也必須配置足夠的錯誤處理，因為它們在復原成員的這段期間內會被暫時阻止執行 DML 操作。一旦復原程序完全完成，且復原成員與群組的其他成員同步後，請還原這些變更；重新啟動事件排程器。

mysql> SET global event_scheduler=ON;

編輯成員選項檔案中的以下系統變數，以便為下次啟動正確配置。

group_replication_start_on_boot=ON
super_read_only=OFF
event_scheduler=ON