MySQL 中文文档

# 18.5.6 使用 MySQL Enterprise Backup 和 Group Replication

MySQL 企业备份 (opens new window)是 MySQL 服务器的商业许可备份实用程序，可通过MySQL企业版 (opens new window).本节说明如何使用 MySQL Enterprise Backup 备份和随后恢复 Group Replication 成员。可以使用相同的技术快速将新成员添加到组中。

# 使用 MySQL Enterprise Backup 备份组复制成员

备份组复制成员类似于备份独立的 MySQL 实例。以下说明假设您已经熟悉如何使用 MySQL Enterprise Backup 执行备份；如果不是这种情况，请查看MySQL 企业备份 8.0 用户指南 (opens new window)， 尤其备份数据库服务器 (opens new window).另请注意中描述的要求将 MySQL 权限授予备份管理员 (opens new window)和将 MySQL Enterprise Backup 与组复制一起使用 (opens new window).

考虑以下具有三个成员的组，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

笔记

  • *对于 MySQL Enterprise Backup 8.0.18 及更早版本，*如果系统变量sql_require_primary_key被设定为在对于该组，MySQL Enterprise Backup 无法记录服务器上的备份进度。这是因为备份进度服务器上的表是 CSV 表，不支持主键。在这种情况下，mysql备份在备份操作期间发出以下警告：

    181011 11:17:06 MAIN WARNING: MySQL query 'CREATE TABLE IF NOT EXISTS
mysql.backup_progress( `backup_id` BIGINT NOT NULL, `tool_name` VARCHAR(4096)
NOT NULL, `error_code` INT NOT NULL, `error_message` VARCHAR(4096) NOT NULL,
`current_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP               ON
UPDATE CURRENT_TIMESTAMP,`current_state` VARCHAR(200) NOT NULL ) ENGINE=CSV
DEFAULT CHARSET=utf8 COLLATE=utf8_bin': 3750, Unable to create a table
without PK, when system variable 'sql_require_primary_key' is set. Add a PK
to the table or unset this variable to avoid this message. Note that tables
without PK can cause performance problems in row-based replication, so please
consult your DBA before changing this setting.
181011 11:17:06 MAIN WARNING: This backup operation's progress info cannot be
logged.

    这并不妨碍mysql备份从完成备份虽然。

  • 对于 MySQL Enterprise Backup 8.0.20 及更早版本，备份次要成员时，由于 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.

    您可以使用--无历史记录选项与您的备份命令。对于 MySQL Enterprise Backup 8.0.21 及更高版本，这不是问题——请参阅将 MySQL Enterprise Backup 与组复制一起使用 (opens new window)详情。

# 恢复失败的成员

假设其中一个成员 (s3在下面的例子中）是不可调和的损坏。组成员的最新备份s2可以用来恢复s3.以下是执行还原的步骤：

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

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

  2. *恢复备份。*连接到目标主机（主机为s3在这种情况下），并使用 MySQL Enterprise Backup 还原备份。以下是步骤：

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

      s3> systemctl stop mysqld

    2. 在损坏的服务器的数据目录中保留两个配置文件，自动.cnf和mysqld-auto.cnf（如果存在），将它们复制到数据目录之外的安全位置。这是为了保存服务器的 UUID和第 5.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 (opens new window)和--中继日志 (opens new window)将二进制日志和中继日志恢复到其原始文件路径的选项s3.例如，如果你知道s3二进制日志的基本名称是s3-bin中继日志的基本名称是s3-中继箱，您的恢复命令应如下所示：

      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

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

  3. 恢复自动.cnfs3 的文件。要重新加入复制组，恢复的成员必须有相同的server_uuid以前是进群的。通过复制提供旧的服务器 UUID自动.cnf将上述步骤 2 中保存的文件放入已恢复成员的数据目录中。

    笔记

    如果您无法提供失败成员的原件server_uuid通过恢复其旧的给恢复的成员自动.cnf文件，您必须让恢复的成员以新成员的身份加入群组；请参阅中的说明重建失败的成员以重新加入为新成员下面介绍如何做到这一点。

  4. *恢复mysqld-auto.cnfs3 的文件（仅当 s3 使用持久系统变量时才需要）。*的设置第 5.1.9.3 节，“持久系统变量”必须将用于配置失败成员的内容提供给恢复的成员。这些设置可以在mysqld-auto.cnf故障服务器的文件，您应该在上面的步骤 2 中保留该文件。将文件还原到还原服务器的数据目录。看恢复持久的系统变量如果您没有该文件的副本该怎么办。

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

    systemctl start mysqld

    笔记

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

  6. *重新启动组复制。*连接到重启s3例如，使用mysql客户端，并发出以下命令：

    mysql> START GROUP_REPLICATION;

    在恢复的实例可以成为该组的在线成员之前，它需要应用备份后该组发生的任何事务；这是使用 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正在应用事务以赶上该组。一旦它赶上了其他人，它会员国更改为在线的：

    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       |
+-------------+-------------+--------------+

    笔记

    如果您要恢复的服务器是主要成员，一旦它与组同步并成为在线的，执行末尾描述的步骤恢复主要成员恢复您在启动服务器之前对服务器所做的配置更改。

    该成员现在已从备份中完全恢复，并作为该组的普通成员发挥作用。

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

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

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

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

  2. *恢复备份。*连接到目标主机（主机为s3在这种情况下），并使用 MySQL Enterprise Backup 还原备份。以下是步骤：

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

      s3> systemctl stop mysqld

    2. 保留配置文件mysqld-auto.cnf，如果在损坏的服务器的数据目录中找到它，请将其复制到数据目录之外的安全位置。这是为了保存服务器的第 5.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 (opens new window)和--skip-relaylog (opens new window)选项：

      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

      笔记

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

  3. *恢复mysqld-auto.cnfs3 的文件（仅当 s3 使用持久系统变量时才需要）。*的设置第 5.1.9.3 节，“持久系统变量”必须将用于配置失败成员的内容提供给恢复的服务器。这些设置可以在mysqld-auto.cnf故障服务器的文件，您应该在上面的步骤 2 中保留该文件。将文件还原到还原服务器的数据目录。看恢复持久的系统变量如果您没有该文件的副本该怎么办。

    笔记

    不要恢复损坏的服务器自动.cnf文件到新成员的数据目录——重建时s3作为新成员加入组，它将被分配一个新的服务器 UUID。

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

    systemctl start mysqld

    笔记

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

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

    mysql> RESET MASTER;

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

    使恢复的服务器能够使用 Group Replication 的内置机制自动恢复分布式恢复, 配置服务器的gtid_executed多变的。为此，请使用backup_gtid_executed.sql包含在备份中的文件s2，通常在被恢复成员的数据目录下恢复。禁用二进制日志，使用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 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';

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

    mysql> START GROUP_REPLICATION;

    在恢复的实例可以成为该组的在线成员之前，它需要应用备份后该组发生的任何事务；这是使用 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正在应用事务以赶上该组。一旦它赶上了其他人，它会员国更改为在线的：

    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不支持备份或保存第5.1.9.3节，“持久化系统变量”-档案mysqld自动。cnf不包括在备份中。要使用持久化变量设置启动还原的成员，需要执行以下操作之一：

  • 保存一份mysqld自动。cnf文件，并将其复制到还原服务器的数据目录。

  • 抄袭mysqld自动。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

← 18.6 组复制安全 →