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

版本8.0

5.7

8.0日本

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

18.5.6使用MySQL企业备份与组复制

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

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

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

考虑下面这个有三个成员的小组，s1，s2,s3，运行在具有相同名称的主机上:

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查询“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从完成备份开始。

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

恢复失败的成员

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

将s3的备份拷贝到主机上。复制备份的确切方法取决于您可用的操作系统和工具。在本例中，我们假设主机都是Linux服务器，并使用SCP在它们之间复制文件:
```
S2 /备份> SCP my。mbi_2206_1429 s3: /备份
```
恢复备份。连接到目标主机(用于s3在这种情况下)，并使用MySQL企业备份恢复备份。以下是步骤:
1. 停止损坏的服务器，如果它仍在运行。例如，在使用systemd的Linux发行版上:
```
S3 > systemctl stop mysqld . sh
```
2. 在损坏的服务器的数据目录中保存两个配置文件，auto.cnf而且mysqld-auto.cnf(如果存在的话)，将它们复制到数据目录之外的安全位置。这是为了保存服务器的UUID而且第5.1.9.3节“持久系统变量”(如果已使用)，这是在下面的步骤中需要的。
3. 的data目录下的所有内容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. cnfmbi_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，你的restore命令应该如下所示:
```
Mysqlbackup——defaults-file=/etc/my.cnf \——datadir=/var/lib/mysql \——backup-image=/backups/my. cnfmbi_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.cnfs3文件。当需要重新加入复制组时，被恢复的成员必须有相同的server_uuid它以前也加入过这个团体。文件提供旧的服务器UUIDauto.cnf将上面步骤2中保存的文件保存到恢复成员的数据目录中。

请注意

如果您不能提供失败会员的原件server_uuid通过恢复其旧的auto.cnf文件，您必须让恢复的成员作为新成员加入组;参见重建失败的成员以重新加入为新成员下面将介绍如何做到这一点。
恢复mysqld-auto.cnfs3的文件(仅在s3使用持久系统变量时需要)。的设置第5.1.9.3节“持久系统变量”用于配置失败成员的数据必须提供给恢复的成员。这些设置可以在mysqld-auto.cnf故障服务器的文件，您应该在上面的第2步中保存它。将文件恢复到恢复的服务器的data目录。看到恢复持久化系统变量关于如果您没有文件的副本该怎么办。
启动恢复后的服务器。例如，在使用systemd的Linux发行版上:
```
Systemctl启动mysqld
```
请注意

如果要恢复的服务器是主要成员，请执行中描述的步骤恢复主成员在启动恢复的服务器之前．
重新启动组复制。连接到重新启动的s3例如，使用amysql客户端，并发出以下命令:
```
mysql启动GROUP_REPLICATION;
```
在恢复的实例成为组的在线成员之前，它需要应用在执行备份之后发生在组中的任何事务;这是通过使用组复制实现的分布式恢复机制，过程在开始GROUP_REPLICATION声明已经发表。要检查恢复实例的成员状态，发出:
```
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更改在线：
```
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：

将s3的备份拷贝到主机上。复制备份的确切方法取决于您可用的操作系统和工具。在本例中，我们假设主机都是Linux服务器，并使用SCP在它们之间复制文件:
```
S2 /备份> SCP my。mbi_2206_1429 s3: /备份
```
恢复备份。连接到目标主机(用于s3在这种情况下)，并使用MySQL企业备份恢复备份。以下是步骤:
1. 停止损坏的服务器，如果它仍在运行。例如，在使用systemd的Linux发行版上:
```
S3 > systemctl stop mysqld . sh
```
2. 保存配置文件mysqld-auto.cnf，如果在损坏的服务器的数据目录中发现它，则将其复制到数据目录之外的安全位置。这是为了保存服务器的第5.1.9.3节“持久系统变量”，这些是以后需要的。
3. 的data目录下的所有内容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. cnfmbi_2206_1429 \——backup-dir=/tmp/restore_ ' date +%d%m_%H%M ' \——skip-binlog——skip-relaylog \ copy-back-and-apply-log
```
  请注意
  
  如果备份中有正常的二进制日志和中继日志，可以毫无问题地将其传输到目标主机上，建议遵循中所述的更简单的过程恢复失败的成员以上。
恢复mysqld-auto.cnfs3的文件(仅在s3使用持久系统变量时需要)。的设置第5.1.9.3节“持久系统变量”用于配置失败成员的信息必须提供给恢复的服务器。这些设置可以在mysqld-auto.cnf故障服务器的文件，您应该在上面的第2步中保存它。将文件恢复到恢复的服务器的data目录。看到恢复持久化系统变量关于如果您没有文件的副本该怎么办。

请注意

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

如果要恢复的服务器是主要成员，请执行中描述的步骤恢复主成员在启动恢复的服务器之前．
重新配置恢复的成员以加入组复制。连接到恢复的服务器mysql客户端，使用以下命令重置源和副本信息:
```
mysql> RESET MASTER;
```
```
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客户:
```
SET SQL_LOG_BIN=OFF;mysql >源datadir/ backup_gtid_executed。SQL_LOG_BIN=ON;
```
然后，配置组复制用户凭据对成员:
```
修改MASTER为MASTER_USER='rpl_user”,MASTER_PASSWORD = '密码' / FOR CHANNEL 'group_replication_recovery';或者从MySQL 8.0.23: MySQL > CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user”,SOURCE_PASSWORD = '密码' / FOR CHANNEL 'group_replication_recovery';
```

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

mysql启动GROUP_REPLICATION;

在恢复的实例成为组的在线成员之前，它需要应用在执行备份之后发生在组中的任何事务;这是通过使用组复制实现的分布式恢复机制，过程在开始GROUP_REPLICATION声明已经发表。要检查恢复实例的成员状态，发出:

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更改在线：

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客户端。

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

group_replication_start_on_boot=OFF super_read_only=ON event_scheduler=OFF

这些设置确保成员在启动时变为只读，并确保在分布式恢复过程中成员与组保持同步时关闭事件调度程序。还必须在客户端上配置适当的错误处理，因为在此期间，它们会暂时禁止在恢复的成员上执行DML操作。一旦恢复过程完全完成，并且恢复的成员与组的其他成员同步，就恢复这些更改;重新启动事件调度程序:

SET global event_scheduler=ON;

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

group_replication_start_on_boot=ON super_read_only=OFF event_scheduler=ON

上一页首页向上下一个