MySQL 8 新特性之Clone Plugin

概述Clone Plugin是MySQL 8.0.17引入的一个重大特性，为什么要实现这个特性呢？个人感觉，主要还是为Group Replication服务。在Group Replication中，添加一

Clone Plugin是MysqL 8.0.17引入的一个重大特性，为什么要实现这个特性呢？个人感觉，主要还是为Group Replication服务。在Group Replication中，添加一个新的节点，差异数据的补齐是通过分布式恢复（distributed Recovery）来实现的。

 

在MysqL 8.0.17之前，只支持一种恢复方式-binlog。但如果新节点需要的binlog已经被Purge了，这个时候，只能先借助于备份工具（XtraBackup，mydumper，MysqLdump）做个全量数据的同步，然后再通过分布式恢复同步增量数据。

 

这种方式，虽然也能实现添加节点的目的，但总归还是要借助于外部工具，需要一定的工作量和使用门槛。要知道，其竞争对手，PXC，默认集成了XtraBackup进行State Snapshot Transfer（类似于全量同步），而MongoDB则更进一步，原生就实现了Initial Sync同步全量数据。从易用性来看，单就集群添加节点这一项而言，MysqL确实不如其竞争对手。客户体验上，还有很大的提升空间。

 

好在MysqL官方也正视到这个差距，终于在MysqL 8.0.17实现了Clone Plugin。当然，对于官方来说，实现这个特性并不算难，毕竟有现成的物理备份工具（MysqL Enterprise Backup）可供借鉴。

 

本文将从以下几个方面展开：

Clone Plugin的安装

Clone Plugin的使用

如何查看克隆 *** 作的进度

如何基于克隆数据搭建从库

Clone Plugin的实现细节

Clone Plugin的限制

Clone Plugin与XtraBackup的对比

Clone Plugin的参数解析

 

一、Clone Plugin的安装

Clone Plugin支持以下两种安装方式：

（1）配置文件指定

[MysqLd]plugin-load-add=MysqL_clone.soclone=FORCE_PLUS_PERMANENT

这里的clone，严格来说，不是参数名，而是插件名，可加可不加，FORCE_PLUS_PERMANENT 控制插件的行为。

有四个取值：

ON（开启插件）

OFF（禁用插件），

FORCE（强制开启。如果插件初始化失败，MysqL将不会启动）

FORCE_PLUS_PERMANENT（在FORCE的基础上，不允许通过UNINSTALL PLUGIN命令卸载插件）。

（2）动态加载

MysqL_clone.soclone=FORCE_PLUS_PERMANENT

查看插件是否安装成功

MysqL> show plugins;...| clone                           | ACTIVE   | CLONE              | MysqL_clone.so | GPL     |...

clone状态显示为”ACTIVE“代表插件加载成功。

 

二、Clone Plugin的使用

Clone Plugin支持两种克隆方式：本地克隆和远程克隆。

 1、 本地克隆

 

本地克隆是在实例本地发起的，其语法如下：

CLONE LOCAL DATA DIRECTORY [=] 'clone_dir';

其中，clone_dir是克隆目录。

 

下面看个具体的Demo。

创建克隆用户

MysqL> create user clone_user'@%' IDentifIEd by clone_pass';MysqL> grant backup_admin on *.* to ';

 

创建克隆目录

# mkdir /data/MysqL# chown -R MysqL.MysqL /data/MysqL

 

创建本地克隆

# MysqL -uclone_user -pclone_passMysqL> clone local data directory=/data/MysqL/3307';

其中，“/data/MysqL/3307” 是克隆目录，其需满足以下几点要求：

克隆目录必须是绝对路径。

“/data/MysqL”必须存在，且MysqL对其有可写权限。

3307不能存在。

 

查看克隆目录的内容

# ll /data/MysqL/3307total 172996drwxr-x--- 2 MysqL MysqL       89 May 24 22:37 #clone-rw-r----- 1 MysqL MysqL     3646 May  ib_buffer_pool-rw-r----- 1 MysqL MysqL 12582912 May  ibdata1-rw-r----- 50331648 May  ib_logfile0-rw-r-----  ib_logfile1drwxr-x--- 2 MysqL MysqL        6 May  MysqL-rw-r----- 25165824 May  MysqL.ibddrwxr-x--- 20 May  slowtechdrwxr-x--- 28 May  sys-rw-r----- 10485760 May  undo_001-rw-r----- 11534336 May 37 undo_002

 

相对于Xtrabackup，无需Prepare，直接即可启动使用。

# /usr/local/MysqL/bin/MysqLd --no-defaults --datadir=/data/MysqL/3307 --user MysqL --port 3307 &

 

2、远程克隆

 

远程克隆涉及两个实例，其中，待克隆的实例是Donor，接受克隆数据的实例是RecipIEnt。克隆命令需在RecipIEnt上发起，语法如下：

CLONE INSTANCE FROM userhost:portIDENTIFIED BY password[DATA DIRECTORY [=] ][REQUIRE [NO] SSL];

其中，

host，port 是待克隆实例的（Donor）的IP和端口，user，password是Donor上的克隆用户和密码，需要backup_admin权限，如上面创建的clone_user。

DATA DIRECTORY指定备份目录，不指定的话，则默认克隆到RecipIEnt的数据目录下。

REQUIRE [NO] SSL，是否开启SSL通信。

 

下面，看个具体Demo。

首先，在Donor实例上创建克隆用户，加载Clone Plugin。

MysqL> create user donor_userdonor_pass;MysqL> install plugin clone soname MysqL_clone.so';

backup_admin是克隆 *** 作必需权限。

 

接着，在RecipIEnt实例上创建克隆用户，加载Clone Plugin。

MysqL> create user 'recipIEnt_user'@%' IDentifIEd by recipIEnt_pass;MysqLgrant clone_admin on *.* to > install plugin clone soname MysqL_clone.so';

这里的clone_admin，隐式含有backup_admin（阻塞DDL）和shutdown（重启实例）权限。

 

设置Donor白名单。RecipIEnt只能克隆白名单中的实例。

MysqLset global clone_valID_donor_List = 192.168.244.10:3306';

设置该参数需要SYstem_VARIABLES_admin权限。

 

在RecipIEnt上发起克隆命令

# MysqL -urecipIEnt_user -precipIEnt_passMysqL> clone instance from donor_user192.168.244.10':3306 IDentifIEd donor_pass;query OK,0 rows affected (36.97 sec)

远程克隆会依次进行以下 *** 作：

（1）获取备份锁。备份锁和DDL互斥。注意，不仅仅是RecipIEnt，Donor上的备份锁同样会获取。

（2）DROP用户表空间。注意，DROP的只是用户数据，不是数据目录，也不包括MysqL，ibdata等系统表空间。

（3）从Donor实例拷贝数据。对于用户表空间，会直接拷贝，如果是系统表空间 ，则会重命名为xxx.#clone，不会直接替代原文件。

# ll /data/MysqL/3306/...-rw-r----- 1 MysqL MysqL     3646 May 25 07:20 ib_buffer_pool--- 1 MysqL MysqL     3646 May 27 07:31 ib_buffer_pool.#clone--- 1 MysqL MysqL 12582912 May 27 07:31 ibdata1--- 1 MysqL MysqL 12582912 May 27 07:31 ibdata1.#clone--- 1 MysqL MysqL 50331648 May 27 07:32 ib_logfile0--- 1 MysqL MysqL 50331648 May 27 07:31 ib_logfile0.#clone...--- 1 MysqL MysqL 25165824 May 27 07:31 MysqL.ibd--- 1 MysqL MysqL 25165824 May 27 07:31 MysqL.ibd.#clone...

（4）重启实例。在启动的过程中，会用xxx.#clone替换掉原来的系统表空间文件。

 

三、如何查看克隆 *** 作的进度

查看克隆 *** 作的进度主要依托于performance_schema.clone_status和performance_schema.clone_progress这两张表。

首先看看performance_schema.clone_status表。

MysqLselect from performance_schema.clone_status\G*************************** 1. row ***************************             ID: 1            PID: 0          STATE: Completed     BEGIN_TIME: 2020-0527 07:31:24.220       END_TIME: 33:08.185         SOURCE: 192.168.244.10:3306    DESTINATION: LOCAL INSTANCE       ERROR_NO:   ERROR_MESSAGE:    binlog_file: MysqL-bin.000009binlog_position: 665197555  GTID_EXECUTED: 59cd4f8f-8fa1-11ea-a0fe-000c29f66609:15601 row in set (0.06 sec)

顾名思义，该表记录了克隆 *** 作的当前状态。

其中，

PID：ProcessList ID。对应show processList中的ID，如果要终止当前的克隆 *** 作，执行kill processList_ID命令即可。

STATE：克隆 *** 作的状态，Not Started（克隆尚未开始），In Progress（克隆中），Completed（克隆成功），Failed（克隆失败）。如果是Failed状态，ERROR_NO，ERROR_MESSAGE会给出具体的错误编码和错误信息。

BEGIN_TIME，END_TIME：克隆 *** 作开始，结束时间。

SOURCE：Donor实例的地址。

DESTINATION：克隆目录。“LOCAL INSTANCE”代表当前实例的数据目录。

GTID_EXECUTED，binlog_file（binlog_position）：克隆 *** 作结束时，主库已经执行的GTID集合，及一致性位置点。可利用这些信息来搭建从库。

 

接下来看看performance_schema.clone_progress表。

MysqL performance_schema.clone_progress;+----+-----------+-----------+----------------------------+----------------------------+---------+-----------+-----------+-----------+------------+---------------+| ID   | STAGE     | STATE     | BEGIN_TIME                 | END_TIME                   | THREADS | ESTIMATE  | DATA      | NETWORK   | DATA_SPEED | NETWORK_SPEED ||    1 | DROP DATA | Completed | 28.581661 35.855706 |       |         0 |          |             file copY 35.855952 58.270881 2 482463294 482497011 | PAGE copY 58.271250 58.719085 |  10977280 11014997 | REDO copY 58.720128 58.930804 465408 465903 file SYNC 58.931094 32:01.063325 | RESTART   59.844119 | RECOVERY  08.185367 7 rows 0.00 sec)

该表记录了克隆 *** 作的进度信息。

其中，

STAGE：一个克隆 *** 作可依次细分为DROP DATA，file copY，PAGE copY，REDO copY，file SYNC，RESTART，RECOVERY等7个阶段。当前阶段结束了才会开始下一个阶段。

STATE：当前阶段的状态。有三种状态：Not Started，In Progress，Completed。

BEGIN_TIME，END_TIME：当前阶段的开始时间和结束时间。

THREADS：当前阶段使用的并发线程数。

ESTIMATE：预估的数据量。

DATA：已经拷贝的数据量。

NETWORK：通过网络传输的数据量。如果是本地克隆，该列的值为0。

DATA_SPEED，NETWORK_SPEED：当前数据拷贝的速率和网络传输的速率。注意，是当前值。

 

四、如何基于克隆数据搭建从库

在前面，我们介绍过

performance_schema.clone_status表，该表会记录Donor实例的一致性位置点信息。我们可以利用这些信息来搭建从库。

MysqL...    binlog_file: MysqL0.06 sec)

 

这里，区分两种场景，GTID复制和基于位置点的复制。

1、GTID复制

MysqL> CHANGE MASTER TO MASTER_HOST master_host_name',MASTER_PORT = master_port_num,...       MASTER_auto_position = > START SLAVE;

需要注意的是，无需额外执行set global gtID_purged *** 作。通过克隆数据启动的实例，gtID_purged已经初始化完毕。

MysqL> show global variables like gtID_purged;-------------+--------------------------------------------+| Variable_name | Value                                      | gtID_purged   | 59cd4f8f560 0.00 sec)

 

2、基于位置点的复制

这里，同样要区分两种场景。

场景1，RecipIEnt要作为Donor的从库。

MysqLSELECT binlog_file,binlog_position FROM performance_schema.clone_status; MysqLmaster_log_name,MASTER_LOG_POS  master_log_pos;MysqL> START SLAVE;

其中，

master_host_name，master_port_num：Donor实例的IP和端口。

master_log_name，master_log_pos：performance_schema.clone_status 中的binlog_file,binlog_position。

 

场景2，Donor本身就是一个从库，RecipIEnt要作为Donor主库的从库。

MysqLSELECT MASTER_LOG_name,MASTER_LOG_POS  MysqL.slave_relay_log_info;MysqL> START SLAVE;

其中，

master_host_name，master_port_num：Donor主库的IP和端口。

master_log_name，master_log_pos：MysqL.slave_relay_log_info中的Master_log_name，Master_log_pos（分别对应 SHOW SLAVE STATUS 中的 Relay_Master_Log_file，Exec_Master_Log_Pos）。

在搭建从库时，建议设置--skip-slave-start。该参数默认为OFF，实例启动后，会自动执行START SLAVE *** 作。

 

如果Donor是个从库，RecipIEnt会基于MysqL.slave_master_info，

MysqL.slave_relay_log_info中的信息自动建立复制，很多时候，这未必是我们的预期行为。

 

五、Clone Plugin的实现细节

克隆 *** 作可细分为以下5个阶段。

[INIT] -> [file copY] ---> [PAGE copY] ---> [REDO copY] -> [Done]

1、INIT：初始化一个克隆对象。

2、file copY

拷贝所有数据文件。在拷贝之前，会记录一个LSN，作为“CLONE START LSN”，这个LSN其实是当前CHECKPOINT的LSN，同时启动“Page Tracking”特性。

“Page Tracking”会跟踪“CLONE START LSN”之后被修改的页，具体来说，会记录该页的tablespace ID和page ID。数据文件拷贝结束后，会将当前CHECKPOINT的LSN记为“CLONE file END LSN”。

3、PAGE copY

拷贝“CLONE START LSN”和“CLONE file END LSN”之间的页，在拷贝之前，会对这些页进行排序-基于tablespace ID和page ID，尽量避免拷贝过程中出现随机读写。同时，开启“Redo Archiving”特性。

“Redo Archiving”会在后台开启一个归档线程将Redo文件中的内容按Chunk拷贝到归档文件中。通常来说，归档线程的拷贝速度会快于Redo日志的生成速度。即使慢于，在写入新的Redo日志时，也会等待归档线程完成拷贝，不会出现还未拷贝的Redo日志被覆盖的情况。当所有修改的页拷贝完毕后，会获取实例的一致性位置点信息，此时的LSN记为“CLONE LSN”。

4、REDO copY

拷贝归档文件中“CLONE file END LSN”与“CLONE LSN”之间的Redo日志。

5、Done

调用snapshot_end()销毁克隆对象。

 

六、Clone Plugin的限制

1、克隆期间，不允许执行DDL命令。同样，DDL会阻塞克隆命令的执行

2、Clone Plugin不会拷贝Donor的配置参数。

3、Clone Plugin不会拷贝Donor的二进制日志文件。

4、Clone Plugin只会拷贝InnoDB表的数据，对于其它存储引擎的表，只会拷贝表结构。

5、Donor实例中如果有表通过DATA DIRECTORY指定了绝对路径，在进行本地克隆时，会提示文件已存在。在进行远程克隆时，绝对路径必须存在且有可写权限。

6、不允许通过MysqL Router连接Donor实例。

7、执行CLONE INSTANCE *** 作时，指定的Donor端口不能为X Protocol端口。

 除此之外，在进行远程克隆时，还会进行如下检查：

MysqL版本（包括小版本）必须一致，且支持Clone Plugin。

ERROR 3864 (HY000): Clone Donor MysqL version: 8.0.20 is different from RecipIEnt MysqL version 19.

主机的 *** 作系统和位数（32位，64位）必须一致。两者可根据version_compile_os，version_compile_machine参数获取。

RecipIEnt必须有足够的磁盘空间存储克隆数据。

字符集（character_set_server），校验集（collation_server），character_set_filesystem必须一致。

innodb_page_size必须一致。会检查innodb_data_file_path中ibdata的数量和大小。

目前Clone Plugin（8.0.20）的实现，无论是Donor，还是RecipIEnt，同一时间，只能执行一个克隆 *** 作。后续会支持多个克隆 *** 作并发执行。

ERROR 3634 (HY000): Too many concurrent clone operations. Maximum allowed - 1.

RecipIEnt需要重启，所以其必须通过MysqLd_safe或systemd等进行管理。如果是通过MysqLd进行启动，实例关闭后，需要手动启动。

ERROR 3707 (HY000): Restart server Failed (MysqLd is not managed by supervisor process).

ACTIVE状态的Plugin必须一致。

 

七、Clone Plugin与XtraBackup的对比

1、在实现上，两者都有file copY和REDO copY阶段，但Clone Plugin比XtraBackup多了一个PAGE copY，由此带来的好处是，Clone Plugin的恢复速度比XtraBackup更快。

2、XtraBackup没有Redo Archiving特性，有可能出现未拷贝的Redo日志被覆盖的情况。

3、GTID下建立复制，无需额外执行set global gtID_purged *** 作。

 

八、Clone Plugin的参数解析

clone_autotune_concurrency

是否自动调节克隆过程中并发线程数的数量，默认为ON，此时，最大线程数受clone_max_concurrency参数控制。若设置为OFF，则并发线程数的数量将是固定的，同clone_max_concurrency参数一致。该参数的默认值为16。

 

clone_buffer_size

本地克隆时，中转缓冲区的大小，默认4M。缓冲区越大，备份速度越快，相应的，对磁盘IO的压力越大。

 

clone_ddl_timeout

克隆 *** 作需要获取备份锁（Backup Lock）。如果在执行CLONE命令时，有DDL在执行，则CLONE命令会被阻塞，等待获取备份锁（Waiting for backup lock）。等待的最大时长由clone_ddl_timeout参数决定，默认300（单位秒）。如果在这个时间内还没获取到锁，CLONE命令会失败，且提示“ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction”。

需要注意的是，如果在执行DDL时，有CLONE命令在执行，DDL同样会因获取不到备份锁被阻塞，只不过，DDL *** 作的等待时长由lock_wait_timeout参数决定，该参数的默认值为31536000s，即365天。

 

clone_enable_compression

远程克隆，在传输数据时，是否开启压缩。开启压缩能节省网络带宽，但相应的，会增加cpu消耗。

 

clone_max_data_banDWIDth

远程克隆时，可允许的最大数据拷贝速率（单位MiB/s）。默认为0，不限制。注意，这里限制的只是单个线程的拷贝速率，如果存在多个线程并行拷贝，实际最大拷贝速率=clone_max_data_banDWIDth*线程数。

 

clone_max_network_banDWIDth

远程克隆时，可允许的最大网络传输速率（单位MiB/s）。默认为0，不限制。如果网络带宽存在瓶颈，可通过该参数进行限速。

 

clone_valID_donor_List

设置Donor白名单，只能克隆白名单中指定的实例。

 

clone_ssl_ca，clone_ssl_cert，clone_ssl_key

SSL相关。

 

九、参考资料

1. InnoDB: Clone local replica：https://dev.mysql.com/worklog/task/?id=9209

2. InnoDB: Clone remote replica：https://dev.mysql.com/worklog/task/?id=9210=

3. InnoDB: Clone Replication Coordinates：https://dev.mysql.com/worklog/task/?id=9211

4. InnoDB: Clone Remote provisioning：https://dev.mysql.com/worklog/task/?id=11636

5. MysqL/InnoDB数据克隆插件(clone plugin)实现剖析：https://zhuanlan.zhihu.com/p/79328512

总结

以上是内存溢出为你收集整理的MySQL 8 新特性之Clone Plugin全部内容，希望文章能够帮你解决MySQL 8 新特性之Clone Plugin所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。