MySQL篇—通过Clone插件进行远程克隆数据（第三篇，总共三篇）

💫《博主介绍》：✨又是一天没白过，我是奈斯，DBA一名✨

💫《擅长领域》：✌️擅长Oracle、MySQL、SQLserver、阿里云AnalyticDB for MySQL(分布式数据仓库)、Linux，也在扩展大数据方向的知识面✌️

💖💖💖大佬们都喜欢静静的看文章，并且也会默默的点赞收藏加关注💖💖💖

    在介绍 Clone 最终篇之前，我们先简要回顾一下前面所讲的内容。在第一篇中，我们探讨了 Clone 的用途、使用的前提条件、存在的限制，以及它的备份原理。Clone 是一种用于复制和备份数据的工具，它能够快速高效地创建数据的精确副本。使用 Clone 需要满足一定的前提条件，同时还需要注意一些限制。

    在第二篇中，我们深入探讨了如何通过 Clone 进行本地克隆数据。 本地克隆操作从MySQL服务器实例中克隆数据，其中克隆操作启动到MySQL服务器实例运行的同一服务器或节点上的目录。通过 Clone 进行本地克隆数据需要遵循一定的步骤，包括选择要克隆的源和目标位置、配置 Clone 参数、执行克隆操作等。完成克隆后，我们可以验证数据的完整性和一致性。

    今天，在第三篇中，我们将介绍如何通过 Clone 进行远程克隆数据。远程克隆是指将数据从源位置复制到远程服务器或云存储位置的过程。与本地克隆相比，远程克隆需要更多的配置和设置，以确保数据能够安全地传输到远程位置。我们将详细介绍如何配置远程克隆的参数、执行远程克隆操作以及验证数据的完整性和一致性。

    别忘了点赞哦！否则我会觉得我的文章写得像是一堆废纸。

    Clone技术涉及到理论介绍、本地克隆方式介绍、远程克隆方式介绍，所以都整理到一篇中着实会感觉到阅读疲劳，所以我将分为三篇文章介绍，三篇文章分别如下：

第一篇：自带物理克隆数据工具Clone插件介绍

第二篇：通过Clone插件进行本地克隆数据

第三篇：通过Clone插件进行远程克隆数据（当前篇）

---

                             

目录

官方文档对远程克隆数据的详细介绍：

远程克隆数据的用途： 

远程克隆数据语法： 

如何停止远程克隆：

远程克隆相关视图： 

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

---

                          

官方文档对远程克隆数据的详细介绍：

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 * from performance_schema.clone_progress;    ###克隆的进度信息
          
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节点快速搭建）：

项目：门户网站，数据量100G

操作系统：两台red hat linx 8.3/centos

主从架构：一主一从

数据库版本：mysql 8.0.17以上

主库IP：192.168.56.31   3306

从库IP：192.168.56.32   3306

注意：使用clone远程有个问题（有时候遇到了，有时候就没遇到，注意就行），如果两个实例之间互为从库，那么将主库clone到从库，主库连接到从库的show slave status\G;就会消失，所以进行clone前主库和从库都先记录下select * from mysql.slave_master_info\G;和show slave status\G;  

              

一、主库（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 ~]# vi  /etc/my.cnf
    
###basic### 
server_id=313306                ---服务id主从要不同必须唯一，用于区分主从（如果一主多从，server_id要不同）。一般后IP+端口 
skip_name_resolve = on          ---默认为off，用于控制MySQL服务器在解析客户端连接时是否进行反向DNS查找。当启用skip_name_resolve时，MySQL服务器将不会尝试通过反向DNS查找来解析客户端的主机名。启用skip_name_resolve的好处：
                     1）提高连接性能：反向DNS查找可能会导致连接延迟，特别是在网络环境较差或DNS服务器响应较慢的情况下。通过启用skip_name_resolve，可以避免这种延迟，从而提高连接性能。
                     2）避免DNS配置问题：在某些情况下，DNS配置可能不正确或不可靠，导致反向DNS查找失败或超时。通过启用skip_name_resolve，可以避免由于DNS配置问题而导致的连接问题。
                     3）安全性考虑：启用skip_name_resolve可以防止通过反向DNS查找获取客户端的主机名，从而提高一定程度的安全性。这可以防止潜在的信息泄露，尤其是在某些情况下，客户端主机名可能包含敏感信息。
    启用skip_name_resolve的影响：
                     1）可能会导致一些功能受限，例如MySQL的访问控制列表（ACL）功能可能无法使用主机名进行授权。
                     2）MySQL 服务器将不会尝试将客户端的 IP 地址解析为主机名。这意味着所有与网络相关的操作，如用户权限检查，都将基于 IP 地址而不是主机名来进行。意味着所有用户账户的主机部分需要使用IP地址格式，例如：'user'@'192.168.0.1' 而不是 'user'@'hostname'，并且之前已经创建了基于主机名的用户账户，在启用此参数后，这些账户将无法登录，需要修改这些账户的主机部分为IP地址格式
innodb_support_xa =1                    ---1表示打开分布式事务，崩溃后启用bin log恢复
binlog_cache_size = 1M                  ---bin log缓存大小，一般1-4M（参数默认32K）
max_binlog_size = 2048M                 ---单个二进制大小（参数默认为1024M）
log_bin_trust_function_creators = 1     ---1表示同步存储过程、函数（默认为0表示不同步，切记设置为1）
innodb_flush_log_at_trx_commit =1       ---1表示每次事务提交时把log buffer写入log file，并且flush到磁盘（此参数不设置也是1）。1（实时写，实时刷）：redo log buffer--实时--> redo log file--实时--> disk(实时调用flush + fsync没法批处理，性能很低)  
sync_binlog = 1      ---5.6默认为0，5.7和8.0默认为1。该参数控制着二进制日志写入磁盘的过程。为0时表示不控制binlog的刷新，由系统自己将binlog buffer pool刷新到磁盘二进制日志中。这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog buffer pool中的所有binlog信息都会被丢失。
transaction-isolation = READ-COMMITTED  ---建议设置为read-committed事务级别，默认为REPEATABLE-READ
gtid_mode=on                            ---开启gtid模式
enforce_gtid_consistency=1              ---服务器只允许执行可以使用GTID安全记录的语句，从而增强GTID的一致。开启会导致开启后对于特定create table不被支持，如CREATE TABLE ... SELECT、CREATE TEMPORARY TABLE、DROP TEMPORARY TABLE等语句
log_slave_updates=1                     ---是否将master上的二进制日志内容更新记录到slave自己的二进制日志中。通常master上的二进制日志内容不会更新记录到slave自己的二进制日志中（主从复制靠的是SQL线程主动read中继日志，和从库上二进制开不开启，记不录记录无关）。启用此变量将使slave其复制SQL线程执行的更新写入自己的二进制日志。若要使此选项生效，还必须使用--log-bin选项以启用二进制日志记录。
    如果是一主多从，可以建议不开启，因为各个从库复制靠的是SQL线程主动read中继日志，和从库上二进制开不开启，记不录记录无关。
    如果是级联主从从，那么需要开启，因为二级从库要读取一级从库的二进制日志。一级从库切换为主后建议关掉log-slave-updates参数，否则重置成主库以后，可能会将已经执行过的二进制日志重复传送给slave，导致slave同步错误。
    
###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（数据克隆）插件安装

第一种方式（将插件写到参数文件）：
plugin_dir=/mysql/app/mysql/lib/plugin/       ---mysql插件的默认安装位置 
plugin_load="rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so;mysql_clone.so"                                       ---插件加载
     
      
第二种方式（手动安装）：
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端复制）

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

                  

二、从库（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@mysql1 ~]# vi  /etc/my.cnf
     
###basic### 
server_id=323306                ---服务id主从要不同必须唯一，用于区分主从（如果一主多从，server_id要不同）。一般后IP+端口 
skip_name_resolve = on          ---默认为off，用于控制MySQL服务器在解析客户端连接时是否进行反向DNS查找。当启用skip_name_resolve时，MySQL服务器将不会尝试通过反向DNS查找来解析客户端的主机名。启用skip_name_resolve的好处：
                     1）提高连接性能：反向DNS查找可能会导致连接延迟，特别是在网络环境较差或DNS服务器响应较慢的情况下。通过启用skip_name_resolve，可以避免这种延迟，从而提高连接性能。
                     2）避免DNS配置问题：在某些情况下，DNS配置可能不正确或不可靠，导致反向DNS查找失败或超时。通过启用skip_name_resolve，可以避免由于DNS配置问题而导致的连接问题。
                     3）安全性考虑：启用skip_name_resolve可以防止通过反向DNS查找获取客户端的主机名，从而提高一定程度的安全性。这可以防止潜在的信息泄露，尤其是在某些情况下，客户端主机名可能包含敏感信息。
    启用skip_name_resolve的影响：
                     1）可能会导致一些功能受限，例如MySQL的访问控制列表（ACL）功能可能无法使用主机名进行授权。
                     2）MySQL 服务器将不会尝试将客户端的 IP 地址解析为主机名。这意味着所有与网络相关的操作，如用户权限检查，都将基于 IP 地址而不是主机名来进行。意味着所有用户账户的主机部分需要使用IP地址格式，例如：'user'@'192.168.0.1' 而不是 'user'@'hostname'，并且之前已经创建了基于主机名的用户账户，在启用此参数后，这些账户将无法登录，需要修改这些账户的主机部分为IP地址格式
innodb_support_xa =1                    ---1表示打开分布式事务，崩溃后启用bin log恢复
binlog_cache_size = 1M                  ---bin log缓存大小，一般1-4M（参数默认32K）
max_binlog_size = 2048M                 ---单个二进制大小（参数默认为1024M）
log_bin_trust_function_creators = 1     ---1表示同步存储过程、函数（默认为0表示不同步，切记设置为1）
innodb_flush_log_at_trx_commit =1       ---1表示每次事务提交时把log buffer写入log file，并且flush到磁盘（此参数不设置也是1）。1（实时写，实时刷）：redo log buffer--实时--> redo log file--实时--> disk(实时调用flush + fsync没法批处理，性能很低)  
sync_binlog = 1      ---5.6默认为0，5.7和8.0默认为1。该参数控制着二进制日志写入磁盘的过程。为0时表示不控制binlog的刷新，由系统自己将binlog buffer pool刷新到磁盘二进制日志中。这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog buffer pool中的所有binlog信息都会被丢失。
transaction-isolation = READ-COMMITTED  ---建议设置为read-committed事务级别，默认为REPEATABLE-READ
gtid_mode=on                            ---开启gtid模式
enforce_gtid_consistency=1              ---服务器只允许执行可以使用GTID安全记录的语句，从而增强GTID的一致。开启会导致开启后对于特定create table不被支持，如CREATE TABLE ... SELECT、CREATE TEMPORARY TABLE、DROP TEMPORARY TABLE等语句
log_slave_updates=1                     ---是否将master上的二进制日志内容更新记录到slave自己的二进制日志中。通常master上的二进制日志内容不会更新记录到slave自己的二进制日志中（主从复制靠的是SQL线程主动read中继日志，和从库上二进制开不开启，记不录记录无关）。启用此变量将使slave其复制SQL线程执行的更新写入自己的二进制日志。若要使此选项生效，还必须使用--log-bin选项以启用二进制日志记录。
    如果是一主多从，可以建议不开启，因为各个从库复制靠的是SQL线程主动read中继日志，和从库上二进制开不开启，记不录记录无关。
    如果是级联主从从，那么需要开启，因为二级从库要读取一级从库的二进制日志。一级从库切换为主后建议关掉log-slave-updates参数，否则重置成主库以后，可能会将已经执行过的二进制日志重复传送给slave，导致slave同步错误。
       
###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  ---中继日志索引输出路径（根据生产而定） 
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
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_pending_jobs_size_max=128M                  ---8.0.11之前默认16M，之后默认128M。参数在MySQL 5.6以后引入，如果没有开启多线程复制，则此参数无用。在开启slave_parallel_workers多线程复制时，在队列中Pending的事件所占用的最大内存。如果内存富余，或者延迟较大时，可以适当调大。注意：从库中的此参数的值需等于或大于主库的max_allowed_packet参数值，否则从库的工作队列可能会变满。
                
###parallel replication###
slave_parallel_workers=4                    ---4个sql_thread（coordinator线程）来进行并行复制，可以动态调整复制线程数（是四个SQL线程，IO线程还是一个）。并且需要重启主从复制生效
slave_parallel_type=LOGICAL_CLOCK           ---DATABASE：默认值，基于库的并行复制方式，5.6默认就是这个参数，即每个库只能有一个复制进程。LOGICAL_CLOCK：基于组提交的并行复制方式
slave_preserve_commit_order=1               ---如果要保证事务是按照relay log中记录的顺序来重放，需要设置参数slave_preserve_commit_order=1，这要求从库开启 log_bin 和log_slave_updates，并且slave_parallel_type设置为LOGICAL_CLOCK。启用slave_preserve_commit_order后，正在执行的worker线程将等待，直到所有先前的事务提交后再提交。当复制线程正在等待其它worker线程提交其事务时，它会将其状态报告为等待提交前一个事务。使用此模式，多线程复制的重放顺序与主库的提交顺序保持一致。slave_parallel_workers 参数控制并行复制worker线程的数量

                

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

第一种方式（将插件写到参数文件）：
plugin_dir=/mysql/app/mysql/lib/plugin/       ---mysql插件的默认安装位置 
plugin_load="rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so;mysql_clone.so"                                       ---插件加载

第二种方式（手动安装）：
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连接）

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

                 

（7）了解克隆数据时，对DML和DDL操作的影响

Donor主库：

DML：不影响
mysql> insert into itpux values (23);
Query OK, 1 row affected (0.81 sec)
          
DDL：长期不返回，需要等到克隆完成（不过可以通过设置clone_ddl_timeout参数在克隆期间允许DDL不过会导致克隆失败，在8.0.27版本新增clone_block_ddl参数在克隆期间允许DDL同时不会导致克隆失败）
mysql> create table itdwd (id int);
             无响应
为了在克隆期间允许DDL，设置clone_ddl_timeout参数为0，虽然会导致克隆失败但要保证DDL不受影响。8.0.27版本新增clone_block_ddl参数在克隆期间允许DDL同时不会导致克隆失败

recipient从库：

mysql> set global clone_ddl_timeout=0;     ---只用在recipient上设置即可，设置为0意味着克隆操作不会等待备份锁。在这种情况下，donor主库执行并发DDL操作可能导致克隆操作失败，设置为其他数值发现还是需要等到克隆完成，只有设置为0。在donor主库设置为0，还是长期不返回，还是需要等到克隆完成，所以只用在recipient从库设置为0即可

               

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

mysql> set global clone_ddl_timeout=0;     ---只用在recipient上设置即可，设置为0意味着克隆操作不会等待备份锁。在这种情况下，donor主库执行并发DDL操作可能导致克隆操作失败，设置为其他数值发现还是需要等到克隆完成，只有设置为0。在donor主库设置为0，还是长期不返回，还是需要等到克隆完成，所以只用在recipient从库设置为0即可

                      

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

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

             

（10）在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

      

（11）查看克隆操作

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;

              

（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 host,user from mysql.user;
mysql> show grants for root@'%';

             

第二步：验证数据库是否恢复和备份之后创建表的数据是否恢复

mysql> show databases;
mysql> select * from test04;

                 

 第三步：验证对象数量

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

  

mysql> select engine,count(*) from information_schema.tables group by engine;    ---存储引擎分类

  

                 

第四步：验证数据量：

SQL> select concat('select count(*) from  ',table_schema,'.',table_name,';') from information_schema.tables where table_schema='库名';