先决条件

1.提供者和接受者必须具有相同的 MySQL 服务器版本。 MYSQL 8.0.17 及更高版本支持克隆插件。

2.提供者和接受者 MySQL 服务器实例必须在相同的操作系统和平台上运行。例如，如果提供者实例在 Linux 64 位平台上运行，则接收者实例也必须在该平台上运行。

3.接收者必须有足够的磁盘空间用于克隆数据。默认情况下，在克隆提供者数据之前删除接受者数据，因此您只需要足够的空间来存储提供者数据。如果使用 DATA DIRECTORY 子句克隆到命名目录，则必须有足够的磁盘空间用于现有的数据和克隆数据。您可以通过检查文件系统上的数据目录大小以及驻留在数据目录之外的任何表空间的大小来估计数据的大小。在估计提供者的数据大小时，请记住只有 InnoDB 数据被克隆。如果您将数据存储在其他存储引擎中，请相应地调整您的数据大小估计。

4.InnoDB 允许在数据目录之外创建一些表空间类型。如果提供者 MySQL 服务器实例具有驻留在数据目录之外的表空间，则克隆操作必须能够访问这些表空间。您可以查询 INFORMATION_SCHEMA.FILES 表以识别驻留在数据目录之外的表空间。驻留在数据目录之外的文件具有到数据目录以外的目录的完全限定路径。

5.在提供者上处于活动状态的插件，包括任何密钥环插件，在接受者身上也必须处于活动状态。您可以通过发出 SHOW PLUGINS 语句或查询 INFORMATION_SCHEMA.PLUGINS 表来识别活动插件。

6.提供者和接受者必须具有相同的 MySQL 服务器字符集和排序规则。

7.提供者和接受者需要相同的 innodb_page_size 和 innodb_data_file_path 设置。捐赠者和接受者的 innodb_data_file_path 设置必须指定相同数量的相同大小的数据文件。您可以使用 SHOW VARIABLES 语法检查变量设置。

8.如果克隆加密或页面压缩的数据，提供者和接收者必须具有相同的文件系统块大小。

9.如果您要克隆加密数据，则需要安全连接。

10.接收方的 clone_valid_donor_list 设置必须包含提供者 MySQL 服务器实例的主机地址。您只能从有效提供者列表中的主机克隆数据。需要具有 SYSTEM_VARIABLES_ADMIN 权限的 MySQL 用户来配置此变量。本节后面的远程克隆示例中提供了设置 clone_valid_donor_list 变量的说明。您可以使用 SHOW VARIABLES 语法检查 clone_valid_donor_list 设置。

11.不得有其他克隆操作正在运行。一次只允许进行一次克隆操作。要确定克隆操作是否正在运行，请查询 clone_status 表。

12.克隆插件以 1MB 数据包和元数据传输数据。因此，提供者和接收者 MySQL 服务器实例上所需的最小 max_allowed_packet 值是 2MB。 max_allowed_packet 值小于 2MB 会导致错误。

启用克隆插件

提供者和接受者必须具有相同的 MySQL 服务器版本。 MYSQL 8.0.17 及更高版本支持克隆插件。

在my.cnf添加如下配置4来启用插件：

[mysqld]
plugin-load-add=mysql_clone.so

在运行时加载插件，请使用如下语句：

INSTALL PLUGIN clone SONAME 'mysql_clone.so';

检查是否已安装：

show plugins;

SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME = 'clone';

在提供方和接收方均要安装插件。

克隆所需权限

在提供者上，克隆用户需要 BACKUP_ADMIN 权限才能访问和传输来自提供者的数据，以及在克隆操作期间阻止 DDL。
在接收方，克隆用户需要 CLONE_ADMIN 权限来替换接收方数据，在克隆操作期间阻塞 DDL，并自动重启服务器。 CLONE_ADMIN 权限隐含地包括 BACKUP_ADMIN 和 SHUTDOWN 权限。

在克隆实例(接收者)创建克隆账号并授权：

CREATE USER 'recipient_clone_user'@'example.recipient.host.com' IDENTIFIED BY '*password*';
GRANT CLONE_ADMIN on *.* to 'recipient_clone_user'@'example.recipient.host.com';

在被克隆实例(提供者)创建账号并授权：

CREATE USER 'donor_clone_user'@'example.donor.host.com' IDENTIFIED BY '*password*';
GRANT BACKUP_ADMIN on *.* to 'donor_clone_user'@'example.donor.host.com';

远程克隆

远程克隆语法：

CLONE INSTANCE FROM 'user'@'host':port
IDENTIFIED BY 'password'
[DATA DIRECTORY [=] 'clone_dir']
[REQUIRE [NO] SSL];

说明：

user 是捐赠者 MySQL 服务器实例上的克隆用户。
password 是用户密码。
host 是提供者 MySQL 服务器实例的主机名地址。不支持 Internet 协议版本 6 (IPv6) 地址格式。可以改用 IPv6 地址的别名。可以按原样使用 IPv4 地址。
port 是捐赠者 MySQL 服务器实例的端口号。（不支持 mysqlx_port 指定的 X 协议端口。也不支持通过 MySQL Router 连接到捐赠者 MySQL 服务器实例。）
DATA DIRECTORY [=] 'clone_dir' 是一个可选子句，用于为您要克隆的数据指定收件者的目录。如果您不想删除收件人数据目录中的现有数据，请使用此选项。需要绝对路径，目录不能存在。 MySQL 服务器必须具有创建目录所需的写入权限。
当不使用可选的 DATA DIRECTORY [=] 'clone_dir' 子句时，克隆操作会删除接收方数据目录中的现有数据，将其替换为克隆的数据，然后自动重新启动服务器。
[REQUIRE [NO] SSL] 明确指定在通过网络传输克隆数据时是否使用加密连接。如果不能满足显式规范，则返回错误。如果未指定 SSL 子句，默认情况下 clone 会尝试建立加密连接，如果安全连接尝试失败，则回退到不安全的连接。无论是否指定此子句，克隆加密数据时都需要安全连接。

注意：
默认情况下，驻留在提供方 MySQL 服务器实例上的数据目录中的用户创建的 InnoDB 表和表空间被克隆到接收方 MySQL 服务器实例上的数据目录中。如果指定了 DATA DIRECTORY [=] 'clone_dir' 子句，它们将被克隆到指定的目录。
驻留在提供者 MySQL 服务器实例上的数据目录之外的用户创建的 InnoDB 表和表空间被克隆到接收者 MySQL 服务器实例上的相同路径。如果表或表空间已存在，则会报告错误。
默认情况下，InnoDB 系统表空间、重做日志和undo表空间被克隆到在提供者上配置的相同位置（分别由 innodb_data_home_dir 和 innodb_data_file_path、innodb_log_group_home_dir 和 innodb_undo_directory 定义）。如果指定了 DATA DIRECTORY [=] 'clone_dir' 子句，则这些表空间和日志将被克隆到指定目录。

将提供者 MySQL 服务器实例的主机地址添加到 clone_valid_donor_list 变量设置中：

SET GLOBAL clone_valid_donor_list = 'example.donor.host.com:3306';

使用之前创建的克隆用户登录到接收者实例，并执行CLONE INSTANCE 语句：

CLONE INSTANCE FROM 'donor_clone_user'@'example.donor.host.com':3306 IDENTIFIED BY 'password';

数据克隆完成后，接收方的MySQL服务器实例会自动重启。

如果不想原目录的数据被替换，则执行：

CLONE INSTANCE FROM 'user'@'example.donor.host.com/':3306 IDENTIFIED BY 'password' DATA DIRECTORY = '/path/to/clone_dir';

需要绝对路径，目录不能存在。 MySQL 服务器必须具有创建目录所需的写入权限。
克隆到命名目录时，接收者 MySQL 服务器实例不会在数据克隆后自动重启。需要我们修改datadir或者手动执行mysqld_safe --datadir=/path/to/clone_dir

监控克隆操作

克隆操作可能需要一些时间才能完成，具体取决于数据量和与数据传输相关的其他因素。可以使用 clone_status 和 clone_progress Performance Schema 表监控接收方 MySQL 服务器实例上克隆操作的状态和进度。

注意：
clone_status 和 clone_progress Performance Schema 表只能用于监视接收方 MySQL 服务器实例上的克隆操作。要监视提供者 MySQL 服务器实例上的克隆操作，请使用克隆阶段事件，如使用性能架构阶段事件监视克隆操作中所述。

clone_status 表提供当前或上次执行的克隆操作的状态。克隆操作有四种可能的状态：未开始、进行中、已完成和失败。
clone_progress 表按阶段提供当前或上次执行的克隆操作的进度信息。克隆操作的阶段包括 DROP DATA、FILE COPY、PAGE_COPY、REDO_COPY、FILE_SYNC、RESTART 和 RECOVERY。

检查克隆操作的状态，在接收方执行：

SELECT STATE FROM performance_schema.clone_status;
SELECT STATE, ERROR_NO, ERROR_MESSAGE FROM performance_schema.clone_status;

查看克隆操作每个阶段的详细信息，在接收方执行：

SELECT STAGE, STATE, END_TIME FROM performance_schema.clone_progress;

克隆复制

这是个经常使用的场景，在线上MySQL增加从节点、或者从节点重构，都可以使用。

克隆插件支持复制。除了克隆数据之外，克隆操作还会从捐赠者那里提取复制坐标并将它们传输给接受者，这样就可以使用克隆插件来配置组复制成员和副本。使用克隆插件进行配置比复制大量事务更快、更有效。

组复制成员还可以配置为使用克隆插件作为分布式恢复的选项，在这种情况下，加入成员会自动选择最有效的方式从现有组成员检索组数据。

在克隆操作期间，二进制日志位置（文件名、偏移量）和 gtid_executed GTID 集都被提取并从提供者 MySQL 服务器实例传输到接收者。该数据允许在复制流中的一致位置启动复制。保存在文件中的二进制日志和中继日志不会从提供者复制到接收者。要启动复制，在克隆数据和开始复制之间，不得清除接收者赶上提供者所需的二进制日志。如果所需的二进制日志不可用，则会报告复制握手错误。因此，克隆实例应在没有过多延迟的情况下添加到复制组，以避免清除所需的二进制日志或新成员明显滞后，从而需要更多的恢复时间。

在克隆的 MySQL 服务器实例上发出此查询以检查传输到接收者的二进制日志位置：

SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;

在克隆的 MySQL 服务器实例上发出此查询以检查传输到接收者的 gtid_executed GTID 集：

SELECT @@GLOBAL.GTID_EXECUTED;

默认情况下，在 MySQL 8.0 中，复制元数据存储库保存在克隆操作期间从提供者复制到接收者的表中。复制元数据存储库保存与复制相关的配置设置，可用于在克隆操作后正确恢复复制。

在 MySQL 8.0.17 和 8.0.18 中，仅复制表 mysql.slave_master_info（连接元数据存储库）。
从 MySQL 8.0.19 开始，还复制了表 mysql.slave_relay_log_info（应用程序元数据存储库）和 mysql.slave_worker_info（应用程序工作器元数据存储库）。

请注意，如果设置 master_info_repository=FILE 和 relay_log_info_repository=FILE 在服务器上使用（这不是 MySQL 8.0 中的默认值并且已弃用），则不会克隆复制元数据存储库；只有在设置了 TABLE 时才会克隆它们。

要克隆以进行复制，请执行以下步骤：

1.对于组复制的新组成员，首先按照第 18.2.1.6 节“将实例添加到组”中的说明配置用于组复制的 MySQL 服务器实例。还要设置第 18.5.3.2 节 “分布式恢复的克隆”中描述的克隆先决条件。当您对加入成员发出 START GROUP_REPLICATION 时，克隆操作由 Group Replication 自动管理，因此您无需手动执行操作，也不需要对加入成员执行任何进一步的设置步骤。

2.对于源/副本 MySQL 复制拓扑中的副本，首先手动将数据从提供方 MySQL 服务器实例克隆到接收方。施主必须是复制拓扑中的源或副本。

3.克隆操作成功完成后，如果您想在提供者上存在的接收者 MySQL 服务器实例上使用相同的复制通道，请验证其中哪些可以在源/副本 MySQL 复制拓扑中自动恢复复制，哪些需要手动设置。

对于基于 GTID 的复制，如果接收者配置了 gtid_mode=ON 并且已经从具有 gtid_mode=ON、ON_PERMISSIVE 或 OFF_PERMISSIVE 的提供者克隆，则来自提供者的 gtid_executed GTID 集应用于接收者。如果接收者是从拓扑中已经存在的副本中克隆的，则使用 GTID 自动定位的接收者上的复制通道可以在通道启动后在克隆操作后自动恢复复制。如果您只想使用这些相同的频道，则无需执行任何手动设置。对于基于二进制日志文件位置的复制，如果接收者在 MySQL 8.0.17 或 8.0.18，则来自提供者的二进制日志位置不会应用于接收者，仅记录在 Performance Schema clone_status 表中。因此，必须手动设置收件人上使用基于二进制日志文件位置的复制的复制通道，以在克隆操作后恢复复制。确保这些通道未配置为在服务器启动时自动启动复制，因为它们还没有二进制日志位置并尝试从头开始复制。
对于基于二进制日志文件位置的复制，如果接收者在 MySQL 8.0.19 或更高版本，则来自提供者的二进制日志位置应用于接收者。在重新启动复制之前，使用基于二进制日志文件位置的复制的接收方上的复制通道会自动尝试使用克隆的中继日志信息执行中继日志恢复过程。对于单线程副本（slave_parallel_workers 设置为 0），中继日志恢复应该在没有任何其他问题的情况下成功，从而使通道无需进一步设置即可恢复复制。对于多线程副本（slave_parallel_workers 大于0），relay log 恢复很可能会失败，因为它通常无法自动完成。在这种情况下，会发出错误消息，您必须手动设置通道。

4.如果您需要手动设置克隆复制通道，或者想要在接收方使用不同的复制通道，以下说明提供了将接收方 MySQL 服务器实例添加到复制拓扑的摘要和缩略示例。另请参阅适用于您的复制设置的详细说明。

要将接收方 MySQL 服务器实例添加到使用基于 GTID 的事务作为复制数据源的 MySQL 复制拓扑，请按照第 17.1.3.4 节“使用 GTID 设置复制”中的说明配置实例。为实例添加复制通道，如以下缩写示例所示。 CHANGE REPLICATION SOURCE TO 语句（来自 MySQL 8.0.23）或 CHANGE MASTER TO 语句（MySQL 8.0.23 之前）必须定义源的主机地址和端口号，以及 SOURCE_AUTO_POSITION | 应启用 MASTER_AUTO_POSITION 选项，如下所示：

CHANGE MASTER TO MASTER_HOST = 'source_host_name', MASTER_PORT = source_port_num,
    ...
    MASTER_AUTO_POSITION = 1,
    FOR CHANNEL 'setup_channel';

START SLAVE USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel';

Or from MySQL 8.0.22 and 8.0.23:

 CHANGE SOURCE TO SOURCE_HOST = 'source_host_name', SOURCE_PORT = source_port_num,
    ...
    SOURCE_AUTO_POSITION = 1,
    FOR CHANNEL 'setup_channel';

START REPLICA USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel';

要将接收方 MySQL 服务器实例添加到使用基于二进制日志文件位置的复制的 MySQL 复制拓扑，请按照第 17.1.2 节“设置基于二进制日志文件位置的复制”中的说明，根据需要配置实例。使用在克隆操作期间传输到接收方的二进制日志位置，为实例添加复制通道，如下面的缩写示例所示：

 SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;

 CHANGE MASTER TO MASTER_HOST = 'source_host_name', MASTER_PORT = source_port_num,
...
MASTER_LOG_FILE = 'source_log_name',
MASTER_LOG_POS = source_log_pos,
FOR CHANNEL 'setup_channel';

START SLAVE USER = 'user_name' PASSWORD = 'password' FOR CHANNEL 'setup_channel';