MySQL8 中文参考（八十一）（6）

MySQL8 中文参考（八十一）（5）https://developer.aliyun.com/article/1566077

恢复失败的成员

假设其中一个成员（以下示例���的s3）无法协调。可以使用组成员s2的最新备份来恢复s3。以下是执行恢复的步骤：

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

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

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

1. 停止受损服务器，如果它仍在运行。例如，在使用 systemd 的 Linux 发行版上：

s3> systemctl stop mysqld

1. 将受损服务器的数据目录中的两个配置文件auto.cnf和mysqld-auto.cnf（如果存在）复制到数据目录之外的安全位置以保存服务器的 UUID 和 Section 7.1.9.3，“持久化系统变量”（如果使用），这些在下面的步骤中是必需的。
   
2. 删除s3的数据目录中的所有内容。例如：

s3> rm -rf /var/lib/mysql/*

1. 如果系统变量innodb_data_home_dir，innodb_log_group_home_dir，和innodb_undo_directory指向除数据目录之外的任何目录，则它们也应该被清空；否则，恢复操作将失败。
2. 将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

1. 注意
   上述命令假定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

1. 能够将二进制日志和中继日志恢复到正确的文件路径会使恢复过程更容易；如果由于某种原因这是不可能的，请参阅重建失败的成员以作为新成员重新加入。

1. 恢复 s3 的auto.cnf文件。为了重新加入复制组，恢复的成员必须具有加入组之前使用的相同的server_uuid。通过将在步骤 2 中保留的auto.cnf文件复制到恢复成员的数据目录中来提供旧的服务器 UUID。
   注意
   如果您无法通过恢复其旧的auto.cnf文件向恢复的成员提供失败成员的原始server_uuid，则必须让恢复的成员作为新成员加入组；请参见下面的重建失败的成员以重新加入作为新成员中的说明。
   
2. 为s3恢复mysqld-auto.cnf文件（仅在s3使用持久系统变量时需要）。 必须提供用于配置失败成员的 Section 7.1.9.3，“持久系统变量”的设置，这些设置可以在失败服务器的mysqld-auto.cnf文件中找到，您应该在上述第 2 步中保留该文件。将文件恢复到恢复服务器的数据目录中。请参阅恢复持久系统变量以了解如果没有文件副本该怎么办。
   
3. 启动恢复服务器。 例如，在使用 systemd 的 Linux 发行版上：

systemctl start mysqld

1. 注意
   如果您正在恢复的服务器是主要成员，请在启动恢复服务器之前执行恢复主要成员中描述的步骤。
2. 重新启动 Group Replication。 连接到重新启动的s3，例如，使用mysql客户端，并执行以下命令：

mysql> START GROUP_REPLICATION

1. 在恢复的实例可以成为组的在线成员之前，需要应用在备份之后发生的任何事务；这是通过使用 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   |
+-------------+-------------+--------------+

1. 这表明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       |
+-------------+-------------+--------------+

1. 注意
   如果您正在恢复的服务器是主要成员，一旦它与组同步并变为ONLINE，请执行恢复主要成员末尾描述的步骤，以恢复您在启动服务器之前所做的配置更改。

该成员现在已经完全从备份中恢复，并作为组的常规成员运行。

重建失败的成员以重新加入作为新成员

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

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

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

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

1. 停止受损的服务器，如果它仍在运行。例如，在使用 systemd 的 Linux 发行版上：

s3> systemctl stop mysqld

1. 保留配置文件mysqld-auto.cnf，如果在受损服务器的数据目录中找到，则将其复制到数据目录之外的安全位置。这是为了保留服务器的第 7.1.9.3 节，“持久化系统变量”，稍后会用到。
   
2. 删除s3的数据目录中的所有内容。例如：

s3> rm -rf /var/lib/mysql/*

1. 如果系统变量innodb_data_home_dir、innodb_log_group_home_dir和innodb_undo_directory指向除数据目录以外的任何目录，则这些目录也应该清空；否则，恢复操作将失败。
2. 将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

1. 注意
   如果您在备份中有健康的二进制日志和中继日志，可以毫无问题地将其传输到目标主机上，建议您按照上述恢复失败成员中描述的更简单的过程进行操作。

1. 为s3恢复mysqld-auto.cnf文件（仅在s3使用持久系统变量时需要）。 必须提供用于配置失败成员的 Section 7.1.9.3, “Persisted System Variables”的设置，这些设置可以在失败服务器的mysqld-auto.cnf文件中找到，您应该在上述第 2 步中保留该文件。将文件恢复到恢复服务器的数据目录中。如果您没有文件副本，则请参阅恢复持久系统变量。
   注意
   不要将损坏服务器的auto.cnf文件恢复到新成员的数据目录中——当重建的s3作为新成员加入组时，它将被分配一个新的服务器 UUID。
   
2. 启动恢复的服务器。 例如，在使用 systemd 的 Linux 发行版上：

systemctl start mysqld

1. 注意
   如果您正在恢复的服务器是主要成员，请在启动恢复的服务器之前执行恢复主要成员中描述的步骤。
2. 重新配置恢复的成员以加入组复制。 使用mysql客户端连接到恢复的服务器，并使用以下命令重置源和副本信息：

mysql> RESET MASTER;

mysql> RESET SLAVE ALL;
Or from MySQL 8.0.22:
mysql> RESET REPLICA ALL;

1. 为了使恢复的服务器能够使用组复制的内置机制进行分布式恢复，配置服务器的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;

1. 然后，在成员上配置组复制用户凭据：

mysql> CHANGE MASTER TO MASTER_USER='*rpl_user*', MASTER_PASSWORD='*password*' /
    FOR CHANNEL 'group_replication_recovery';
Or from MySQL 8.0.23:
mysql> CHANGE REPLICATION SOURCE TO SOURCE_USER='*rpl_user*', SOURCE_PASSWORD='*password*' /
    FOR CHANNEL 'group_replication_recovery';

1. 重新启动组复制。 使用您的mysql客户端向恢复的服务器发出以下命令：

mysql> START GROUP_REPLICATION;

1. 在恢复的实例可以成为组的在线成员之前，需要将备份后组中发生的任何事务应用到实例上；这是通过使用  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       |
+-------------+-------------+--------------+

1. 这表明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       |
+-------------+-------------+--------------+

1. 注意
   如果您正在恢复的服务器是主要成员，在它与组同步并变为ONLINE后，执行恢复主要成员末尾描述的步骤，以恢复在启动之前对服务器所做的配置更改。

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

恢复持久化系统变量。 mysqlbackup不支持备份或保留 Section 7.1.9.3, “Persisted System Variables” ——文件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

务器发出以下命令：

```sql
mysql> START GROUP_REPLICATION;
```
在恢复的实例可以成为组的在线成员之前，需要将备份后组中发生的任何事务应用到实例上；这是通过使用 Group Replication 的分布式恢复机制实现的，该过程在发出 START GROUP_REPLICATION 语句后开始。要检查恢复实例的成员状态，请执行：
```sql
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`：
```sql
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       |
+-------------+-------------+--------------+
```
注意
如果您正在恢复的服务器是主要成员，在它与组同步并变为`ONLINE`后，执行恢复主要成员末尾描述的步骤，以恢复在启动之前对服务器所做的配置更改。

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

恢复持久化系统变量。 mysqlbackup不支持备份或保留 Section 7.1.9.3, “Persisted System Variables” ——文件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