1 业务背景

在实际业务中，经常碰到需要重新搭建mysql从库的场景。除了常用的MySQL主从复制搭建（xtrabackup、mydumper备份恢复方案）外，本文介绍另外一种Clone Plugin方案，重建从库操作更简单，速度更快。

2 版本

mysql数据库版本须在8.0.17及之后，因Clone Plugin是8.0.17引入的一个新功能。

以下测试环境为CentOS7.9+MySQL8.0.26。

• 操作系统版本

#cat /etc/redhat-release

• 数据库版本

3 插件安装

有两种安装方式，所有库执行

• 一为动态加载的方式

root@localhost 17:37:  [(none)]> install plugin clone soname'mysql_clone.so';

• 二为修改数据库配置文件my.cnf，此方法需要重启数据库:

vim my.cnf
...
[mysqld]
#Clone Plugin
plugin-load-add=mysql_clone.so
clone=FORCE_PLUS_PERMANENT
...

重启mysql

$service mysql restart

status状态为ACTIVE表示插件安装成功

• 涉及参数优化说明

clone_autotune_concurrency:默认为ON，用于在远程克隆操作时，额外生成动态线程，以优化传输速度。仅适用于接收实例。
clone_max_concurrency:定义远程克隆操作时，动态生成的线程的最大限制。和上面的参数有关。
clone_buffer_size:仅适用于本地克隆操作，定义在数据传输期间使用的缓冲期大小。默认为4M，较大的缓冲区可能会提高性能。
clone_ddl_timeout:定义在克隆操作时，等待备份锁定的超时时间，单位为秒，适用于接收和远程MySQL实例。需要注意的是，克隆操作不能与DDL操作同时进行。且克隆操作会上一个备份锁。设置为0时，如果有同时的DDL操作，那么克隆将会立即失败。
clone_enable_compression:仅适用于接收实例。该参数定义在远程克隆期间是否开启网络层的数据压缩，以节省带宽，提高传输速率。
clone_max_data_bandwidth:定义远程克隆操作的单个线程最大传输速率，以每秒(MB)为单位。如果有4个线程，那么总的传输速率就是每秒4MB。设置为0表示无限制。
clone_max_network_bandwidth:定义远程克隆操作的最大网络传输速率，同样以每秒(MB)为单位。该参数仅适用于接收实例。
clone_valid_donor_list:在远程克隆操作时，定义的远程实例地址，仅在接收实例上设置。

4 主从搭建

• 主库操作

创建用户并赋权，backup_admin是克隆操作必须权限，REPLICATION SLAVE是复制所必须的权限。如果已有复制权限用户，则仅需对该用户赋backup_admin权限即可。

root@localhost 17:47:  [(none)]> create user 'repl'@'%' identified by '密码';
Query OK, 0 rows affected (0.00 sec)
root@localhost 17:48:  [(none)]> grant backup_admin on *.* to 'repl'@'%';
Query OK, 0 rows affected (0.00 sec)

• 从库操作

  创建用户并赋clone_admin权限，隐式含有backup_admin（阻塞DDL）和shutdown（重启实例）权限。如果已有复制权限用户，则仅需对该用户赋clone_admin权限即可。

root@localhost 17:51:  [(none)]> create user 'repl'@'%' identified by '密码';
Query OK, 0 rows affected (0.01 sec)
root@localhost 17:51:  [(none)]> grant clone_admin on *.* to 'repl'@'%';
Query OK, 0 rows affected (0.00 sec)

从库发起克隆命令，设置主库ip为白名单

root@localhost 17:57:  [(none)]> set global clone_valid_donor_list = '172.21.55.101:3306';
Query OK, 0 rows affected (0.00 sec)
root@localhost 18:16:  [(none)]> clone instance from 'repl'@'172.21.55.101':3306 identified by '密码';
Query OK, 0 rows affected (17.92 sec)

查看clone进度及状态

root@localhost 18:17:  [(none)]> SELECT STAGE, STATE, CAST(BEGIN_TIME AS TIME) as "START TIME",   CASE WHEN END_TIME IS NULL THEN   LPAD(sys.format_time(POWER(10,12) * (UNIX_TIMESTAMP(now()) - UNIX_TIMESTAMP(BEGIN_TIME))), 10, ' ')   ELSE   LPAD(sys.format_time(POWER(10,12) * (UNIX_TIMESTAMP(END_TIME) - UNIX_TIMESTAMP(BEGIN_TIME))), 10, ' ')   END as DURATION,   LPAD(CONCAT(FORMAT(ROUND(ESTIMATE/1024/1024,0), 0), " MB"), 16, ' ') as "Estimate",   CASE WHEN BEGIN_TIME IS NULL THEN LPAD('0%', 7, ' ')   WHEN ESTIMATE > 0 THEN   LPAD(CONCAT(CAST(ROUND(DATA*100/ESTIMATE, 0) AS BINARY), "%"), 7, ' ')   WHEN END_TIME IS NULL THEN LPAD('0%', 7, ' ')   ELSE LPAD('100%', 7, ' ') END as "Done(%)" FROM performance_schema.clone_progress;

root@localhost 18:17:  [(none)]> select * from performance_schema.clone_status\G

root@localhost 18:17:  [(none)]>  select * from performance_schema.clone_progress;

• 建立主从关系，从库操作

root@localhost 18:33:  [(none)]>change master to master_host='172.21.55.101',master_port=3306,master_user='repl',master_password='密码',master_auto_position=1;

从库启动复制线程

root@localhost 18:34:  [(none)]> start slave;

5 实现原理

克隆最基本的要求就是要保证把克隆源的一个一致性的状态拷贝到另一个数据目录中，那么Clone Plugin是如何保证拷贝完成时是一个一致性的点呢。

这涉及到snapshot（快照）的概念，源库的一个snapshot就是一个一致性的状态点，拷贝源库的snapshot到目的数据目录就保证了目的数据目录具有同源库的历史一致性的状态。

clone snapshot流程大体分为3步，如下图所示

细分有如下5个阶段：

具体clone过程可通过数据字典视图performance_schema.clone_progress查看。

6 价值及建议

Clone plugin带来的价值

对于InnoDB缓冲池脏页比较多的场景，相比Xtrabackup，拥有极快的恢复速度；

无GLOBAL锁与COMMIT锁，无死锁风险；

无Flush tables操作，不会清理表缓存，几乎不会实时影响业务；

无Redo日志被覆盖问题；

两条命令完成全链路操作，无手工失误风险（删除库表、对齐GTID与Binlog坐标）；

官方原生支持，不存在兼容性问题；

使用备份锁，未来可支持并发truncate，支持并发的克隆。

使用建议

不要在有非InnoDB表的实例上使用，或者确保非InnoDB表只读并且数据已经落盘；

数据库版本、字符集、排序规则保持一致，尤其不可跨版本；

使用之前评估binlog_order_commits影响，仅限于同步Binlog坐标期间；

使用之前评估Binlog坐标持久化影响，仅限于同步Binlog坐标期间；

确认当前实例无分布式事务，即XA语句，仅限于同步Binlog坐标期间；

建议page cleaner线程数配置为缓冲池实例个数，关注用户线程主动刷脏风险。