MySQL 8.0 克隆(clone)插件快速搭建主从复制

MySQL 8.0 clone插件提供从一个实例克隆数据的功能，克隆功能提供了更有效的方式来快速创建MySQL实例，搭建主从复制和组复制。本文介绍使用 MySQL 8.0 clone 插件快速搭建主从复制的方法

环境：

• mysql 8.0.29

• 主库：192.168.56.201

• 从库：192.168.56.202

本文将通过实例操作，实现从库由主库克隆，克隆完成后，搭建主从复制。

1、安装clone插件

主、从节点都需要安装。

# 安装克隆插件

INSTALL PLUGIN clone SONAME 'mysql_clone.so';

# 检查插件是否安装成功

mysql> SELECT PLUGIN_NAME,PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME='clone';+-------------+---------------+| PLUGIN_NAME | PLUGIN_STATUS |+-------------+---------------+| clone       | ACTIVE        |+-------------+---------------+

2、创建用户并授权

创建复制账号，只需要在主库创建，在克隆完成后，搭建主从复制使用。

# 在主库上创建复制账号

create user repl@'%' identified by '123456';grant  replication slave on *.* to 'repl'@'%';

克隆源，也就是主库，需要有【BACKUP_ADMIN】权限，克隆受体，也就是从库，需要【CLONE_ADMIN】权限，为了方便，我们在两个机器上把这两个权限都加上。

# 主、从库都需要创建克隆用户并授权

create user 'clone_user'@'%' identified by '123456';grant BACKUP_ADMIN on *.* to 'clone_user'@'%';grant CLONE_ADMIN on *.* to 'clone_user'@'%';

3、执行克隆任务：

在从库上执行克隆命令，如下：

注：需要使用克隆用户登录数据库

mysql -uclone_user -p

# 设置克隆源，将clone_valid_donor_list设置为主库

SET GLOBAL clone_valid_donor_list = '192.168.56.201:3306';

# 开始克隆

CLONE INSTANCE FROM 'clone_user'@'192.168.56.201':3306 IDENTIFIED BY '123456';

在执行克隆时，会先将从库本地的数据目录清空，请确保本地数据目录没有重要数据，可以清空，否则将导致本地数据丢失。

克隆完成后，从库MySQL实例自动重启。

4、启动复制

从库重启完成后，查看Binlog文件、位置和已经执行的GTID。​​​​​​​

SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;SELECT @@GLOBAL.GTID_EXECUTED;

重建复制：

change master to master_host='192.168.56.201',master_port=3306,master_user='repl',master_password='123456',master_auto_position=1;

# 启动复制，查看复制状态​​​​​​​

start slave;show slave status\G

5、克隆过程中的状态监控

MySQL performance_schema库中提供了clone_status和clone_progress来查询克隆的状态与进度，以便对克隆过程进行监控。​​​​​​​

SELECT STATE, ERROR_NO, ERROR_MESSAGE FROM performance_schema.clone_status;SELECT STAGE, STATE, END_TIME FROM performance_schema.clone_progress;

6、使用限制

克隆技术的一些限制条件：

• 版本大于等于8.0.17且不支持跨版本。要求相同版本号，您无法MySQL 5.7和MySQL 8.0之间进行克隆，在8.0.19和8.0.20之间也不可以，而且要求版本>=8.0.17。

• 克隆操作期间不允许使用 DDL，允许并发DML。

• 两台机器具有相同的操作系统OS。同一平台同一架构，例如linux to windows、x64 to x32 是不支持。

• 两台MySQL实例具体相同的 innodb_page_size 和 innodb_data_file_path(ibdata文件名)

• 同一时刻仅仅允许有一个克隆任务存在

• recipient 需要设置变量clone_valid_donor_list

• max_allowed_packet 大于2M

• doner的undo表空间文件名称不能重复

• 不会克隆my.cnf文件

• 不会克隆binlog二进制日志。

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

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

• 捐赠者和接受者分别需要有至少BACKUP_ADMIN/CLONE_ADMIN权限的账号

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

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

官方文档对远程克隆数据的详细介绍：
MySQL :: MySQL 8.0 Reference Manual :: 5.6.7.3 Cloning Remote Data

                       

远程克隆数据的用途： 
1、MGR节点快速扩充

2、主从复制的slave节点快速搭建（其实和MGR节点快速扩充操作时一样的，今天的案例以这种为主）

                    

远程克隆数据语法： 
    远程克隆操作涉及本地MySQL服务器实例(“recipient”)启动克隆操作的服务器，以及远程MySQL服务器实例(“donor”)源数据所在的位置。当对接收方启动远程克隆操作时，克隆的数据将通过网络从donor传输到recipient。默认情况下，远程克隆操作将删除recipient数据目录中的数据，并将其替换为已克隆的数据。还可以选择将数据复制到recipient上的其他目录，以避免删除现有数据。

语法：

CLONE INSTANCE FROM 'user'@'host':port

IDENTIFIED BY 'password'

[DATA DIRECTORY [=] 'clone_dir']

[REQUIRE [NO] SSL];     ---用户需要有BACKUP_ADMIN权限

DATA DIRECTORY：是一个可选子句，用于在接收端指定要克隆的数据的目录。如果不想删除recipient原数据目录中的现有数据，可以使用此选项修改数据copy的目录，必须有绝对路径，且目录必须不存在。不指定的话，则默认克隆到Recipient的数据目录下。

[REQUIRE [NO] SSL]：显式指定在通过网络传输克隆数据时是否使用加密连接。如果不能满足显式规范，则返回错误。如果未指定SSL子句，克隆将在默认情况下尝试建立加密连接，如果安全连接尝试失败，则返回到不安全连接。无论是否指定此子句，克隆加密数据时都需要安全连接。  

                

如何停止远程克隆：
SQL> select * from performance_schema.clone_status\G;       ---克隆操作的状态

PID：Processlist ID。对应show processlist中的Id，如果要终止当前的克隆操作，执行kill processlist_id命令即可。

           

SQL> Kill+id号;

            

远程克隆相关视图： 
SQL> select * from performance_schema.clone_status\G;       ---克隆操作的状态

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”代表当前实例的数据目录。

BINLOG_FILE：克隆完成后的file号

BINLOG_POSITION：file的pos点

GTID_EXECUTED：克隆的gtid点，可利用这些信息来搭建从库。

         

SQL> select

   stage,

   state,

   cast(begin_time as DATETIME) as "START TIME",

   cast(end_time as DATETIME) as "FINISH TIME",

   lpad(sys.format_time(power(10,12) * (unix_timestamp(end_time) - unix_timestamp(begin_time))), 10, ' ') 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(round(data*100/estimate, 0), "%"), 7, ' ')

   when end_time is NULL then lpad('0%', 7, ' ')

   else lpad('100%', 7, ' ')

   end as "Done(%)"

   from performance_schema.clone_progress;

STAGE：一个克隆操作可依次细分为DROP DATA，FILE COPY，PAGE COPY，REDO COPY，FILE SYNC，RESTART，RECOVERY等7个阶段。当前阶段结束了才会开始下一个阶段。本地克隆只涉及到前五个阶段完成DROP DATA，FILE COPY，PAGE COPY，REDO COPY，FILE SYNC，远程克隆涉及到七个阶段

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

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

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

THREADS：当前阶段使用的并发线程数。并发线程数一般由clone_autotune_concurrency参数自动调节。默认为ON，此时该参数最大线程数受clone_max_concurrency参数控制。若设置为OFF，则并发线程数的数量将是固定的同clone_max_concurrency参数保持一致。clone_max_concurrency参数的默认值为16。

ESTIMATE：预估的数据量。

DATA：已经拷贝的数据量。

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

DATA_SPEED：当前数据拷贝的速率。注意，是当前值。

NETWORK_SPEED：当前网络传输的速率。注意，是当前值。

                         

案例开始（通过远程克隆对主从复制的slave节点快速搭建）：

1、主库（Donor）上的配置

（1）将1个从库的域名加入到hosts文件

[root@mysql1 ~]# vi /etc/hosts
192.168.56.31 mysql1     ---原有域名解析
192.168.56.32 mysql2
                   

（2）创建二进制和中继日志目录（如果主库已经开了二进制日志则不需要配置）

[root@mysql1 ~]# mkdir -p /mysql/log/3306/binlog      ---二进制目录日志
[root@mysql1 ~]# mkdir -p /mysql/log/3306/relaylog    ---中继日志目录
[root@mysql1 ~]# chown -R mysql:mysql /mysql/log/3306/binlog     
[root@mysql1 ~]# chown -R mysql:mysql /mysql/log/3306/relaylog
[root@mysql1 ~]# chmod -R 775 /mysql/log/3306/binlog
[root@mysql1 ~]# chmod -R 775 /mysql/log/3306/relaylog
                    

（3）配置相关参数

[root@mysql1 ~]# cp  /etc/my.cnf /etc/my.cnf.bak
 
[root@mysql1 ~]#vi  /etc/my.cnf  
###binlog###
binlog_gtid_simple_recovery=1                    ---（默认值）这个参数控制了当mysql启动或重启时，mysql在搜寻GTIDs时是如何迭代使用binlog文件的。这个选项设置为真，会提升mysql执行恢复的性能。因为这样mysql-server启动和binlog日志清理更快
log_bin=/mysql/log/3306/binlog/itpuxdb-binlog    ---二进制输出路径（指定之后将指定的值赋给log_bin_basename这个参数上，log_bin显示为on，bug）
log_bin_index=/mysql/log/3306/binlog/itpuxdb-binlog.index     ---记录二进制日志文件的基本名称和路径在这个可读的文件中。默认和log_bin参数的值相同，并在此基础上会自动加上扩展名.index
binlog_format=ROW                     ----二进制工作模式，’ROW’会记录每一行数据被修改的情况（必须）   
binlog_rows_query_log_events=on       ----二进制日志中记录更详细的SQL操作。一个事务就是一个事件，binary log events
expire_logs_days = 10                 ----二进制日志保留天数（根据业务安排，官方表示只删除二进制。中继日志由relay_log_purge参数控制在sql线程应用完之后自动清理，默认为on启用）
               

（4）Clone（数据克隆）插件安装

mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';    ---这种是手动在线安装插件，不需要重启，并且重启后也不会失效。
 
mysql> show plugins;

                

（5）主从库创建复制用户并授权  

mysql> create user 'repuser'@'%' identified with mysql_native_password BY '123456';
mysql> grant replication client,replication slave on *.* to 'repuser'@'%';
mysql> flush privileges;
mysql> select user,host from mysql.user;
             

（6）在Donor实例上创建克隆用户（用于recipient端复制）

mysql> create user 'donor_clone_user'@'%' identified by '123456';
mysql> grant backup_admin on *.* to 'donor_clone_user'@'%';
                  

2、从库（recipient）上的配置

（1）将主从库的域名加入到hosts文件

[root@mysql2 ~]# vi /etc/hosts
192.168.56.31 mysql1
192.168.56.32 mysql2
               

（2）创建二进制和中继日志目录

[root@mysql2 ~]# mkdir -p /mysql/log/3306/binlog      ---二进制目录日志
[root@mysql2 ~]#mkdir -p /mysql/log/3306/relaylog     ---中继日志目录
[root@mysql2 ~]#chown -R mysql:mysql /mysql/log/3306/binlog     
[root@mysql2 ~]#chown -R mysql:mysql /mysql/log/3306/relaylog
[root@mysql2 ~]#chmod -R 775 /mysql/log/3306/binlog
[root@mysql2 ~]#chmod -R 775 /mysql/log/3306/relaylog
                 

（3）配置相关参数

[root@mysql2 ~]#cp  /etc/my.cnf /etc/my.cnf.bak
 
[root@mysql2 ~]#vi  /etc/my.cnf 
###binlog###
binlog_gtid_simple_recovery=1                  ---（默认值）这个参数控制了当mysql启动或重启时，mysql在搜寻GTIDs时是如何迭代使用binlog文件的。这个选项设置为真，会提升mysql执行恢复的性能。因为这样mysql-server启动和binlog日志清理更快
log_bin=/mysql/log/3306/binlog/itpuxdb-binlog  ---二进制输出路径（指定之后将指定的值赋给log_bin_basename这个参数上，log_bin显示为on，bug）
log_bin_index=/mysql/log/3306/binlog/itpuxdb-binlog.index   ---记录二进制日志文件的基本名称和路径在这个可读的文件中。默认和log_bin参数的值相同，并在此基础上会自动加上扩展名.index
binlog_format=ROW                   ----二进制工作模式，’ROW’会记录每一行数据被修改的情况（必须）
binlog_rows_query_log_events=on     ----二进制日志中记录更详细的SQL操作。一个事务就是一个事件，binary log events
expire_logs_days = 10               ----二进制日志保留天数（根据业务安排，官方表示只删除二进制。中继日志由relay_log_purge参数控制在sql线程应用完之后自动清理，默认为on启用）
 
###slave parameter###
max_relay_log_size                                 ---中继日志大小，默认为0，可以手动定义大小。官方表示如果max_relay_log_size为0，那么将继承max_binlog_size二进制日志大小（继承二进制大小即可，默认1G大小）
relay_log=/mysql/log/3306/relaylog/itpuxdb_relay   ---中继日志输出路径
relay_log_index=/mysql/log/3306/relaylog/itpuxdb_relay.index    ---中继日志索引输出路径（根据生产而定） 
slave_parallel_type=LOGICAL_CLOCK                               ---默认DATABASE值，兼容MySQL 5.6基于schema级别的并发复制，基于库的并行复制方式;   LOGICAL_CLOCK值：基于组提交的并行复制方式，组提交是一堆事务的集合，减轻1O压力（之前是采用一个事务提交一次，设置为LOGICAL_CLOCK后多个事务执行完成后提交一次，减轻IO压力）。
super_read_only=1                                               ---Slave机器上对数据库进行修改或者删除，会导致主从的不一致，需要对Slave机器设置为read_only=1让Slave提供只读操作。read_only仅仅对没有SUPER权限的用户有效(即mysql.user表的Super_priv字段为Y)，一般给App的权限是不需要SUPER权限的。参数super_read_only可以将有SUPER权限的用户也设置为只读，且该参数设置为ON后 read_only也跟着自动设置为ON
slave_parallel_workers=4                                        ---4个sql_thread（coordinator线程）来进行并行复制，可以动态调整复制线程数（是四个SQL线程，IO线程还是一个）。并且需要重启主从复制生效
relay_log_recovery=1                                            ---IO线程安全。支持中继日志自我修复功能，日志丢失损坏时，从主master获取日志，完成日志的恢恢复（该参数表示当前接受到的relay log全部删除，然后从sql线程回放到的位置重新拉取）
relay_log_info_repository=table                                 ---SQL线程安全。默认是file，SQL线程的数据回放是写数据库操作，relay-info是写文件操作。这两个操作很难保证一致性，relay-info将写入到mysql.slave_relay_log_info这张表中
master_info_repository=table                                    ---默认是file，IO线程也是接收一个个的event。通过设置参数master_info_repository可以将master-info信息写到什么位置，性能上比设置为FILE有很高的提升，可靠性也得到保证，设置为TABLE后，master-info将信息保存到mysql.slave_master_info
slave_skip_errors=ddl_exist_errors                              ---解决ddl语句在从库造成冲突，可设置off，all，ErorCode，ddl_exist_erros选项。默认为off。如果使用show slave status\G中看到last_Errno：1062，那么设置slave_skip_errors=1062，slave_skip_errors=all，slave_skip_errors=ddl_exist_errors解决
slave_preserve_commit_order=1                                   ---slave上commit的顺序保持一致，必须为1，否则可能会有GAP锁产生
                

（4）Clone（数据克隆）插件安装

mysql> INSTALL PLUGIN clone SONAME 'mysql_clone.so';    ---这种是手动在线安装插件，不需要重启，并且重启后也不会失效。
 
mysql> show plugins;

       

（5）主从库创建复制用户并授权  

mysql> create user 'repuser'@'%' identified with mysql_native_password BY '123456';
mysql> grant replication client,replication slave on *.* to 'repuser'@'%';
mysql> flush privileges;
mysql> select user,host from mysql.user;
            

（6）在Recipient实例上创建克隆用户（用于recipient连接）

mysql> create user 'recipient_clone_user'@'%' identified by '123456';
mysql> grant clone_admin on *.* to 'recipient_clone_user'@'%';
              

（7）设置克隆期间允许DDL（为了在克隆期间允许DDL，设置clone_ddl_timeout参数为0，虽然会导致克隆失败但要保证DDL不受影响。8.0.27版本新增clone_block_ddl参数在克隆期间允许DDL同时不会导致克隆失败。这个设置可选）

mysql> set global clone_ddl_timeout=0;   
###设置为0意味着克隆操作不会等待备份锁。在这种情况下，执行并发DDL操作可能导致克隆操作失败，设置为其他数值发现还是需要等到克隆完成，只有设置为0。
             

（8）在Recipient上设置Donor白名单，只克隆白名单中的实例

mysql> set global clone_valid_donor_list = '192.168.56.31:3306';     ----Donor主库的ip和端口
             

（9）在Recipient上发起克隆命令

[root@slave ~]# mysql -urecipient_clone_user -p123456 -S /mysql/data/3306/mysql.sock
mysql> clone instance from 'donor_clone_user'@'192.168.56.31':3306 identified by '123456';  
###从库完成DROP DATA，FILE COPY，PAGE COPY，REDO COPY，FILE SYNC后，在RESTART阶段进行重启实例，在启动的过程中会用xxx.#clone替换掉原来的系统表空间文件，最后进行RECOVERY
                     

（10）查看克隆操作

mysql> select * from performance_schema.clone_status\G;       ---克隆操作的状态

mysql> select 
   stage,
   state,
   cast(begin_time as DATETIME) as "START TIME",
   cast(end_time as DATETIME) as "FINISH TIME",
   lpad(sys.format_time(power(10,12) * (unix_timestamp(end_time) - unix_timestamp(begin_time))), 10, ' ') 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(round(data*100/estimate, 0), "%"), 7, ' ')
   when end_time is NULL then lpad('0%', 7, ' ')
   else lpad('100%', 7, ' ')
   end as "Done(%)"
   from performance_schema.clone_progress;

              

（11）验证从库数据

mysql> show databases;
mysql> select table_name from information_schema.tables;
mysql> select * from ded.itpuxbak11;  
mysql> select * from itpuxdb.emp; 
mysql> select * from itpuxdb.yg; 
###能查询到数据，表示数据恢复的没问题。可能存在表不能查询的情况，那么就是数据字典没有记录表的问题，需要多验证几张
              

（12）在从库上使 slave 与 master 建立连接

mysql> select * from performance_schema.clone_status\G;
通过clone在线数据克隆的相关视图得知，备份时当时的二进制写入的是binlog.000127日志，pos点为236。Gtid为aa51378a-878d-11ed-b4fb-080027504174:1-11284,bf5ce993-4462-11ee-9699-080027504174:1-4，那么通过gtid无损复制需要指定gtid，show master status;的值

mysql> set @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
mysql> set @@SESSION.SQL_LOG_BIN= 0;
mysql> set @@GLOBAL.GTID_PURGED='aa51378a-878d-11ed-b4fb-080027504174:1-11284,bf5ce993-4462-11ee-9699-080027504174:1-4';     
###指定gtid_purged为clone在线数据克隆备份时的gtid点，就是通知数据库这个gtid之前的事务被清除了（也是就记录自动清理或者手动清理的二进制最后的全局事务ID），向设置的gtid_purged点开始向后复制事务。如果有多个事务，用逗号分隔即可
mysql> set @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;
mysql> Show variables like '%gtid%';
 
mysql> change master to
          master_host='192.168.56.31', 
          master_port=3306,
          master_user='repuser',
          master_password='123456',
          master_auto_position=1;    ---GTID replication采用自动定位binlog+position
 
mysql> start slave;            ---启动主从复制
 
mysql> show slave status \G;   ---Auto_Position为1：使用的就是GTID技术，GTID replication采用自动binlog+position。

      

 （13）验证对象数量 

mysql> select * from sys.schema_object_overview where db='itpuxdb';    ---数据对象