17.4.4 通过组复制使用 MySQL Enterprise Backup

MySQL 企业备份是 MySQL Server 的商业许可的备份 Util，可用于MySQL 企业版。本节说明如何使用 MySQL Enterprise Backup 备份和随后还原组复制成员。可以使用相同的技术将新成员快速添加到组中。

使用 MySQL 企业备份来备份组复制成员

备份组复制成员类似于备份独立的 MySQL 实例。以下说明假定您已经熟悉如何使用 MySQL Enterprise Backup 执行备份。如果不是这种情况，请查看MySQL Enterprise Backup 4.1 用户指南，尤其是备份数据库服务器。还要注意向备份 Management 员授予 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

Note

  • 对于 MySQL Enterprise Backup 4.1.1 和更早版本，在备份辅助成员时，由于 MySQL Enterprise Backup 无法将备份状态和元数据写入只读服务器实例，因此在备份操作期间会发出以下警告：
181113 21:31:08 MAIN WARNING: This backup operation cannot write to backup
progress. The MySQL server is running with the --super-read-only option.

您可以通过在备份命令中使用--no-history-logging选项来避免该警告。对于 MySQL Enterprise Backup 4.1.2 和更高版本，这不是问题-有关详细信息，请参见将 MySQL Enterprise Backup 与组复制一起使用。

恢复失败的成员

假定其中一个成员(在下面的示例中为s3)是不可调和地损坏的。组成员s2的最新备份可用于还原s3。以下是执行还原的步骤：

  • *将 s2 的备份复制到 s3 的主机上.*复制备份的确切方法取决于您使用的 os 和工具。在此示例中，我们假设主机都是 Linux 服务器，并使用 SCP 在它们之间复制文件：
s2/backups> scp my.mbi_2206_1429 s3:/backups

  • *还原备份.*连接到目标主机(在本例中为s3的主机)，然后使用 MySQL Enterprise Backup 还原备份。步骤如下：

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

s3> systemctl stop mysqld

  • 通过将配置文件auto.cnf复制到数据目录之外的安全位置，可以保留该文件位于损坏的服务器数据目录中。这是为了保留server's UUID，稍后需要。

  • 删除s3数据目录中的所有内容。例如：

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

如果系统变量innodb_data_home_dir，innodb_log_group_home_dir和innodb_undo_directory指向数据目录以外的任何目录，则还应将它们设置为空；否则，它们应该为空。否则，还原操作将失败。

  • 将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上的二进制日志和中继日志具有相同的基本名称，并且在两个服务器上的相同位置。如果不满足这些条件，则对于 MySQL Enterprise Backup 4.1.2 和更高版本，应使用--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

能够将二进制日志和中继日志还原到正确的文件路径使还原过程变得更加容易。如果由于某种原因无法实现，请参见重建失败的成员以重新加入为新成员。

  • 将auto.cnf文件还原为 s3.要重新加入复制组，已还原的成员必须具有以前加入该组所用的server_uuid。通过将上面第 2 步中保留的auto.cnf文件复制到已还原成员的数据目录中，以提供旧服务器 UUID。

Note

如果无法通过恢复故障成员的旧auto.cnf文件来将故障成员的原始server_uuid提供给恢复的成员，则必须让恢复的成员作为新成员加入该组；请参阅下面的重建失败的成员以重新加入为新成员中的说明。

  • *启动还原的服务器.*例如，在使用 systemd 的 Linux 发行版上：
systemctl start mysqld

Note

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

  • *重新启动组复制.*使用mysqlClient 端连接到重新启动的s3，并发出以下命令：
mysql> START GROUP_REPLICATION;

在还原的实例成为该组的联机成员之前，它需要应用备份后该组发生的所有事务。这是使用组复制的distributed recovery机制实现的，并且该过程在发出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   |
+-------------+-------------+--------------+

这 table 明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，请执行恢复主要成员末尾描述的步骤以还原在启动服务器之前对服务器所做的配置更改。

现在，该成员已从备份中完全还原，并成为该组的常规成员。

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

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

  • *将 s2 的备份复制到 s3 的主机上.*复制备份的确切方法取决于您使用的 os 和工具。在此示例中，我们假设主机都是 Linux 服务器，并使用 SCP 在它们之间复制文件：
s2/backups> scp my.mbi_2206_1429 s3:/backups

  • *还原备份.*连接到目标主机(在本例中为s3的主机)，然后使用 MySQL Enterprise Backup 还原备份。步骤如下：

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

s3> systemctl stop mysqld
  • 删除s3数据目录中的所有内容。例如：
s3> rm -rf /var/lib/mysql/*

如果系统变量innodb_data_home_dir，innodb_log_group_home_dir和innodb_undo_directory指向数据目录以外的任何目录，则还应将它们设置为空；否则，它们应该为空。否则，还原操作将失败。

  • 将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

Notes

  • 如果备份中具有正常的二进制日志和中继日志，可以毫无问题地传输到目标主机，则建议按照上面恢复失败的成员所述执行更简单的过程。

  • 不要将损坏的服务器的auto.cnf文件手动恢复到新成员的数据目录中，当重建的s3作为新成员加入组时，将为其分配新的服务器 UUID。

  • *启动还原的服务器.*例如，在使用 systemd 的 Linux 发行版上：
systemctl start mysqld

Note

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

  • *重新配置恢复的成员以加入组复制.*使用mysqlClient 端连接到恢复的服务器，并使用以下命令重置源和副本信息：
mysql> RESET MASTER;

mysql> RESET SLAVE ALL;

为了使还原的服务器能够使用 Group Replication 的内置机制distributed recovery自动恢复，请配置服务器的gtid_executed变量。为此，请使用s2备份中包含的backup_gtid_executed.sql文件，该文件通常在已还原成员的数据目录下进行还原。禁用二进制日志记录，使用backup_gtid_executed.sql文件配置gtid_executed，然后通过与mysqlClient 端一起发出以下语句来重新启用二进制日志记录：

mysql> SET SQL_LOG_BIN=OFF;
mysql> SOURCE datadir/backup_gtid_executed.sql
mysql> SET SQL_LOG_BIN=ON;

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

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' /
		FOR CHANNEL 'group_replication_recovery';
  • *重新启动组复制.*使用mysqlClient 端向已还原的服务器发出以下命令：
mysql> START GROUP_REPLICATION;

在还原的实例成为该组的联机成员之前，它需要应用备份后该组发生的所有事务。这是使用组复制的distributed recovery机制实现的，并且该过程在发出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       |
+-------------+-------------+--------------+

这 table 明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       |
+-------------+-------------+--------------+

Note

如果要还原的服务器是主要成员，则该服务器与组同步后成为ONLINE，请执行恢复主要成员末尾描述的步骤，以还原在启动服务器之前对服务器所做的配置更改。

该成员现在已作为新成员还原到组中。

还原主要成员. 如果还原的成员是组中的主要成员，则必须注意防止在组复制恢复阶段写入还原的数据库：根据 Client 端访问该组的方式，一旦在网络上可以访问已还原的成员，DMR 语句就有可能在该成员上完成，然后该成员完成对脱离组时错过的活动的追赶。为了避免这种情况，请在启动还原的服务器之前，在服务器选项文件中配置以下系统变量：

group_replication_start_on_boot=OFF
super_read_only=ON
event_scheduler=OFF

这些设置可确保成员在启动时变为只读状态，并确保在恢复阶段成员追赶组时关闭事件计划程序。还必须在 Client 端上配置足够的错误处理，因为在此期间将暂时阻止它们对还原的成员执行 DML 操作。一旦还原过程完全完成，并且还原的成员与该组的其余成员同步，则还原这些更改；重新启动事件调度程序：

mysql> SET global event_scheduler=ON;

在成员的选项文件中编辑以下系统变量，以便为下次启动正确配置内容：

group_replication_start_on_boot=ON
super_read_only=OFF
event_scheduler=ON
Name MySql 中文文档
Version
Language
Badge
Last Updated 2021-07-03T12:24:35