MySQL :: MySQL 8.4 Reference Manual :: 20.5.6 Using MySQL Enterprise Backup with Group Replication

version 8.4

8.0 current
5.7

8.0 Japanese

MySQL 8.4 Reference Manual / ... / Using MySQL Enterprise Backup with Group Replication

20.5.6 使用 MySQL Enterprise Backup 与组复制

MySQL Enterprise Backup 是 MySQL Server 的一个商业许可备份工具，仅在 MySQL Enterprise Edition 中提供。下面将解释如何使用 MySQL Enterprise Backup 将组复制成员备份并恢复。同样，可以快速添加新成员到组中。

Backing up a 组复制 Member Using MySQL Enterprise Backup

备份组复制成员与备份独立 MySQL 实例类似。以下指令假设您已经熟悉使用 MySQL Enterprise Backup 进行备份；如果不是，请查看 Backing Up a Database Server。另外，注意在 Grant MySQL Privileges to Backup Administrator 和 Using MySQL Enterprise Backup with Group Replication 中描述的要求。

考虑以下包含三个成员的组：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. 如果corrupted服务器仍在运行，请停止它。例如，在使用systemd的Linux发行版中：
```
s3> systemctl stop mysqld
```
2. 将corrupted服务器的数据目录中的两个配置文件auto. cnf和mysqld-auto.cnf(如果存在)拷贝到安全位置外的数据目录中。这是为了保留服务器的UUID和第7.1.9.3节，“持久系统变量”(如果使用)，这些变量在下面的步骤中需要。
3. 删除s3的数据目录中的所有内容。例如：
```
s3> rm -rf /var/lib/mysql/*
```
  如果系统变量innodb_数据_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
```
  Note
  
  上述命令假设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
```
  能够将二进制日志和relay日志恢复到正确的文件路径使得恢复过程变得更容易；如果某些原因无法实现，请见重建失败成员以重新加入新的成员。
将auto.cnf文件恢复到s3中为了重新加入复制组，恢复的成员必须具有与之前加入组时相同的server_uuid。将步骤2中保留的auto.cnf文件复制到恢复成员的数据目录中，以供供应老服务器UUID。

Note

如果您无法通过恢复失败成员的老auto.cnf文件提供其原始server_uuid给恢复成员，那么您必须让恢复成员作为新成员加入组；见重建失败成员以重新加入新的成员以下的说明，以了解如何实现该操作。
恢复 s3 的 mysqld-auto.cnf 文件（仅在使用持久系统变量的 s3 时需要）。要配置失败成员时使用的第 7.1.9.3 节，“持久系统变量” 的设置，需要将这些设置提供给恢复的成员。这些设置可以在失败服务器的 mysqld-auto.cnf 文件中找到，您应该在步骤 2 中保存了该文件。将文件恢复到恢复服务器的数据目录中。请参阅恢复持久系统变量，了解如果您没有文件副本该怎么做。
启动恢复的服务器。例如，在使用 systemd 的 Linux 发行版上：
```
systemctl start mysqld
```
Note

如果您正在恢复的是一个主要成员，按照恢复主要成员中的步骤操作在启动恢复的服务器之前。

重新启动 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       |
+-------------+-------------+--------------+

Note

如果您恢复的是主成员，一旦它与群组同步并变为ONLINE，请按照恢复主成员的末尾部分描述的步骤将配置更改 revert 到服务器之前您启动它时的状态。

现在，成员已经完全从备份中恢复，并且作为群组中的常规成员工作。

有时，按照上述步骤在恢复失败成员无法执行，因为例如二进制日志或中继日志已损坏或缺失于备份。在这种情况下，使用备份来重建成员，然后将其添加到组中作为新成员。在以下步骤中，我们假设重建的成员名为s3，与失败成员相同，并且在同一主机上运行s3:

将 s2 的备份复制到 s3 的主机上。 复制备份的确切方法取决于操作系统和可用的工具。在这个示例中，我们假设这两个主机都是 Linux 服务器，并使用 SCP 将文件之间复制：
```
s2/backups> scp my.mbi_2206_1429 s3:/backups
```
还原备份。 连接到目标主机（在本例中是 s3 的主机），然后使用 MySQL Enterprise Backup 还原备份。以下是步骤：
1. 如果 corrupted 服务器仍在运行，请停止它。例如，在使用 systemd 的 Linux 发行版上：
```
s3> systemctl stop mysqld
```
2. 保存配置文件mysqld-auto.cnf，如果在 corrupted 服务器的数据目录中找到该文件，然后将其复制到安全位置外部数据目录中。这是为了保留服务器的第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作为一个新的成员，而不是使用备份中的旧二进制日志和relay日志，因此，如果这些日志已经包含在您的备份中，使用 --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
```
  Note
  
  如果您在备份中有健康的二进制日志和relay日志，可以将其安全地传输到目标主机上，那么您被推荐按照恢复失败成员的步骤进行操作。
恢复 s3 的 mysqld-auto.cnf 文件（仅在 s3 使用持久系统变量时需要）。要配置失败成员的设置，需要提供给恢复服务器。这些设置可以在失败服务器的 mysqld-auto.cnf 文件中找到，该文件您应该已经保存在步骤 2 中。将文件恢复到恢复服务器的数据目录中。请参阅恢复持久系统变量，了解如果您没有文件副本该怎么做。

Note

不要将损坏服务器的 auto.cnf 文件恢复到新成员的数据目录中—当重建的 s3 加入组作为新的成员时，它将被分配一个新的服务器 UUID。
启动恢复服务器。例如，在使用 systemd 的 Linux 发行版上：
```
systemctl start mysqld
```
Note

如果您正在恢复的服务器是主成员，按照恢复主成员中的步骤操作在启动恢复服务器之前。
将恢复的成员重新配置以加入 Group Replication。使用mysql 客户端连接到恢复服务器，并使用以下命令重置源和副本信息：
```
mysql> RESET BINARY LOGS AND GTIDS;

mysql> RESET REPLICA ALL;
```
为了使恢复的服务器能够自动恢复使用 Group Replication 的内置机制进行分布式恢复，配置服务器的gtid_executed变量。要做到这一点，请使用备份中的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;

在恢复实例成为群组的在线成员之前，它需要应用于备份后发生的事务，这可以使用 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 |
+-------------+-------------+--------------+
| s3          |        3306 | RECOVERING   |
| s2          |        3306 | ONLINE       |
| s1          |        3306 | ONLINE       |
+-------------+-------------+--------------+

这显示s3正在应用事务以catch up with the group。一旦它与群组同步并变为ONLINE，其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       |
+-------------+-------------+--------------+

Note

如果您正在恢复的服务器是主成员，一旦它与群组同步并变为ONLINE，请执行恢复主成员的最后部分，以还原您在启动服务器之前对其进行的配置更改。

现在，该成员已经被恢复到群组中作为新的成员。

恢复 persisted 系统变量. mysqlbackup不提供备份或保留Section 7.1.9.3, “persisted 系统变量”的支持—文件mysqld-auto.cnf不包含在备份中。要将恢复成员启动其 persisted 变量设置，请需要执行以下操作：

将损坏服务器的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

PREV HOME UP NEXT

20.5.6 使用 MySQL Enterprise Backup 与 组复制

Backing up a 组复制 Member Using MySQL Enterprise Backup

20.5.6 使用 MySQL Enterprise Backup 与组复制