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

如果您要恢复的服务器是主成员，请在恢复主成员中描述的步骤 在启动恢复的服务器之前 执行。

重新启动组复制。 使用例如 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