将 s2 的备份复制到 s3 的主机上。 复制备份的确切方式取决于操作系统和可用的工具。在这个示例中，我们假设主机都是 Linux 服务器，并使用 SCP 将文件复制到它们之间：

s2/backups> scp my.mbi_2206_1429 s3:/backups

恢复备份。 连接到目标主机（在这个示例中是 s3 的主机），并使用 MySQL 企业备份恢复备份。以下是步骤：

还原 auto.cnf 文件以供 s3 使用。 要重新加入复制组，恢复的成员 必须 具有相同的 server_uuid，它曾经用于加入组之前。通过将 auto.cnf 文件从步骤 2 中保存的副本复制到恢复的成员的数据目录中，提供旧的服务器 UUID。

还原 mysqld-auto.cnf 文件以供 s3 使用（仅在 s3 使用持久系统变量时需要）。 失败的成员用于配置的 Section 7.1.9.3, “Persisted System Variables” 设置必须提供给恢复的成员。这些设置可以在失败的服务器的 mysqld-auto.cnf 文件中找到，您应该在步骤 2 中保存了该文件。将文件还原到恢复的服务器的数据目录中。请参阅 Restoring Persisted System Variables 中的说明，如果您没有该文件的副本。

启动恢复的服务器。 例如，在使用 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       |
+-------------+-------------+--------------+

将 s2 的备份复制到 s3 的主机上。 复制备份的确切方式取决于操作系统和可用的工具。在这个示例中，我们假设主机都是 Linux 服务器，并使用 SCP 将文件复制到它们之间：

s2/backups> scp my.mbi_2206_1429 s3:/backups

恢复备份。 连接到目标主机（在这个示例中是 s3 的主机），并使用 MySQL Enterprise Backup 恢复备份。以下是步骤：

恢复 mysqld-auto.cnf 文件（仅当 s3 使用持久系统变量时需要）。 失败的成员的配置设置，用于 第 7.1.9.3 节，“持久系统变量”，必须提供给恢复的服务器。这些设置可以在失败的服务器的 mysqld-auto.cnf 文件中找到，您应该在步骤 2 中将其保存到安全位置。请参阅 恢复持久系统变量，了解如果您没有该文件的副本该怎么办。

启动恢复的服务器。 例如，在使用 systemd 的 Linux 发行版上：

systemctl start mysqld

重新配置恢复的成员以加入组复制。 使用 mysql 客户端连接到恢复的服务器，并使用以下命令重置源和副本信息：

mysql> RESET BINARY LOGS AND GTIDS;

mysql> RESET REPLICA ALL;

为了使恢复的服务器能够使用组复制的分布式恢复机制自动恢复，需要配置服务器的 gtid_executed 变量。为此，请使用备份的 backup_gtid_executed.sql 文件，该文件通常位于恢复的成员数据目录下。禁用二进制日志记录，使用 backup_gtid_executed.sql 文件配置 gtid_executed，然后重新启用二进制日志记录：

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;

在恢复的实例可以成为组的在线成员之前，它需要应用组中发生的所有事务；这可以使用组复制的 分布式恢复 机制来实现，过程将在 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       |
+-------------+-------------+--------------+