最详细的clone plugin 介绍
1、可以实现的功能介绍
MySQL 8.0.17推出的clone plugin插件，利用克隆插件能够扩展实现：
SQL命令进行备份。
Slave节点快速搭建。
MGR节点快速扩充。html
而克隆插件的基础功能，能够理解为：
能够对自己的实例的InnoDB数据，备份到本服务器的指定目录中。（本地克隆：本地备份）
能够将远程实例的InnoDB数据还原到当前的实例中。（远端克隆：远端备份 + 本实例自动还原）
能够将远程实例的InnoDB数据还原到当前的实例的其余目录中。（远端克隆：远端备份）mysql
2、克隆插件介绍
克隆插件容许从本地或远程的MySQL Server中克隆数据。克隆的数据是存储在InnoDB中的schema（database）、table（表）、tablespaces（表空间）和data dictionary metadata（数据字典元数据）的物理快照。该物理快照其实是一个功能完整的数据目录，MySQL克隆插件可使用该数据目录来配置并恢复一个MySQL Server。linux
2.1克隆插件分为本地clone和远程clone：
本地克隆：指的是将数据从启动克隆操做的MySQL Server克隆到该MySQL Server的主机上的一个指定目录下
远程克隆：涉及到启动克隆操做的本地MySQL Server（称为"recipient"，即，数据的接收者或接收方）和数据源所在的远程MySQL Server（称为"donor"，即，数据的提供者或发送方），在接收方上启动远程克隆操做时，克隆的数据会经过网络从发送方传输到接收方。
默认状况下，远程可能那个操做会删除接收方数据目录中的全部数据，并将其替换为克隆的新数据。若是不但愿接收方中的现有数据被删除，你也能够在接收方中执行克隆操做时将克隆数据指定存放在其余目录中redis
2.2克隆插件应用场景：
对于克隆的数据自己来讲，本地克隆操做与远程克隆操做没有太大区别。
克隆插件支持在复制拓扑中使用。除了克隆数据外，克隆操做还可以从发送方中提取和传输复制坐标（二进制日志的位置），并将其应用于接收方，也就是说，咱们可使用克隆插件来在组复制中添加新的组成员，也能够在主从复制拓扑中添加新的从库。
与经过二进制日志来复制大量事务相比，经过克隆插件要快得多，效率也更高（更多信息详见"六、在复制拓扑中使用克隆"）。组复制成员还能够配置使用克隆插件来做为另外一种恢复方法（若是不使用克隆插件，则必须使用基于二进制日志的状态传输进行数据恢复），当组成员和待加入组的Server都配置支持克隆插件时，待加入组的Server能够自行决定选择一个更加高效的方式从种子成员中获取数据。
有关更多信息，请参见《MySQL Group Replication for 8.0》."4.3.1 克隆用于分布式恢复"。sql
2.3克隆插件支持克隆数据加密的和数据页压缩：
克隆插件支持克隆数据加密的和数据页压缩。详情可参考"四、克隆加密数据"和“五、克隆压缩数据"shell
2.4使用克隆功能须先安装克隆插件：
有关安装的说明，详情可参考"3、安装克隆插件"。有关克隆的命令，详情可参考"4、克隆演示”。数据库
3、安装克隆插件
下面是mysql8.0.20二进制安装和插件具体安装过程：安全
[root@mysql-redis182 3307]# wget -P /data/soft https://cdn.mysql.com//Downloads/MySQL-8.0/mysql-8.0.20-linux-glibc2.12-x86_64.tar.xz
[root@mysql-redis182 3307]# tar Jxf /data/soft/mysql-8.0.20-linux-glibc2.12-x86_64.tar.xz -C /usr/local/
[root@mysql-redis182 logs]# cd /usr/local/;ln -sv mysql-8.0.20-linux-glibc2.12-x86_64 mysql
[root@mysql-redis182 ~]# grep -w '/data/mysql/3307' /data/mysql/3307/my8.cnf
datadir = /data/mysql/3307/data
slow_query_log_file = /data/mysql/3307/logs/slow.log
log-error = /data/mysql/3307/logs/error.log
log-bin = /data/mysql/3307/binlog/mysql-bin
innodb_undo_directory = /data/mysql/3307/undolog
[root@mysql-redis182 logs]# /usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/3307/my8.cnf --initialize
开启mysql_clone.so参数写入配置文件；
[root@mysql-redis182 mysql]# grep clone /data/mysql/my8.cnf
plugin-load-add=mysql_clone.so
clone=FORCE_PLUS_PERMANENT ##启动时加载插件并防止它在运行时被删除，
获取到密码：
[root@mysql-redis182 logs]# grep -w 'root@localhost' error.log |awk '{print $NF}'
nbspMeu*K4g1
[root@mysql-redis182 3307]# /usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/3307/my8.cnf &
[1] 12614
[root@mysql-redis182 3307]# ss -lntup|grep 3306
tcp LISTEN 0 1024 :::3306 :::* users:(("mysqld",pid=12614,fd=35))
tcp LISTEN 0 70 :::33060 :::* users:(("mysqld",pid=12614,fd=31))
修改密码：
root@localhost [(none)]>alter user user() identified by 'rRt&8UiJpN3v7Cx'
root@localhost [(none)]>select version();
+-----------+
| version() |
+-----------+
| 8.0.20 |
+-----------+
1 row in set (0.00 sec)
开启clone插件：服务器
root@localhost [(none)]>INSTALL PLUGIN clone SONAME 'mysql_clone.so';
INSTALL PLUGIN语句能够加载插件，并将其注册到mysql系统库下的mysql.plugins表中，这样在后续重启MySQL Server时不须要重复使用--plugin-load-add选项来加载插件库微信
验证插件是否安装完成，能够查看INFORMATION_SCHEMA.plugins表或者使用SHOW PLUGINS语句查看：
root@localhost [(none)]>SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'clone'; +-------------+---------------+ | PLUGIN_NAME | PLUGIN_STATUS | +-------------+---------------+ | clone | ACTIVE | +-------------+---------------+ 1 row in set (0.00 sec)
卸载插件：UNINSTALL PLUGIN clone;
克隆插件参数写入配置文件：
例如，要在启动时加载插件并防止它在运行时被删除，可使用如下选项:
提示在初始化mysql8.0 前不要加入下面的参数，不然致使初始化报错以及启动mysql报错
[mysqld]
plugin-load-add=mysql_clone.so
clone=FORCE_PLUS_PERMANENT ##启动时加载插件并防止它在运行时被删除，
有关插件激活状态的更多信息，请参见连接：https://dev.mysql.com/doc/refman/8.0/en/plugin-loading.html#server-plugin-activating
4、克隆插件演示：
4.1克隆本地数据：
克隆插件支持用于在本地克隆数据的语法，即，将数据从本地（相同主机）的一个MySQL Server的数据目录克隆到本地MySQL Server所在主机的一个指定目录下，
使用克隆插件执行克隆本地数据的操做语法以下：
mysql> CLONE LOCAL DATA DIRECTORY [=] 'clone_dir';
要正确使用CLONE语法，必须先安装克隆插件。有关安装说明，请参见"前文"。
执行CLONE LOCAL DATA DIRECTORY语句须要用户具备BACKUP_ADMIN权限，所以须要先授予操做用户该权限，语句以下：
#语法：
mysql> CLONE LOCAL DATA DIRECTORY = '/path/to/clone_dir';
其中，clone_user是用于执行克隆操做的MySQL用户。该用户能够是在"."上（全局权限）具备BACKUP_ADMIN权限的任何MySQL用户。
mysql> GRANT BACKUP_ADMIN ON . TO 'clone_user'@'127.0.0.1' idnetified by 'sjdue2398uys'; 此语法在mysql8.0中不支持了
下面是正确的受权语法：
create user clone_user@'127.0.0.1' identified by 'sjdue2398uys';flush privileges; GRANT BACKUP_ADMIN ON *.* TO clone_user@'127.0.0.1'; grant all on *.* to clone_user@'127.0.0.1';
[root@localhost mysql]# mysql -uclone_user -h127.0.0.1 -p'sjdue2398uys' mysql> CLONE LOCAL DATA DIRECTORY = '/data/mysql/mydata_clone'; # 这是克隆的副本目录 Query OK, 0 rows affected (36.46 sec)
#查看克隆目录下的文件：
mysql> system ls -lh /data/mysql/mydata_clone 总用量 5.1G drwxr-x--- 2 mysql mysql 4.0K 5月 8 12:02 #clone -rw-r----- 1 mysql mysql 5.6K 5月 8 12:01 ib_buffer_pool -rw-r----- 1 mysql mysql 1.0G 5月 8 12:01 ibdata1 -rw-r----- 1 mysql mysql 2.0G 5月 8 12:02 ib_logfile0 -rw-r----- 1 mysql mysql 2.0G 5月 8 12:02 ib_logfile1 drwxr-x--- 2 mysql mysql 4.0K 5月 8 12:01 mysql -rw-r----- 1 mysql mysql 24M 5月 8 12:01 mysql.ibd drwxr-x--- 2 mysql mysql 4.0K 5月 8 12:01 sys -rw-r----- 1 mysql mysql 10M 5月 8 12:01 undo_001 -rw-r----- 1 mysql mysql 10M 5月 8 12:01 undo_002
在上述操做语句中，"/path/to/clone_dir"是将数据克隆到本地目录的绝对路径。
该路径中，"clone_dir"目录不能事先存在（事先存在会报错），但路径前缀"/path/to/"必须事先存在。
另外，MySQL Server必须具备在文件系统中建立目录所需的写权限。
注意：本地克隆操做不支持克隆位于数据目录外部的用户建立的表或表空间。
尝试克隆此类表或表空间会致使报错：
ERROR 1086 (HY000): File '/path/to/tablespace_name.ibd' already exists.。
克隆操做时若是指定了一个与数据源表空间相同路径时会致使冲突，所以被禁止
重要提示：
当执行克隆操做时，全部用户建立的InnoDB表和表空间，InnoDB系统表空间，redo log和undo log表空间都将被克隆到指定目录下
注意：克隆操做只会克隆数据文件，除了系统变量datadir以外，
若是系统变量innodb_data_home_dir、innodb_data_file_path、innodb_log_group_home_dir、innodb_undo_directory单独指定了不一样于datadir指定的路径，则也会被执行克隆，
系统变量socket、pid-file、tmpdir、log-error、slow_query_log_file、log-bin、relay-log指定路径下的文件不会被克隆
若是须要，能够在克隆操做完成后使用克隆的数据目录启动一个新的MySQL Server，例如：
#其中clone_dir是克隆操做完成以后的数据副本目录
shell> mysqld_safe --datadir=clone_dir
#示例
先将第二个MySQL Server的配置文件设置好，不能与同一个主机中其余MySQL Server的配置文件存在路径冲突，也不能存在端口冲突，而后，使用mysqld_safe启动第二MySQL Server，使用--datadir指定克隆的数据副本目录。
因为原先的实例开启了innodb_undo_directory 存放undolog的日志，然而指定目录/data/mysql/mydata_clone 克隆完成后，undolog日志存放了/data/mysql/mydata_clone 这个下面，因此clonemy8.cnf配置文件要从新指定innodb_undo_directory=/data/mysql/mydata_clone，才能基于clone副本数据正常启动新的实例
mysqld_safe --defaults-file=/data/mysql/clonemy8.cnf --datadir=/data/mysql/mydata_clone & 固然mysqld --defaults-file=/data/mysql/clonemy8.cnf --datadir=/data/mysql/mydata_clone & 也能够启动的
本地指定目录克隆后，重启新实例的mysql的配置文件须要修改的路径以下：
[root@localhost ~]# egrep '3307|mydata_clone' /data/mysql/clonemy8.cnf port = 3307 socket = /tmp/mysql3307.sock port = 3307 datadir = /data/mysql/mydata_clone socket = /tmp/mysql3307.sock pid-file = mysqldb3307.pid innodb_undo_directory = /data/mysql/mydata_clone
查看clone状态：显示的失败，然而本地指定目录clone,事实上是成功的
由于指定DATA DIRECTORY，本地磁盘空间须要更多的空间（克隆数据+本地历史数据），不会自动重启MySQL实例
mysql> select * from performance_schema.clone_status; +------+------+--------+-------------------------+----------+----------------+----------------+----------+-------------------------------------------------------------------------------+-------------+-----------------+---------------+ | ID | PID | STATE | BEGIN_TIME | END_TIME | SOURCE | DESTINATION | ERROR_NO | ERROR_MESSAGE | BINLOG_FILE | BINLOG_POSITION | GTID_EXECUTED | +------+------+--------+-------------------------+----------+----------------+----------------+----------+-------------------------------------------------------------------------------+-------------+-----------------+---------------+ | 1 | 0 | Failed | 2020-05-08 12:01:44.674 | NULL | LOCAL INSTANCE | LOCAL INSTANCE | 1815 | Recovery failed. Please Retry Clone. For details, look into server error log. | | 0 | | +------+------+--------+-------------------------+----------+----------------+----------------+----------+-------------------------------------------------------------------------------+-------------+-----------------+---------------+ 1 row in set (0.00 sec) mysql> select * from performance_schema.clone_progress; +------+-----------+-----------+----------------------------+----------------------------+---------+------------+------------+---------+------------+---------------+ | ID | STAGE | STATE | BEGIN_TIME | END_TIME | THREADS | ESTIMATE | DATA | NETWORK | DATA_SPEED | NETWORK_SPEED | +------+-----------+-----------+----------------------------+----------------------------+---------+------------+------------+---------+------------+---------------+ | 1 | DROP DATA | Completed | 2020-05-08 12:01:44.674154 | 2020-05-08 12:01:44.674758 | 1 | 0 | 0 | 0 | 0 | 0 | | 1 | FILE COPY | Completed | 2020-05-08 12:01:44.674812 | 2020-05-08 12:01:57.679768 | 2 | 1119999520 | 1119999520 | 0 | 0 | 0 | | 1 | PAGE COPY | Completed | 2020-05-08 12:01:57.679858 | 2020-05-08 12:01:57.882701 | 2 | 0 | 0 | 0 | 0 | 0 | | 1 | REDO COPY | Completed | 2020-05-08 12:01:57.882761 | 2020-05-08 12:01:58.084247 | 2 | 8192 | 8192 | 0 | 0 | 0 | | 1 | FILE SYNC | Completed | 2020-05-08 12:01:58.084367 | 2020-05-08 12:02:21.137360 | 2 | 0 | 0 | 0 | 0 | 0 | | 1 | RESTART | Completed | 2020-05-08 12:02:21.137360 | 2020-05-08 12:17:37.276226 | 0 | 0 | 0 | 0 | 0 | 0 | | 1 | RECOVERY | Failed | 2020-05-08 12:17:37.276226 | NULL | 0 | 0 | 0 | 0 | 0 | 0 | +------+-----------+-----------+----------------------------+----------------------------+---------+------------+------------+---------+------------+---------------+ 7 rows in set (0.00 sec) mysql>
提示：
手动启动MySQL Server后，能够链接到接收方MySQL Server检查performance_schema下的clone_progress和clone_status表，以验证克隆操做是否成功完成。对于RESTART语句也会执行相同的监控
4.2 克隆远程数据
4.2.1克隆远程数据语法介绍:
克隆插件支持如下语法来克隆远程数据，即，从远程MySQL Server（数据捐赠者，或称为donor节点）克隆数据并将其传输到执行克隆操做的MySQL Server（数据接收者，或称为recipient节点）
CLONE INSTANCE FROM 'user'@'host':port IDENTIFIED BY 'password' [DATA DIRECTORY [=] 'clone_dir'] [REQUIRE [NO] SSL];
以上语法中的一些关键字解释：
"user"是donor MySQL Server上的用于执行克隆操做的用户，须要具备对全部库全部表的BACKUP_ADMIN权限
"host"是donor MySQL Server的主机名或IP地址。不支持IPV6地址，但支持IPV6地址别名与IPV4地址
"port"是donor MySQL Server的端口号。(不支持mysqlx_port指定的X协议端口。也不支持经过MySQL Router链接到donor MySQL Server)
"password"是"user"的用户密码
"DATA DIRECTORY [=] 'clone_dir'" 是一个可选子句，用于在recipient节点上为要克隆的数据副本指定一个本地存放目录。
若是不但愿删除recipient节点上数据目录中的现有数据，请使用此选项指定一个其余路径。
但须要指定一个绝对路径，而且该目录不能事先存在、MySQL Server必须具备建立目录所需的写访问权限。
若是在执行克隆操做时未使用可选的"DATA DIRECTORY [=] 'clone_dir'" 子句，则克隆操做将删除recipient节点数据目录中的现有数据，并用克隆数据副原本替换它，而后自动从新启动MySQL Server
"[REQUIRE [NO] SSL]" 用于显式指定在经过网络传输克隆数据时是否使用加密链接。
若是使用了该子句但不能知足SSL使用条件，则返回一个错误。
若是没有指定SSL子句，则克隆数据时默认会先尝试创建加密链接，但若是SSL链接尝试失败，则退回使用不安全链接。
另外，不管是否指定此子句，若是要克隆加密数据，则必须使用安全链接。
有关更多信息，请参见下文中"为克隆配置加密链接"部分，原文连接：https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-remote.html#clone-plugin-remote-ssl
注意：
默认状况下，驻留在发送方（donor节点）MySQL Server的数据目录中用户建立的InnoDB表和表空间，会被克隆到接收方（recipient节点）MySQL Server的数据目录中（接收方中与数据文件存放相关的系统变量指定的路径下）。
若是指定了"DATA DIRECTORY [=] 'clone_dir'"子句，则在接收方中会将克隆数据存放到指定的目录下
若是用户建立的InnoDB表和表空间位于发送方MySQL Server的数据目录以外，它们会被克隆到接收方MySQL Server的相同路径上。
若是在接收方MySQL Server的相同路径上存在相同文件（表或表空间文件），则会报错.默认状况下，InnoDB的系统表空间、redo log和undo log表空间被克隆到与donor节点上的相关系统变量指定的相同位置
（分别由系统变量innodb_data_home_dir和innodb_data_file_path、innodb_log_group_home_dir和innodb_undo_directory指定）。
所以，若是未指定DATA DIRECTORY [=] 'clone_dir'子句，请确保donor节点和recipient节点中的相关系统变量设了为相同路径，若是指定了DATA DIRECTORY [=] 'clone_dir'子句，那么这些表空间和日志将被克隆到指定的目录下
（但若是指定了克隆数据的存放目录，则全部的数据文件都会被存放到该目录下，所以，在使用这些集中存放的克隆数据文件来启动新的MySQL Server以前，你可能须要手动作一些路径调整）
4.2.2远程克隆的前提条件：
要执行远程克隆操做，克隆插件必须在发送方和接收方的MySQL Server上都是安装且都处于激活状态。有关安装说明，请参见"安装克隆插件"
执行远程克隆操做须要在发送方和接收方上都建立好用于克隆操做的MySQL用户（对于发送方和接收方上各自用户克隆的用户，其用户名和密码能够不相同），且授予足够的权限
- 对于发送方，克隆用户须要BACKUP_ADMIN权限来访问和传输发送方的数据，并在克隆操做期间阻塞DDL操做
-
对于接收方，克隆用户须要CLONE_ADMIN权限来替换接收方的数据，并在克隆操做期间阻塞DDL操做，并自动从新启动MySQL Server。
注意：CLONE_ADMIN权限隐式地包含了BACKUP_ADMIN和SHUTDOWN权限。当执行远程克隆操做时（执行CLONE INSTANCE语句）会执行一些前提条件检查：- 发送方和接收方必须拥有相同的MySQL Server版本。注意：MySQL 8.0.17及更高版本支持克隆插件，低于MySQL 8.0.17版本不支持，可使用：SELECT VERSION()语句查看版本号
- 发送方和接收方MySQL Server必须运行在相同的操做系统和平台上。
例如，若是donor节点运行在一个Linux 64位平台上，那么recipient节点也必须运行在Linux 64位平台上。有关如何肯定操做系统平台的信息，请参阅操做系统相关文档 - 接收方必须有足够的磁盘空间来存放克隆数据。默认状况下，在接收方中接收发送方的克隆数据以前会先删除接收方的数据，所以只须要按照发送方的数据大小来提供足够的磁盘空间便可。
但若是使用了DATA DIRECTORY [=] 'clone_dir'子句将克隆数据存放到指定的目录下，则必须考虑接收方和发送方的数据总大小，以便提供足够存放二者数据大小的磁盘空间。
能够经过检查文件系统上的数据目录大小和位于数据目录以外的任何表空间的大小来估计数据的大小。在估计发送方的数据大小时，请记住只有InnoDB数据是克隆的。
若是在其余存储引擎中存储了数据，在估算克隆所需的磁盘空间时请注意排除这些数据文件的大小
-
InnoDB容许在数据目录（datadir系统变量指定的目录）以外建立一些表空间类型。若是发送方MySQL Server有驻留在数据目录以外的表空间，则克隆操做必须可以访问这些表空间。
能够经过查询INFORMATION_SCHEMA.FILES表来识别位于数据目录以外的数据表空间有哪些，驻留在数据目录以外的数据表空间文件是一个绝对路径。
查询语句：SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILESroot@localhost [(none)]>SELECT FILE_NAME FROM INFORMATION_SCHEMA.FILES; +-----------------------------------+ | FILE_NAME | +-----------------------------------+ | ./ibdata1 | | ./ibtmp1 | | /data/mysql/3307/undolog/undo_001 | | /data/mysql/3307/undolog/undo_002 | | ./mysql.ibd | | ./sys/sys_config.ibd | +-----------------------------------+ 6 rows in set (0.00 sec)
- 在发送方上处于激活状态的任何插件，也必须在接收方上处于活动状态。能够经过执行SHOW plugins语句或查询INFORMATION_SCHEMA.PLUGINS表来识别活跃状态的插件
- 发送方和接收方必须具备相同的MySQL Server字符集和排序规则。有关MySQL Server字符集和排序配置的信息，请参阅：https://dev.mysql.com/doc/refman/8.0/en/charset-configuration.html
-
发送方和接收方须要具备相同的innodb_page_size和innodb_data_file_path系统变量设置。在发送方和接收方上的innodb_data_file_path系统变量设置必须指定相同数量、相同大小的数据文件。
可使用SHOW VARIABLES语句检查各自的变量设置值。例如：SHOW VARIABLES LIKE 'innodb_page_size';SHOW VARIABLES LIKE 'innodb_data_file_path'; -
若是克隆加密数据或压缩页数据，则发送方和接收方必须具备相同的文件系统块大小。
对于页压缩数据，接收方的文件系统必须支持稀疏文件和打孔（文件系统的概念，可参考连接：http://www.voidcn.com/article/p-cwkauntz-bpz.html），以便在接收方的文件系统上打孔。
有关这些特性以及如何识别使用它们的表和表空间的信息，请参见下文中的"四、克隆加密数据"和"五、克隆压缩数据"。要肯定文件系统块大小，请参阅操做系统相关的文档。 -
若是要克隆加密数据，则须要启用安全链接。请参见下文中"为克隆配置加密链接"部分
-
接收方上的系统变量clone_valid_donor_list的设置必须包含donor MySQL Server的主机地址。由于只能从有效的接收方列表中的主机克隆数据。
若是要设置该系统变量，则须要用户具备SYSTEM_VARIABLES_ADMIN权限。在本节后面的远程克隆示例中提供了设置clone_valid_donor_list系统变量的说明。
可使用SHOW VARIABLES语句检查clone_valid_donor_list系统变量的设置。例如：SHOW VARIABLES LIKE 'clone_valid_donor_list' - 克隆操做只能串行执行，不能多个克隆操做并行执行，要肯定是否有克隆操做正在运行，能够经过查询performance_schema.clone_status表进行确认，详情可参考"九、监控克隆操做"
- 克隆插件以1MB大小的数据包和1M大小的元数据的形式传输数据。所以，在发送方和接收方的MySQL Server上，max_allowed_packet变量的最小值要求为2MB。
小于2MB的max_allowed_packet变量值会致使报错。可使用查询语句来检查max_allowed_packet变量的设置：SHOW VARIABLES LIKE 'max_allowed_packet'
如下前提条件也适用于远程克隆操做：
-
UNDO表空间文件名必须是惟一的。当数据被从发送方克隆到接收方时，不管UNDO表空间在发送方上的什么位置下存放着，都会被克隆到接收方上的innodb_undo_directory系统变量指定的位置，或者被克隆到DATA DIRECTORY [=] 'clone_dir'子句指定的目录下（若是使用该子句的话）。
从MySQL 8.0.18开始，若是在克隆操做期间遇到重复的undo表空间文件名，就会报告错误。在MySQL 8.0.18以前，克隆具备相同文件名的undo表空间可能会致使接收方上的undo表空间文件被覆盖。 -
要查看UNDO表空间文件名以确保它们的名称是惟一的，能够经过查询INFORMATION_SCHEMA.FILES表，例如：SELECT TABLESPACE_NAME, FILE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE LIKE 'UNDO LOG'
-
有关删除和添加undo表空间文件的信息，请参阅：https://dev.mysql.com/doc/refman/8.0/en/innodb-undo-tablespaces.html
-
默认状况下，在克隆数据完成以后，将自动从新启动（中止和启动）接收方MySQL Server。
要实现自动重启，必须在接收方上有一个监控进程来检测Server关闭。
不然，在数据被克隆后、克隆操做中止、并关闭了接收方MySQL Server以后会报错：ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process)。
此错误不表示克隆操做失败。这意味着在克隆数据以后，必须手动启动接收方MySQL Server。
手动启动MySQL Server后，能够链接到接收方MySQL Server检查performance_schema下的clone_progress和clone_status表，以验证克隆操做是否成功完成。
对于RESTART语句也会执行相同的监控。有关更多信息，请参见：https://dev.mysql.com/doc/refman/8.0/en/restart.html。
若是使用DATA DIRECTORY [=] 'clone_dir'子句克隆到指定目录，则不适用此要求，由于在此状况下不会执行自动从新启动MySQL Server
（指定克隆目录的状况下，全部数据文件都被拷贝到了该目录下，实际启动MySQL Server时，配置文件中可能将redo log、undo log和数据文件指向了不一样的路径） - 克隆插件支持多个系统变量用于控制远程克隆操做。在执行远程克隆操做以前，请检查系统变量并根据须要进行调整以适应你的运行环境。
克隆相关的系统变量是在执行克隆操做的MySQL Server上设置的（接收方）。参见"十二、克隆插件系统变量"
克隆远程数据操做示例：默认状况下，远程克隆操做会删除接收方数据目录中的数据，用克隆的数据替换，而后从新启动MySQL Server
（但指定了DATA DIRECTORY [=] 'clone_dir'子句时不会执行自动重启），该示例假设已经知足了全部的前提条件呢，详情参见上文
4.2.四、远程克隆数据：
环境：
192.168.1.105 master实例
192.168.1.182 新的实例
安装过程能够参考“3、安装克隆插件”，此处再也不赘述。
开始操做演示：
192.168.1.105 机器发送端操做：
使用管理用户登陆到发送方 donor MySQL Server中，建立一个克隆用户并赋予BACKUP_ADMIN权限： root@localhost [(none)]> create user donor_clone_user@'192.168.1.%' identified by 'clone_test66'; Query OK, 0 rows affected (0.02 sec) root@localhost [(none)]>grant backup_admin on *.* to donor_clone_user@'192.168.1.%'; Query OK, 0 rows affected (0.02 sec) 在donor MySQL Server中安装克隆插件: root@localhost [(none)]>INSTALL PLUGIN clone SONAME 'mysql_clone.so'; ERROR 1125 (HY000): Function 'clone' already exists
192.168.1.182接受方机器操做：
使用管理用户登陆到接收方MySQL Server，建立一个克隆用户并赋予CLONE_ADMIN权限：
root@localhost [(none)]>create user recipient_clone_user@'192.168.1.%' identified by 'clone_test66';
root@localhost [(none)]>grant clone_admin on *.* to recipient_clone_user@'192.168.1.%';
在接收方MySQL Server中安装克隆插件:
root@localhost [(none)]>INSTALL PLUGIN clone SONAME 'mysql_clone.so';
ERROR 1125 (HY000): Function 'clone' already exists
将donor MySQL Server的主机地址添加到接收方MySQL Server的clone_valid_donor_list变量中:
root@localhost [(none)]> SET GLOBAL clone_valid_donor_list = '192.168.1.105:3306';
以在donor MySQL Server中建立的克隆用户，登陆到接收方MySQL Server中，执行以下克隆语句:（指定克隆目录操做）
root@localhost [(none)]>CLONE INSTANCE FROM 'donor_clone_user'@'192.168.1.105':3306 IDENTIFIED BY 'clone_test66' DATA DIRECTORY = '/data/mysql/3307/clone_data';
Query OK, 0 rows affected (24.72 sec)
查看克隆状态：
root@localhost [performance_schema]>select * from clone_status\G
*************************** 1. row ***************************
ID: 1
PID: 9
STATE: Completed
BEGIN_TIME: 2020-05-08 16:34:20.646
END_TIME: 2020-05-08 16:34:45.358
SOURCE: 192.168.1.105:3306
DESTINATION: /data/mysql/3307/clone_data/
ERROR_NO: 0
ERROR_MESSAGE:
BINLOG_FILE:
BINLOG_POSITION: 0
GTID_EXECUTED:
1 row in set (0.00 sec)
root@localhost [performance_schema]>select * from clone_progress;
+------+-----------+-------------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
| ID | STAGE | STATE | BEGIN_TIME | END_TIME | THREADS | ESTIMATE | DATA | NETWORK | DATA_SPEED | NETWORK_SPEED |
+------+-----------+-------------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
| 1 | DROP DATA | Completed | 2020-05-08 16:34:20.769263 | 2020-05-08 16:34:20.871097 | 1 | 0 | 0 | 0 | 0 | 0 |
| 1 | FILE COPY | Completed | 2020-05-08 16:34:20.871379 | 2020-05-08 16:34:31.474627 | 4 | 1119999445 | 1119999445 | 1120067369 | 0 | 0 |
| 1 | PAGE COPY | Completed | 2020-05-08 16:34:31.474938 | 2020-05-08 16:34:31.776621 | 4 | 0 | 0 | 393 | 0 | 0 |
| 1 | REDO COPY | Completed | 2020-05-08 16:34:31.777004 | 2020-05-08 16:34:32.077628 | 4 | 2560 | 2560 | 3325 | 0 | 0 |
| 1 | FILE SYNC | Completed | 2020-05-08 16:34:32.077900 | 2020-05-08 16:34:45.357769 | 4 | 0 | 0 | 0 | 0 | 0 |
| 1 | RESTART | Not Started | NULL | NULL | 0 | 0 | 0 | 0 | 0 | 0 |
| 1 | RECOVERY | Not Started | NULL | NULL | 0 | 0 | 0 | 0 | 0 | 0 |
+------+-----------+-------------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
7 rows in set (0.00 sec)
克隆到指定目录说明：
默认状况下，远程克隆操做会删除接收方数据目录中的数据，并用克隆的数据替换它。
经过克隆到指定目录，能够避免接收方数据目录中的现有数据被删除，也不会执行重启MySQL Server的操做。
将数据克隆到指定目录的过程与不指定目录的克隆远程数据过程相同，但有一点区别，前者的克隆语句必须包含DATA DIRECTORY [=] 'clone_dir'子句。
例如：CLONE INSTANCE FROM 'donor_clone_user'@'192.168.1.105':3306 IDENTIFIED BY 'clone_test66' DATA DIRECTORY = '/data/mysql/3307/clone_data';
其中，DATA DIRECTORY子句须要指定一个绝对路径，且该目录不能事先存在，MySQL Server必须具备建立目录所需的写访问权限
克隆到指定目录时，在克隆数据完成以后，不会自动从新启动接收方MySQL Server。
若是你想使用指定目录启动MySQL Server，你必须手动修改一些文件的目录调整以后再执行启动，或者直接使用新的my.cnf配置文件，
在启动时将--datadir选项指定到克隆数据所在的目录，例如：mysqld_safe --datadir=/data/mysql/3307/clone_data
因为配置文件制定了undo文件存放目录，因此也要修改下：
[root@mysql-redis182 ~]# grep -w 'clone_data' /data/mysql/3307/my8.cnf datadir = /data/mysql/3307/clone_data innodb_undo_directory = /data/mysql/3307/clone_data
而后启动mysql服务：
/usr/local/mysql/bin/mysqld --defaults-file=/data/mysql/3307/my8.cnf & 登陆192.168.1.182 发现主库192.168.1.105上建立的数据已经clone本地了 root@localhost [(none)]>show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | sys | | test001 | | test002 | +--------------------+ 6 rows in set (0.01 sec) root@localhost [(none)]>select user,host from mysql.user; +------------------+-------------+ | user | host | +------------------+-------------+ | donor_clone_user | 192.168.1.% | | mysql.infoschema | localhost | | mysql.session | localhost | | mysql.sys | localhost | | root | localhost | +------------------+-------------+ 5 rows in set (0.00 sec)
启动克隆版的MySQL，查看接受放的二进制日志位置和gtid信息：
克隆操做结束以后，可在执行克隆操做的MySQL Server上执行以下查询语句，以检查发送给接收方的二进制日志位置：
root@localhost [(none)]>SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status; +------------------+-----------------+ | BINLOG_FILE | BINLOG_POSITION | +------------------+-----------------+ | mysql-bin.000002 | 2463 | +------------------+-----------------+ 1 row in set (0.01 sec)
在克隆操做结束以后，可在执行克隆操做的MySQL Server上执行以下查询，以检查传输给接收方的GTID SET：
root@localhost [(none)]>SELECT @@GLOBAL.GTID_EXECUTED; +------------------------------------------------------------------------------------+ | @@GLOBAL.GTID_EXECUTED | +------------------------------------------------------------------------------------+ | e03f6a3a-90f8-11ea-9e29-842b2b72175e:1-9, fb9ad95e-9104-11ea-ab74-b82a72cec95c:1-3 | +------------------------------------------------------------------------------------+ 1 row in set (0.01 sec)
提示：当在192.168.1.182机器接受端未指定克隆目录操做，会清空当前192.168.1.182mysql实例数据目录下的数据，而后把克隆的数据复制过来，而且会自动重启mysql服务，因为undolog日志路径变化致使重启失败
登陆到接收方192.168.1.182MySQL Server中，执行以下克隆语句:（未指定克隆目录操做）
root@localhost [(none)]> CLONE INSTANCE FROM 'donor_clone_user'@'192.168.1.105':3306 IDENTIFIED BY 'clone_test66' ;
ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process).
5、利用远程克隆的数据进行复制拓扑扩展应用介绍：
当在发送方上设置master_info_repository=TABLE和relay_log_info_repository=TABLE时（这是MySQL 8.0的默认设置），若是发送方是一个从库角色，那么从库的状态日志会被保存在表中，这些表在克隆操做期间会从发送方当作数据复制到接收方。
从库的状态日志中保存了与复制相关的配置设置，这些设置可用于在克隆操做成功以后正确地自动恢复复制
（若是配置文件中没有设置skip_slave_start参数，则在克隆操做完成以后会自动启动复制线程，另外，若是发送方不是从库而是主库，那么从库的状态日志表中并不存在复制配置信息，所以不适用，恢复复制过程当中须要手动执行CHANGE MASTER语句进行配置）。
在MySQL 8.0.17和8.0.18中，只有mysql.slave_master_info表才会被复制到接收方（主库信息日志）
从MySQL 8.0.19开始，mysql.slave_relay_log_info（中继日志信息日志）和mysql.slave_worker_info（从库worker线程日志）也会被复制到接收方
PS：有关上述三张表中每一个表包含的内容列表及其含义，请参阅：https://dev.mysql.com/doc/refman/8.0/en/slave-logs-status.html。
注意，若是在发送方上设置了master_info_repository=FILE和relay_log_info_repository=FILE（这不是MySQL 8.0的默认设置，而且是不推荐的），则不会克隆从库的状态日志，只有在发送方设置master_info_repository=TABLE和relay_log_info_repository=TABLE时才会克隆从库的状态日志信息。
要在复制拓扑中使用克隆，请按照如下步骤执行：
对于用于组复制的新组成员，请先按照连接：https://dev.mysql.com/doc/refman/8.0/en/group-replication-adding-instances.html 中的说明为组复制配置好MySQL Server环境，且按照连接：https://dev.mysql.com/doc/refman/8.0/en/group-replication-cloning.html的说明设置好克隆功能所需的前提条件。
而后，在joiner成员上执行START GROUP_REPLICATION语句时，克隆操做由组复制自动管理，所以不须要手动执行joiner成员加入组的操做，也不须要在joiner成员上执行任何进一步的设置步骤。
对于主从复制拓扑中的从库，首先在从库（接收方）中手动执行远程克隆操做语句，将数据从donor MySQL Server克隆到接收方。
在复制拓扑中，发送方必须是主库或从库。若是发送方是主库的，则后续须要手动执行CHANGE MASTER语句来配置复制，若是发送方是从库的，则不须要手动执行复制配置操做，复制可以经过克隆数据进行自动恢复复制
（配置文件中指定了skip_slave_start参数的状况除外）。有关克隆语句的详细信息，请参见"三、克隆远程数据"
克隆操做成功完成后，若是要在接收方MySQL Server上使用与发送方相同的复制通道，请验证其中哪些设置或配置能够在主从复制拓扑中自动恢复，哪些须要手动设置才能恢复。
-
对于基于GTID的复制，若是在接收方配置了gtid_mode=ON，而且在发送方设置了gtid_mode=ON、ON_PERMISSIVE或 OFF_PERMISSIVE值，则接收方的gtid_executed系统变量中的GTID SET会做为接收方的GTID SET。
若是接收方的数据是从拓扑中已经存在的一个从库中克隆出来的，则在启用了GTID自动定位（由CHANGE MASTER TO语句上的MASTER_AUTO_POSITION选项指定）的接收方上的复制通道能够在自动重启MySQL Server以后自动恢复，不须要执行任何手动设置（若是须要修改复制通道，则自行调整，这里不作赘述） -
对于基于二进制日志文件位置的复制，若是接收方使用的是MySQL 8.0.17或8.0.18，则来自发送方的二进制日志位置不该用于接收方，仅记录在performance_schema.clone_status表中。
所以，在自动重启实例以后，必须在接收方中手动为复制通道设置使用基于二进制日志文件位置的复制，以便恢复复制。
在这种状况下，须要确保在重启实例时启用skip_slave_start来避免复制自动启动，由于此时并未设置二进制日志位置，自动启动复制将尝试从头开始复制。 - 对于基于二进制日志文件位置的复制，若是接收方使用的是MySQL 8.0.19或以上版本，则来自发送方的二进制日志位置将应用于接收方。
接收方上使用基于二进制日志文件位置的复制，将会在自动重启复制通道以前，使用中继日志信息自动尝试执行中继日志的恢复过程。
注意：对于单线程的从库（slave_parallel_workers设置为0），在没有任何其余意外发生的状况下，复制通道无需进一步设置便可成功恢复复制。
对于多线程的从库（slave_parallel_workers大于0），中继日志恢复可能会失败，由于它一般不能自动完成。在这种状况下，会发出一条错误消息，您必须手动设置通道
5.1利用远程克隆数据，部署基于gtid主从复制搭建
在mysql8.0上是不支持以下的受权方式：
192.168.1.105 master库操做：
错误的受权姿式
root@localhost [test001]>grant replication slave on *.* to novelrep@'192.168.1.182' identified by 'JuwoSdk21TbUser'; flush privileges; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'identified by 'JuwoSdk21TbUser'' at line 1 Query OK, 0 rows affected (0.02 sec)
正确的受权姿式
root@localhost [test001]>create user novelrep@'192.168.1.182' identified by 'JuwoSdk21TbUser'; grant replication slave on *.* to novelrep@'192.168.1.182'; Query OK, 0 rows affected (0.03 sec) Query OK, 0 rows affected (0.00 sec)
CHANGE MASTER TO MASTER_HOST='192.168.1.105',MASTER_PORT=3306,MASTER_USER='novelrep',MASTER_PASSWORD='JuwoSdk21TbUser',MASTER_AUTO_POSITION = 1;start slave;
报错：
Last_IO_Errno: 2061
Last_IO_Error: error connecting to master 'novelrep@192.168.1.105:3306' - retry-time: 60 retries: 1 message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.
解决办法：
root@localhost [(none)]>create user novelrep@'192.168.1.182' identified WITH 'mysql_native_password' by 'JuwoSdk21TbUser'; grant replication slave on *.* to novelrep@'192.168.1.182'; Query OK, 0 rows affected (0.02 sec) Query OK, 0 rows affected (0.00 sec)
192.168.1.182库操做：
CHANGE MASTER TO MASTER_HOST='192.168.1.105',MASTER_PORT=3306,MASTER_USER='novelrep',MASTER_PASSWORD='JuwoSdk21TbUser',MASTER_AUTO_POSITION = 1;start slave;
Last_IO_Errno: 13117
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work (or the --replicate-same-server-id option must be used on slave but this does not always make sense; please check the manual before using it).
缘由是server_id冲突了
解决办法：修改192.168.1.182上的server-id
show slave status\G 自动恢复复制，复制正常
6、克隆插件回顾总结
6.1本地clone+还原注意事项：
5.1只克隆innodb存储引擎的数据。非INNODB引擎的表只会生成空表。
5.2 不会克隆原实例的所有目录结构，只克隆了data目录下的相关数据。
5.3 克隆的目标目录必须不存在，克隆过程会生成该目录，因此原实例的启动帐户要有建立目录的权限。
5.4 克隆后的目录会自动设置：mysql:mysql
5.5 克隆目标目录不会生成原实例自定义的innodb_undo_directory
5.6 克隆不会拷贝原实例的binlog文件
6.2远程克隆数据注意事项:
执行CLONE INSTANCE在非donor实例上执行。
不指定DATA DIRECTORY，将先清空本地数据，再作克隆拷贝，并自动重启MySQL实例（建议mysqld_safe启动）。
若指定DATA DIRECTORY，本地磁盘空间须要更多的空间（克隆数据+本地历史数据），不会自动重启MySQL实例
donor 和 recipient的MySQL版本要一致，而且至少8.0.17或者更高的版本。
donor 和 recipient的操做系统不能跨平台。
donor 和 recipient须要具备相同的字符集和排序规则。
donor和 recipient须要设置相同的 innodb_page_size and innodb_data_file_path
若是克隆了加密或者页压缩的数据，donor 和 recipient须要保持同样的文件系统块大小。
克隆命令将以1MB的包大小传输，因此donor 和 recipient的 max_allowed_packet至少要设置2MB。
6.3.其余注意事项
克隆操做期间不容许DDL（包括TRUNCATE TABLE）。
一次只能克隆一个MySQL实例。不支持在单个克隆操做中克隆多个MySQL实例。
远程克隆操做（在CLONE INSTANCE语句中指定Donor的MySQL服务器实例的端口号时）不支持mysqlx_port指定的X协议端口。
clone插件不支持MySQL配置参数的克隆。
clone插件不支持二进制日志的克隆。
克隆插件仅克隆存储在InnoDB中的数据。其余存储引擎数据未克隆。存储在任何数据库（包括sys模式）中的MyISAM和CSV表都被克隆为空表
鸣谢：本博文是在学些了马蜂窝高级DBA张充和爱可生高级DBA罗小波分享在知书堂微信公众号的关于MySQL8.0的clone plugin插件的文章。结合本身的理解总结于此。特别感谢二位的分享。同时我也分享出来，但愿能帮助到更多的爱好MySQL伙伴，一块儿交流，一块儿成长。
- 1. _MSC_VER详细介绍 _MSC_VER详细介绍
- 2. vue中eslintrc.js配置最详细介绍
- 3. 全网最详细的Redis介绍
- 4. UIWindow 史上最详细的介绍
- 5. 最全的ajax详细介绍，ajax全
- 6. 关于 npm 最详细的介绍
- 7. Kafka史上最详细的介绍!!!!!!!!
- 8. 详细介绍git clone --depth=1的用法
- 9. DUBBO 详细介绍
- 10. html-webpack-plugin插件的详细介绍和使用
- 更多相关文章...
- • 网站主机 介绍 - 网站主机教程
- • Spring整合Redis详细步骤 - Redis教程
- • Java Agent入门实战（一）-Instrumentation介绍与使用
- • 为了进字节跳动，我精选了29道Java经典算法题，带详细讲解
-
每一个你不满意的现在，都有一个你没有努力的曾经。