MySQL :: MySQL 9.0 參考手冊 :: 20.5.6 使用 MySQL Enterprise Backup 與群組複製

版本 9.0

8.4 目前
8.0
5.7

8.0 日文

MySQL 9.0 參考手冊 / ... / 使用 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
```
注意

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

重新啟動群組複寫。 使用例如 mysql 用戶端連線到重新啟動的 s3，並發出以下命令：

mysql> START 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
```
注意

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

mysql> RESET REPLICA ALL;
```
為了讓還原後的伺服器能夠使用群組複寫的內建機制進行分散式復原來自動復原，請設定伺服器的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;
```
然後，設定成員上的群組複寫使用者憑證：
```
mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', 
    ->   SOURCE_PASSWORD='password'
    ->   FOR CHANNEL 'group_replication_recovery';
```

重新啟動群組複寫。 使用您的 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 檔案複製到還原後伺服器的資料目錄中。
在啟動還原後的伺服器後，並在重新啟動群組複寫之前，透過 mysql 用戶端將所有系統變數手動設定為其持久值。

還原主要成員。 如果還原後的成員是群組中的主要成員，則必須注意避免在群組複寫分散式復原過程中寫入還原後的資料庫。根據用戶端存取群組的方式，可能會在還原後的成員在網路上可存取之後，但在該成員完成追趕群組離線時遺失的活動之前，在該成員上執行 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

上一個首頁向上下一個