MySQL:: MySQL 8.0参考手册::18.5.6使用MySQL企业备份与组复制

版本8.0

5.7

8.0日本

MySQL 8.0参考手册/.．./ 使用MySQL企业备份与组复制

18.5.6使用MySQL Enterprise Backup with Group Replication

MySQL企业备份是一个商业许可的MySQL服务器备份工具，可与MySQL企业版．介绍如何使用MySQL Enterprise Backup对Group Replication成员进行备份和恢复。同样的技术也可以用于快速向组中添加新成员。

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

备份一个Group Replication成员类似于备份一个独立的MySQL实例。下面的说明假设您已经熟悉如何使用MySQL Enterprise Backup执行备份;如果不是这样，请重新阅读MySQL Enterprise Backup 8.0用户指南,特别是备份数据库服务器．还要注意中描述的需求为备份管理员授予MySQL权限而且使用MySQL企业备份与组复制．

考虑下面这个有三个成员的小组，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 | | s2在线| | 3306 | | s3 | 3306 |在线  | +-------------+-------------+--------------+

使用MySQL企业备份，创建备份s2例如，通过在其主机上发出以下命令:

S2 > mysqlbackup——defaults-file=/etc/my.cnf——backup-image=/backups/my. cnfmbi_“日期+ % d % m_ % H % M ' \——backup-dir = /备份/ backup_“日期+ % d % m_ % H % M '——用户=根- p \主机127.0.0.1 backup-to-image

笔记

对于MySQL Enterprise Backup 8.0.18及更早版本，如果系统变量sql_require_primary_key被设置为在对于组，MySQL企业备份无法在服务器上记录备份进度。这是因为backup_progress表是一个CSV表，不支持主键。在这种情况下,mysqlbackup备份过程中会发出以下警告:

181011 11:17:06主要警告: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完成备份。

适用于MySQL Enterprise Backup 8.0.20及更早版本当备份一个次要成员时，由于MySQL Enterprise Backup不能将备份状态和元数据写入一个只读的服务器实例，它可能会在备份操作中发出类似如下的警告:
```
181113 21:31:08主要警告:此备份操作无法写入备份进度。MySQL服务器运行的是——超级只读选项。
```
可以通过使用——no-history-logging选项与备份命令。对于MySQL Enterprise Backup 8.0.21和更高版本来说，这不是问题使用MySQL企业备份与组复制获取详细信息。

恢复失败的成员

假设其中一个成员(s3在下面的例子中)是不可调和的损坏。组成员的最新备份s2能用来恢复吗s3．执行恢复的步骤如下:

将备份的s2拷贝到主机上用于s3。复制备份的确切方法取决于可用的操作系统和工具。在这个例子中，我们假设主机都是Linux服务器，并使用SCP在它们之间复制文件:
```
s2 /备份> scp我。mbi_2206_1429 s3: /备份
```
恢复备份。连接到目标主机s3，并使用MySQL Enterprise backup恢复备份。以下是步骤:
1. 如果损坏的服务器仍在运行，则停止它。例如，在使用systemd的Linux发行版上:
```
S3 > systemctl停止mysqld
```
2. 保存损坏服务器的数据目录中的两个配置文件，auto.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. cnf \mbi_2206_1429 \——backup-dir=/tmp/restore_ ' date +%d%m_%H%M ' copy-back- apply-log
```
  请注意
  
  上面的命令假设二进制日志和中继日志是打开的s2而且s3具有相同的基本名称，并且在两台服务器上的相同位置。如果不满足这些条件，则应该使用——log-bin而且——relay-log将二进制日志和中继日志恢复到其原始文件路径的选项s3．例如，如果你知道s3二进制日志的基名称为s3-bin中继日志的基本名称是s3-relay-bin，你的恢复命令应该是这样的:
```
mysql备份——defaults-file=/etc/my.cnf \——datadir=/var/lib/mysql \——backup-image=/backups/my. cnf \mbi_2206_1429 \——log-bin=s3-bin——relay-log=s3-relay-bin \——backup-dir=/tmp/restore_ ' date +%d%m_%H%M ' copy-back- apply-log
```
  能够将二进制日志和中继日志恢复到正确的文件路径使恢复过程更容易;如果这是不可能的，看重新生成失败的成员以重新加入为新成员．
恢复auto.cnf申请s3。重新加入复制组，恢复的成员必须有相同的server_uuid它以前也加入过这个组织。通过复制来提供旧服务器UUIDauto.cnf将上面第2步中保存的文件保存到恢复成员的数据目录中。

请注意

如果您不能提供失败成员的原件server_uuid通过恢复原来的成员而恢复原来的成员auto.cnf文件时，必须让恢复的成员以新成员的身份加入组;看到说明重新生成失败的成员以重新加入为新成员以下是如何做到这一点。
恢复mysqld-auto.cnfs3的文件(仅在s3使用持久系统变量时需要)。控件的设置第5.1.9.3节，“持久化系统变量”必须向恢复的成员提供用于配置失败成员的。这些设置可以在mysqld-auto.cnf故障服务器的文件，您应该在上面的步骤2中保存它。将文件恢复到恢复后的服务器的数据目录。看到恢复持久化的系统变量说明如果没有该文件的副本该如何处理。
启动恢复后的服务器。例如，在使用systemd的Linux发行版上:
```
systemctl开始mysqld
```
请注意

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

重启组复制。连接到重新启动的s3使用，例如，amysql并发出以下命令:

mysql >开始GROUP_REPLICATION;

在恢复的实例成为组的在线成员之前，它需要应用备份之后发生在组上的任何事务;这是通过使用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 | | s2在线| | 3306 | | s3 | 3306 |恢复  | +-------------+-------------+--------------+

这表明s3正在应用事务以赶上群组。一旦它赶上了集团的其他成员，它就member_state更改在线：

mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members+-------------+-------------+--------------+ | member_host | member_port | member_state  | +-------------+-------------+--------------+ | s1在线| | 3306 | | s2在线| | 3306 | | s3 | 3306 |在线  | +-------------+-------------+--------------+

请注意

如果正在恢复的服务器是主成员，那么一旦它获得了与组的同步，就变成在线，执行最后描述的步骤恢复主成员恢复在启动服务器之前对其所做的配置更改。

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

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

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

将备份的s2拷贝到主机上用于s3。复制备份的确切方法取决于可用的操作系统和工具。在这个例子中，我们假设主机都是Linux服务器，并使用SCP在它们之间复制文件:
```
s2 /备份> scp我。mbi_2206_1429 s3: /备份
```
恢复备份。连接到目标主机s3，并使用MySQL Enterprise backup恢复备份。以下是步骤:
1. 如果损坏的服务器仍在运行，则停止它。例如，在使用systemd的Linux发行版上:
```
S3 > systemctl停止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而且——skip-relaylog选项:
```
S3 > mysqlbackup——defaults-file=/etc/my.cnf \——datadir=/var/lib/mysql \——backup-image=/backups/my. cnf \mbi_2206_1429 \——backup-dir=/tmp/restore_ ' date +%d%m_%H%M ' \——skip-binlog——skip-relaylog \ copy-back- apply-log
```
  请注意
  
  如果备份中有健康的二进制日志和中继日志，可以毫无问题地传输到目标主机上，建议您遵循中描述的更简单的过程恢复失败的成员以上。
恢复mysqld-auto.cnfs3的文件(仅在s3使用持久系统变量时需要)。控件的设置第5.1.9.3节，“持久化系统变量”必须向恢复的服务器提供用于配置失败成员的。这些设置可以在mysqld-auto.cnf故障服务器的文件，您应该在上面的步骤2中保存它。将文件恢复到恢复后的服务器的数据目录。看到恢复持久化的系统变量说明如果没有该文件的副本该如何处理。

请注意

不恢复已损坏服务器的auto.cnf文件保存到新成员的数据目录—当重新生成时s3作为新成员加入组，它将被分配一个新的服务器UUID。
启动恢复后的服务器。例如，在使用systemd的Linux发行版上:
```
systemctl开始mysqld
```
请注意

如果正在恢复的服务器是主成员，请执行中描述的步骤恢复主成员在启动恢复的服务器之前．
重新配置恢复的成员以加入组复制。连接到恢复的服务器mysql使用以下命令重置源和副本信息:
```
mysql >重置主宰;
```
```
mysql> RESET SLAVE ALL或者从MySQL 8.0.22: MySQL > RESET REPLICA ALL;
```
使恢复的服务器能够使用组复制的内置机制自动恢复分布式恢复，配置服务器的gtid_executed变量。要做到这一点，使用backup_gtid_executed.sql的备份中包含的文件s2，通常在恢复成员的数据目录下恢复。禁用二进制日志记录，使用backup_gtid_executed.sql文件配置gtid_executed，然后通过使用您的mysql客户:
```
mysql >设置SQL_LOG_BIN =;mysql >源datadir/ backup_gtid_executed。设置SQL_LOG_BIN=ON;
```
然后,配置组复制用户凭据成员:
```
将MASTER修改为MASTER_USER='rpl_user”,MASTER_PASSWORD = '密码' / FOR CHANNEL 'group_replication_recovery';更改复制源为SOURCE_USER='rpl_user”,SOURCE_PASSWORD = '密码' / FOR CHANNEL 'group_replication_recovery';
```

重启组复制。使用您的命令向恢复的服务器发出以下命令mysql客户:

mysql >开始GROUP_REPLICATION;

mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members+-------------+-------------+--------------+ | member_host | member_port | member_state  | +-------------+-------------+--------------+ | s3 | 3306 |中| | s2在线| | 3306 | | s1 | 3306 |在线  | +-------------+-------------+--------------+

这表明s3正在应用事务以赶上群组。一旦它赶上了集团的其他成员，它就member_state更改在线：

mysql> SELECT member_host, member_port, member_state FROM performance_schema.replication_group_members+-------------+-------------+--------------+ | member_host | member_port | member_state  | +-------------+-------------+--------------+ | s3在线| | 3306 | | s2在线| | 3306 | | s1 | 3306 |在线  | +-------------+-------------+--------------+

请注意

该成员现在已作为新成员恢复到组中。

恢复持久化的系统变量。mysqlbackup不支持备份或保存第5.1.9.3节，“持久化系统变量”——文件mysqld-auto.cnf不包含在备份中。要启动恢复的成员及其持久变量设置，需要执行以下操作之一:

保存一个副本mysqld-auto.cnf文件，并将其复制到恢复的服务器的数据目录。
复制mysqld-auto.cnf如果组的另一个成员具有与已损坏成员相同的持久系统变量设置，则将该文件从组的另一个成员转移到已恢复的服务器的数据目录中。
启动恢复的服务器之后，在重新启动Group Replication之前，通过mysql客户端。

恢复主成员。如果恢复的成员是组中的主成员，则必须注意防止在组复制分布式恢复过程中对恢复的数据库进行写操作。根据客户端访问组的方式，一旦恢复的成员在网络上可以访问，就有可能在该成员完成它在组外错过的活动的追赶之前，在该成员上执行DML语句。为了避免这种情况,在启动恢复的服务器之前，在server选项文件中配置如下系统变量:

group_replication_start_on_boot =掉在event_scheduler super_read_only = =

这些设置确保成员在启动时变为只读，并且当成员在分布式恢复过程中赶上组时关闭事件调度器。还必须在客户机上配置足够的错误处理，因为在此期间，客户机暂时不能对恢复的成员执行DML操作。恢复过程完全完成后，恢复的成员与组的其他成员同步，恢复这些更改;重新启动事件调度程序:

设置全局event_scheduler=ON;

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

group_replication_start_on_boot =从event_scheduler super_read_only = =

上一页首页向上下一个