使用MySQL Enterprise Backup和组复制

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

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

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

注意

• 如果该组的系统变量sql_require_primary_key设置ON为，则MySQL Enterprise Backup将无法在服务器上记录备份进度。这是因为backup_progress服务器上的表是CSV表，因此不支持主键。在这种情况下，mysqlbackup在备份操作期间会发出以下警告：

  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.
  

但是，这不会阻止mysqlbackup完成备份。

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.

恢复失败的成员

假定其中一个成员（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. 保留两个配置文件在被破坏的服务器的数据目录，auto.cnf以及mysqld-auto.cnf（如果存在的话），通过将它们复制到数据目录的安全位置之外。这是为了保留服务器的UUID 和“持久性系统变量”（如果使用），这在下面的步骤中是必需的。

   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
      

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

3. 还原auto.cnfs3 的文件。要重新加入复制组，还原的成员必须具有与加入复制server_uuid组之前相同的成员。通过将auto.cnf以上步骤2中保留的文件复制到已还原成员的数据目录中，以提供旧服务器UUID 。

   注意

   如果无法server_uuid通过还原故障成员的旧auto.cnf文件来将故障成员的原始文件提供给还原成员，则必须让还原成员作为新成员加入该组；有关如何执行此操作的信息，请参阅下面的“重建失败的成员以新成员的身份重新加入”中的说明。

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

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

   systemctl start mysqld
   

   注意

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

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

   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：

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如果配置文件在损坏的服务器的数据目录中找到，则将其复制到数据目录之外的安全位置，以保留该文件。这是为了保留服务器的“持久性系统变量”，这在以后需要。

   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
      

      注意

      如果备份中具有正常的二进制日志和中继日志，可以毫无问题地传输到目标主机，则建议您按照上面的“还原失败的成员”中所述的简单步骤进行操作。

3. 还原mysqld-auto.cnf s3 的文件（仅当s3使用持久性系统变量时才需要）。必须将用于配置故障成员的“持久性系统变量”的设置提供给还原的服务器。这些设置可以在mysqld-auto.cnf故障服务器的文件中找到，您应该在上面的步骤2中保留了这些设置。将文件还原到还原的服务器的数据目录。如果您没有该文件的副本，请参阅恢复永久性系统变量。

   注意

   请勿将损坏的服务器auto.cnf文件还原到新成员的数据目录中-重建文件s3作为新成员加入组时，将为其分配新服务器UUID。

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

   systemctl start mysqld
   

   注意

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

5. 重新配置还原的成员以加入组复制。使用 mysql客户端连接到已还原的服务器，并使用以下命令重置主服务器和从服务器信息：

   mysql> RESET MASTER;
   

   mysql> RESET SLAVE ALL;
   

   为了使还原的服务器能够使用组复制的内置分布式恢复机制自动恢复，请配置服务器的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';
   

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

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

   注意

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

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

恢复持久性系统变量。mysqlbackup不支持备份或保留“持久性系统变量”-该文件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