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 Server 的商业许可备份实用程序，可通过 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 的备份

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，则必须让已恢复成员作为新成员加入组；请查看以下重建故障成员以重新加入为新成员中关于如何执行此操作的说明。
恢复 mysqld-auto.cnf 文件以用于 s3（仅当 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
```
  注意
  
  如果您在备份中拥有健康的二进制日志和中继日志，并且可以将它们毫无问题地传输到目标主机，建议您按照上面恢复故障成员中描述的更简单的过程操作。
恢复 mysqld-auto.cnf 文件以用于 s3（仅当 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

PREV HOME UP NEXT