MySQL8.0.17 推出Clone Plugin功能，Clone Plugin允许在本地或从远程MySQL实例克隆数据。克隆数据是存储在InnoDB其中的数据的物理快照，其中包括库、表、表空间和数据字典元数据。克隆的数据包含一个功能齐全的数据目录，允许使用克隆插件进行MySQL服务器配置。其中复制源实例称为Donor，接受实例称为Recipient。

Clone Plugin的实现基于InnoDB物理文件的备份，机制大致与Xtrabackup相同。物理备份过程中存在一种可能性：即当备份大容量实例过程中，由于业务不断发生变化，重做日志还未备份就被覆盖了，从而导致备份文件无法恢复的情况。

为此MySQL 8.0.17版本恢复了InnoDB重做日志文件归档（ InnoDB redo log archiving） 的功能，解决备份一致性问题。

Clone Plugin 功能基本原理

       克隆最基本的要求就是要保证把克隆源的一个一致性的状态拷贝到另一个数据目录中，那么插件是如何保证拷贝完成时是一个一致性的点呢，这涉及到snapshot的概念，源库的一个snapshot就是一个一致性的状态点，拷贝源库的snapshot到目的数据目录就保证了目的数据目录具有源库的历史一致性状态。

clone snapshot的实现

总的来说可以分为以下3步： 

每一步的分界点都以lsn来区分 基线拷贝所有的文件（clone start lsn -> clone file end lsn) 增量1拷贝 clone start lsn到clone file end lsn之间搜集的脏页 增量2拷贝 clone file end lsn到clone lsn归档的redo

一致性原理： clone开始的时候所有已经flush的数据都通过文件拷贝了，而未flush的将被记录下来了 clone结束的时候:  到最近的checkpoint的脏页都被记录下来了，这些脏页应用到全量文件上就等价于最近的checkpoint，而checkpoint以后的增量通过拷贝归档redo来实现。这个截止点clone lsn（对应的binlog位点)就被完整的拷贝到了目的实例.

snapshot因此被分成了如下几种状态：

也就是说对于克隆操作，innodb会创建一个快照，快照先后会有5个状态，其中FILE COPY对应xtrabackup的ibd拷贝，REDO COPY对应redo拷贝；

克隆功能会用到2个新特性，分别是Page Tracking和Redo Archiving；PAGE COPY是xtrabackup没有的.

总的流程大致如下所示：

FILE COPY:

该状态会拷贝所有的数据库文件，在开始拷贝前，会启动Page Tracking，记录CLONE START LSN这个lsn后被改动的所有InnoDB页的改动。更具体得说，CLONE START LSN的取值就是当前的checkpoint lsn，这是因为这个阶段直接拷贝物理文件，InnoDB只能确保checkpoint lsn之前的所有数据页面已经从Buffer Pool中刷回到磁盘上，在其之后的页面可能还未被回刷到磁盘。Page Tracking会从指定的lsn，即checkpoint lsn开始跟踪每次从Buffer Pool回刷页面到磁盘的操作，并记录对应页面的space id和page id。这样就可以捕获该阶段的所有数据更改。

PAGE COPY:

这个阶段是克隆功能特有的。在完成数据库文件拷贝后开始，在开始前会启动Redo Archiving，同时停止Page Tracking。也就是从记录页面更改到记录redo变化。

Redo Archiving会从指定的lsn位置开始拷贝redo日志。相比xtrabackup的拷贝线程，该功能更加可靠，因为新产生的redo日志在写入redo文件前，会判断是否会覆盖还未被拷贝走的redo日志，如果是的话，会等待Redo Archiving完成拷贝。该阶段会将Page Tracking记录的所有页面拷贝并发送到指定位置，在拷贝前，会基于spaceid和page id进行排序，尽可能确保磁盘读写的顺序性。这个阶段的数据拷贝效率应该会远高于文件拷贝阶段，因为最新修改的页面基本上都还在Buffer Pool，无需从磁盘中读取。

REDO COPY:

该阶段在完成页面拷贝后进行，会加锁获取Binlog文件及当前偏移位置，和/或gtid_executed信息，并停止Redo Archiving。在解锁后，将Binlog相关信息和拷贝的redo日志发送到指定位置。发送完后，克隆功能的快照拷贝步骤也就结束了。 显然，在克隆功能中，解决了xtrabackup拷贝redo时存在被覆盖问题，提高了可用性；同时，通过引入PAGE COPY这个新阶段来减少了所需归档的redo日志量，这样可以有效缩短应用redo日志所需的时间，可大大提升性能。

需要注意的是，克隆功能会删除目标MySQL实例上的所有数据。若实例上的数据还有用处，需确保在使用该功能前做好备份。

实现snapshot必须实现脏页收集和redo归档 脏页收集： 脏页收集可以有两种方式：1. 在mtr 提交脏页时，2. i/o线程刷脏时。目前为了不影响mtr的并发选择了后者。

clone_copy 和 clone_apply，plugin通过调用这两组接口在源和目的之间拷贝文件和内存数据，从而实现拷贝完整的snapshot：

1. copy_data:

2. clone_copy(locator[IN], callback_context[IN], ...)

3. callback_context

4. clone_file_cbk(from_file_descriptor[IN], copy_length[IN], ...) 拷贝文件的回调

5. clone_buffer_cbk(from_data_buffer[IN], copy_length[IN], ...) 拷贝脏页的回调

6. apply_data:

clone_apply(locator[IN], callback_context[IN], ...)

clone_apply_file_cbk(to_file_descriptor[IN], copy_length[IN], ...) 把copy的数据写到目的数据目录

接口示意图：

一些关键点

1. 通过内存的队列去缓存修改的脏页和spaceid，page_id

2. 不重复记录相同的spaceid,pageid

3. 通过后台不停的追加写文件，防止内存撑爆

4. 元信息不单独维护，文件名和头包括必要的信息

5. 文件头中记录了开始和结束的lsn.

6. 如果缓存满了会导致flushpage被阻塞，但是这种情况应该很少，

7. 内存不足时会告警和停止收集脏页，同时会重启clone的流程

Redo归档：

1. 后台归档线程从checkpoint LSN开始归档redo 这个后台线程就是之前的脏页搜集线程

2. 每次都按块从上次copy的lsn到最新的flush lsn把日志从redo file拷贝到archive file

3. 拷贝的速度基本上要比redo生成的速度快，为了防止归档日志被覆盖，mtr在归档日志将要被覆盖时会柱塞mtr

4. 归档日志通过lsn命名

5. 提供如用户接口实现归档

克隆的前提条件和限制

• 捐赠者和接受者都需要安装克隆插件。

• 捐赠者和接受者分别需要有至少BACKUP_ADMIN/CLONE_ADMIN权限的账号，暗示了接受者必须先启动一个数据库实例(空或有数据的实例均可，因为都会被删除)

• 克隆目标目录必须有写入权限

• 克隆操作期间不允许使用 DDL，包括TRUNCATE TABLE，允许并发DML。如果DDL正在运行，则克隆操作将等待锁定；否则，如果克隆操作正在运行，则DDL将等待锁定。

• 要求相同版本号，您无法MySQL 5.7和MySQL 8.0之间进行克隆，而且要求版本>=8.0.17

• 同一平台同一架构，例如linux to windows、x64 to x32 是不支持。

• 足够的磁盘空间

• 可以克隆操作一般表空间，但必须要有目录权限，不支持克隆使用绝对路径创建的一般空间。与源表空间文件具有相同路径的克隆表空间文件将导致冲突

• 远程克隆时不支持CLONE INSTANCE FROM中通过使用mysqlx的端口

• 克隆插件不支持克隆MySQL服务器配置my.cnf等

• 克隆插件不支持克隆二进制日志。

• 克隆插件仅克隆存储的数据 InnoDB。不克隆其他存储引擎数据。MyISAM并且 CSV存储在包括sys模式的任何模式中的表都被克隆为空表。

• 不支持通过MySQL router连接到捐赠者实例。

• 一些参数是必须一致的，例如innodb_page_size、innodb_data_file_path、--lower_case_table_names

• 如果克隆加密或页面压缩数据，则捐赠者和接收者必须具有相同的文件系统块大小

• 如果要克隆加密数据，则需要安全连接

• clone_valid_donor_list 在接受者 的设置必须包含捐赠者MySQL服务器实例的主机地址。

• 必须没有其他克隆操作正在运行。一次只允许一次克隆操作。要确定克隆操作是否正在运行，请查询该 clone_status表。

• 默认情况下，克隆数据后会自动重新启动接受者MySQL实例。要自动重新启动，必须在接收方上提供监视进程以检测服务器是否已关闭。否则，在克隆数据后，克隆操作将停止并出现以下错误，并且关闭接受者MySQL服务器实例：

ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process).

此错误不表示克隆失败。这意味着必须在克隆数据后手动重新启动接受者的MySQL实例。

Clone相关参数

mysql> show global variables like '%clone%';

Clone Plugin克隆方式

本地克隆

本地克隆操作将启动克隆操作的MySQL服务器实例中的数据克隆到同服务器或同节点上的一个目录里.

本地clone无需启动额外mysqld, 只要在实例上执行一条sql语句，指定下目标目录即可:

语法：

CLONE LOCAL DATA DIRECTORY [=] 'clone_dir';

克隆步骤：

• DROP DATA

• FILE COPY

• PAGE COPY

• REDO COPY

• FILE SYNC

远程克隆

远程克隆可以理解为将本地克隆的数据以流的方式发送到远端从而写入远端的目的数据目录完成克隆，具体流程如下图示：

Clone远程和交互示意图：

CLONE PROTOCOL说明:

• 
  

1. COM_INIT: 协商版本号，存储引擎发起clone操作，源端（DONER)的locater会返回给目的端(RECIPIENT)，locater是一个innodb存储引擎内部表示snapshot状态的逻辑指针，协商版本号未来可以支持不同版本间的clone；

2. COM_ATTACH: 新的slave线程和当前clone线程相关联，用于并发处理；

3. COM_REINIT: 用于当出现类似网络错误时重启clone，clone主线程等待所有辅助线程退出后，会把stage/chunk/block信息发送给源端重新clone；

4. COM_EXECUTE: 开始传输数据到客户端，源端流式的将snapshot通过网络发送到目的端，数据通过这个com的回包连续不断的发送；   A. COM_RES_LOCS : 目的端发送给源端的locater信息；   B. COM_RES_DATA_DESC :用于描述接下来数据包的描述符，第一部分是存储引擎在cloneplugin的位置，用于  clone plugin调用正确的存储引擎，第二部分就和具体的存储引擎相关，innodb有如下的内容：      1. State information      2. Task information      3. File metadata      4. Location next data block - file index and offset    C. COM_RES_DATA :clone的原始数据；    D. COM_RES_COMPLETE : 克隆成功完成；    E. COM_RES_ERROR : 克隆报错退出，源端通过多次DESC+DATA直到snapshot发送完毕，然后发送一个 CLONE_COM_END表明结束；

5. COM_ACK：用于目的端通知源端可以安全的切换snapshot状态了，它同时也可以用于目的端反馈给源端错误信息，因为COM_EXECUTE一直是源端发送数据到目的端；

6. COM_EXIT: 退出plugin返回到普通的服务器协议；

默认情况下，远程克隆操作会删除接受者(recipient)数据目录中的数据，并将其替换为捐赠者(donor)的克隆数据。（可选）您也可以将数据克隆到接受者的其他目录，以避免删除现有数据。

远程克隆操作和本地克隆操作克隆的数据没有区别，数据是相同的。

克隆插件支持复制。除克隆数据外，克隆操作还从捐赠者中提取并传输复制位置信息，并将其应用于接受者，从而可以使用克隆插件来配置组复制或主从复制。使用克隆插件进行配置比复制大量事务要快得多，效率更高。

语法:

CLONE INSTANCE FROM USER@HOST:PORT

IDENTIFIED BY 'password'

[DATA DIRECTORY [=] 'clone_dir']

[REQUIRE [NO] SSL];

mysql> SET GLOBAL clone_valid_donor_list = '10.xxx.xxx.xxx:3306';

mysql> CLONE INSTANCE FROM clone_user@10.xxx.xxx.xxx:3306

IDENTIFIED BY 'password';

mysql> CLONE INSTANCE FROM user_name@10.xxx.xxx.xxx:3306

IDENTIFIED BY 'password'

DATA DIRECTORY = '/data/clone_dir';

克隆步骤:

1. 创建空实例[mysqld–initialize]

2. 启动目的实例

3. 连接源实例

4. 从源实例clone数据到目的实例

5.    SQL > INSTALL PLUGIN CLONE

6.    SQL > CLONE REMOTE INSTANCE

7. 用在clone的数据目录上重启

主要流程：

主要流程包含如下几个过程：

[INIT] ---> [FILE COPY] ---> [PAGE COPY] ---> [REDO COPY] -> [Done]

• 
  

1. INIT阶段

需要持有backup lock, 阻止ddl进行

• 
  

1. FILE COPY

按照文件进行拷贝，同时开启page tracking功能，记录在拷贝过程中修改的page, 此时会设置buf_pool->track_page_lsn为当前lsn，track_page_lsn在flush page阶段用到:

buf_flush_page:

if (!fsp_is_system_temporary(bpage->id.space()) &&

buf_pool->track_page_lsn != LSN_MAX) {

page_t *frame;

lsn_t frame_lsn;

frame = bpage->zip.data;

if (!frame) {

frame = ((buf_block_t *)bpage)->frame;

}

frame_lsn = mach_read_from_8(frame + FIL_PAGE_LSN); 对于在track_page_lsn之后的page, 如果frame_Lsn大于track_page_lsn, 表示已经记录下page id了，无需重复记录

arch_page_sys->track_page(bpage, buf_pool->track_page_lsn, frame_lsn,

false); 将page id记录下来，表示在track_page_lsn后修改过的page

}

会创建一个后套线程page_archiver_thread()，将内存记录的page id flush到disk上

• 
  

1. PAGE COPY

这里有两个动作

1. 开启redo archiving功能，从当前点开始存储新增的redo log，这样从当前点开始所有的增量修改都不会丢失，同时上一步在page track的page被发送到目标端。确保当前点之前所做的变更一定发送到目标端

2. 关于redo archiving，实际上这是官方早就存在的功能，主要用于官方的企业级备份工具，但这里clone利用了该特性来维持增量修改产生的redo。 在开始前会做一次checkpoint， 开启一个后台线程log_archiver_thread()来做日志归档。当有新的写入时(notify_about_advanced_write_lsn)也会通知他去archive，当arch_log_sys处于活跃状态时，他会控制日志写入以避免未归档的日志被覆盖(log_writer_wait_on_archiver), 注意如果log_writer等待时间过长的话， archive任务会被中断掉

1. Redo Copy

停止Redo Archiving", 所有归档的日志被发送到目标端，这些日志包含了从page copy阶段开始到现在的所有日志，另外可能还需要记下当前的复制点，例如最后一个事务提交时的binlog位点或者gtid信息，在系统页中可以找到

• 
  

1. Done

目标端重启实例，通过crash recovery将redo log应用上去。

克隆插件部署

安装克隆插件

可以在配置文件中添加如下行My.cnf

[mysqld]

plugin-load-add=mysql_clone.so

或

mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';

检查插件是否安装成功：

设置强制启动失败参数

[mysqld]

plugin-load-add=mysql_clone.so

clone=FORCE_PLUS_PERMANENT

注： 可以设置clone=FORCE_PLUS_PERMANENT或clone=FORCE。作用是：如果插件未成功初始化，就会强制mysqld启动失败。

克隆需要的权限

需要有备份锁的权限。备份锁是MySQL8.0的新特性之一，比5.7版本的flush table with read lock要轻量。

mysql> CREATE USER clone@'%' IDENTIFIED by '123456';

GRANT BACKUP_ADMIN ON *.* TO 'clone';Query OK, 0 rows affected (0.00 sec)

mysql> GRANT BACKUP_ADMIN ON *.* TO 'clone';

Query OK, 0 rows affected (0.00 sec)

本地克隆测试

执行本地克隆

[root@test]# mysql -h127.0.0.1 -uclone -P 3399 -p123456

mysql> CLONE LOCAL DATA DIRECTORY ='/data/myclone';

Query OK, 0 rows affected (13.06 sec)

注：需要MySQL的运行用户拥有/data目录的rwx权限，要求clone_dir(myclone)目录不存在

本地克隆的步骤如下

• DROP DATA

• FILE COPY

• PAGE COPY

• REDO COPY

• FILE SYNC

观察方法如下

mysql> SELECT STAGE, STATE, END_TIME FROM performance_schema.clone_progress;

或者：

mysql> set global log_error_verbosity=3;

mysql> CLONE LOCAL DATA DIRECTORY ='/data/myclone1';

[root@test myclone]# tail -f data/mydata/my3399/error_my3399.log

远程克隆测试

假设前提条件都满足，步骤如下

和本地克隆一样，远程克隆需要插件安装和用户授权。捐赠者、接受者的授权略有不同。

1. 捐赠者和接受者都安装了克隆插件

mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';

1. 捐赠者授权

mysql> CREATE USER clone @'10.%' IDENTIFIED by '123456';

mysql> GRANT BACKUP_ADMIN ON *.* TO 'clone'@'10.%';

1. 接受者授权

mysql> CREATE USER clone1@'10.%' IDENTIFIED by '123456';

mysql> GRANT CLONE_ADMIN ON *.* TO 'clone1'@'10.%';

注意：CLONE_ADMIN权限 = BACKUP_ADMIN权限 + SHUTDOWN权限。 SHUTDOWN权限允许用户shutdown和restart mysqld。授权不同是因为，接受者需要restart mysqld。

1. 接受者设置捐赠者列表清单

mysql> SET GLOBAL clone_valid_donor_list = '10.149.17.101:3399';

安全相关参数。多个实例用逗号分隔，例如“HOST1:PORT1,HOST2:PORT2,HOST3:PORT3”

1. 接受者开始拉取克隆捐赠者数据

[root@sjs_21_219 mydata]# usr/local/mysql/bin/mysql -h127.0.0.1 -uclone1 -p123456 -P3399

mysql> CLONE INSTANCE FROM clone@'10.149.17.101':3399 IDENTIFIED BY '123456';

Query OK, 0 rows affected (27.78 sec)

mysql> Restarting mysqld...

2019-09-16T09:31:43.469318Z mysqld_safe Number of processes running now: 0

2019-09-16T09:31:43.474172Z mysqld_safe mysqld restarted

mysql>

mysql>

mysql> show databases;

ERROR 2013 (HY000): Lost connection to MySQL server during query

Clone完成并重启数据库。

注意：重启后所有用户权限和捐赠者一样了。

接受者如果非mysqld_safe启动的，会报错误，但不影响克隆，需要您人手启动mysqld即可。

ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process).

1. 远程克隆步骤如下

利用克隆备份建立实例

• 
  

1. 克隆备份

[root@mgr1 ~]# mysql -u root -S tmp/mysql3399.sock -P 3399 -p123456

mysql> CLONE LOCAL DATA DIRECTORY ='/data/myclone2';

Query OK, 0 rows affected (13.06 sec)

• 
  

1. 查看备份目录内容

[root@mgr1 myclone2]# ls

#clone ib_buffer_pool ibdata1 ibdata2 ib_logfile0 ib_logfile1 lm mysql mysql.ibd sys undo_001 undo_002

• 
  

1. 利用克隆备份启动实例

为了和源实例端口冲突，启用3398端口

[root@mgr1 myclone2]# chown -R mysql.mysql data/myclone2/

[root@mgr1 myclone2]# cp data/mydata/my3399/my3398.cnf /data/myclone2/my3398.cnf

[root@mgr1 myclone2]# vi my3398.cnf

• 
  

1. 启动实例

[root@mgr1 myclone2]# /usr/local/mysql/bin/mysqld_safe --defaults-file=/data/myclone2/my3398.cnf --user=mysql &

• 
  

1. 验证

[root@mgr1 myclone2]# mysql -u root -S /tmp/mysql3398.sock -P 3398 -p123456

利用克隆建立主从复制

二进制日志位置（文件名，偏移量）和 GTID 坐标都从供体（Master） MySQL 服务器实例中提取和传输。可以在克隆的 MySQL 服务器实例上执行以下查询，以查看二进制日志位置或应用的最后一个事务的 GTID：

mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;

+------------------+-----------------+

| BINLOG_FILE | BINLOG_POSITION |

+------------------+-----------------+

| mysql-bin.000003 | 164294 |

+------------------+-----------------+

1 row in set (0.01 sec)

GTID复制时，通过以下命令查看GTID位置

mysql> SELECT @@GLOBAL.GTID_EXECUTED;

+--------------------------------------------+

| @@GLOBAL.GTID_EXECUTED |

+--------------------------------------------+

| 8afdc298-d84f-11e9-be4e-6c0b8482fd32:1-203 |

+--------------------------------------------+

1 row in set (0.00 sec)

捐赠者授权：

create user repl@'%' identified WITH 'mysql_native_password' by 'repl';

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'%';

接受者建立GTID主从复制关系

CHANGE MASTER TO

MASTER_HOST='10.149.17.101',

MASTER_USER='repl',

MASTER_PASSWORD='repl',

MASTER_PORT=3399,

MASTER_AUTO_POSITION=1;

主从关系既通过克隆复制完成。

利用克隆搭建MGR节点

上述5个worklog构成了完整的克隆功能。但这还不够，为了能够方便得在MGR中使用，Pedro Gomes还开了个worklog：Clone plugin integration on distributed recovery (WL#12827)，用于将克隆功能集成到MGR的分布式故障恢复模块中。

在MGR中有2个场景会用到克隆功能：一是往MGR集群中新增一个节点时；二是故障恢复的节点与其他节点的复制延迟超过所设阈值group_replication_clone_threshold时。

需要指出的是，相比非MGR场景，在MGR中使用克隆功能更加方便，用户唯一需要设置的就是group_replication_clone_threshold参数，克隆功能的原生参数clone_valid_donor_list和命令CLONE INSTANCE FROM等MGR均会自动完成设置和操作。

流程：

1. 加入小组

2. 从小组成员收集GTID信息

3. 如果数据中的间隙太大，或者不存在所需GTID的binlog，请执行克隆过程。如果没有移动到6。

3.1、GR插件从在线有效成员中选择捐赠者

3.2、GR插件执行命令以将施主添加到克隆插件有效供体列表中。

3.3、GR插件使用恢复凭据执行克隆命令（SQL）。

3.4、克隆插件克隆来自捐赠者的数据并重新启动服务器

1. 如果配置为启动，插件将在启动时启动。

2. 回到1。

3. 执行分布式恢复过程。

4. 当新成员赶上该组时，转到状态ONLINE

步骤：

1. 任意组节点先停止组复制

Mysql> STop GROUP_REPLICATION

1. 节点捐赠者安装了克隆插件

mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';

mysql> Start GROUP_REPLICATION;

1. 捐赠者授权

GRANT REPLICATION SLAVE ON *.* TO "repl";

GRANT BACKUP_ADMIN ON *.* TO "repl";

1. 接受者设置捐赠者列表清单

mysql> SET GLOBAL clone_valid_donor_list = '10.152.69.141:3399';

1. 接受者开始拉取克隆捐赠者数据

[root@mgr1 ~]# /usr/local/mysql8/bin/mysql -S /tmp/mysql3399.sock

mysql> CLONE INSTANCE FROM repl@'10.152.69.141':3399 IDENTIFIED BY '123456';

Query OK, 0 rows affected (27.78 sec)

mysql> Restarting mysqld...

mysql>

mysql>

1. 加入组

mysql> Start GROUP_REPLICATION;

1. 检查是否加入成功，由恢复转到状态ONLINE

监控克隆操作

1. 检查克隆进度

mysql> SELECT STATE FROM performance_schema.clone_status;

+-----------+

| STATE |

+-----------+

| Completed |

+-----------+

1 row in set (0.01 sec)

1. 检查克隆是否出错

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

+-----------+----------+---------------+

| STATE | ERROR_NO | ERROR_MESSAGE |

+-----------+----------+---------------+

| Completed | 0 | |

+-----------+----------+---------------+

1 row in set (0.01 sec)

1. 检查克隆步骤

mysql> SELECT STAGE, STATE, END_TIME FROM performance_schema.clone_progress;

+-----------+-------------+----------------------------+

| STAGE | STATE | END_TIME |

+-----------+-------------+----------------------------+

| DROP DATA | Completed | 2019-09-16 15:53:13.186036 |

| FILE COPY | Completed | 2019-09-16 15:53:21.497639 |

| PAGE COPY | Completed | 2019-09-16 15:53:21.700253 |

| REDO COPY | Completed | 2019-09-16 15:53:21.902100 |

| FILE SYNC | Completed | 2019-09-16 15:53:26.283666 |

| RESTART | Not Started | NULL |

| RECOVERY | Not Started | NULL |

+-----------+-------------+----------------------------+

7 rows in set (0.00 sec)

1. 检查克隆次数

mysql> show global status like 'Com_clone';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| Com_clone | 2 |

+---------------+-------+

1 row in set (0.01 sec)

# `捐赠者` 每次+1，`接受者` 0

1. 查看克隆线程ID

Mysql> show processlist

mysql> SELECT * FROM performance_schema.clone_status\G

*************************** 1. row ***************************

ID: 1

PID: 15

STATE: Completed

BEGIN_TIME: 2019-09-16 15:53:13.184

END_TIME: 2019-09-16 15:53:26.284

SOURCE: LOCAL INSTANCE

DESTINATION: /data/myclone1/

ERROR_NO: 0

ERROR_MESSAGE:

BINLOG_FILE:

BINLOG_POSITION: 0

GTID_EXECUTED:

1 row in set (0.00 sec)

克隆与xtrabackup的对比

• 克隆和xtrabackup备份都属于物理热备，备份恢复原理也近似。

• 克隆在恢复实例时需要先启动一个实例并授权，而xtrabackup不需要。

• xtrabackup在backup后需要apply log，克隆是类似mysqlbackup提供的backup-and-apply-log，合并在一起做。

• xtrabackup备份文件的权限等于执行命令的人的权限，恢复实例时需要人手chown回实例权限，克隆备份后权限和原数据权限一致，无需再人手chown，方便恢复。

• xtrabackup恢复时需要在mysql中执行reset master;然后set global gtid_purged="UUID:NUMBER",具体的UUID:NUMBER的值为备份文件中的xtrabackup_info文件的内容；克隆不需要这个操作步骤，默认克隆完就可以建立复制了。

• xtrabackup有备份my.cnf，而克隆没有。

• xtrabackup备份完一般是scp拷贝到另外一台机器恢复，走的是22端口；克隆走的是MySQL的监听端口。所以在目录权限正确的情况下，甚至根本不需要登录Linux服务器的权限。如下:

[root@192-168-199-103 ~]# mysql -uroot -ppassword2 -h192.168.199.102 -P3008 -e "SET GLOBAL clone_valid_donor_list = '192.168.199.101:3008';"

mysql: [Warning] Using a password on the command line interface can be insecure.

[root@192-168-199-103 ~]# mysql -uroot -ppassword2 -h192.168.199.102 -P3008 -e "CLONE INSTANCE FROM root@'192.168.199.101':3008 IDENTIFIED BY 'password1';"

mysql: [Warning] Using a password on the command line interface can be insecure.

参考文献

1. https://dev.mysql.com/doc/refman/8.0/en/clone-plugin.html

2. https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-remote.html

3. https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-replication.html

4. https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-monitoring.html 

5. https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-limitations.html