看看MySQL8新特性ClonePlugin
mysql视频教程栏目介绍MySQL 8的新特性Clone Plugin
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.so clone=FORCE_PLUS_PERMANENT
这里的clone，严厉来说，不是参数名，而是插件名，可加可不加，FORCE_PLUS_PERMANENT 控制插件的行为。
有四个取值：
- ON**（**开启插件）
- OFF（禁用插件）
- FORCE（强迫开启。要是插件初始化失败，MySQL将不会启动）
- FORCE_PLUS_PERMANENT（在FORCE的根基上，不允许通过UNINSTALL PLUGIN下令卸载插件）。
（2）动态加载
[mysqld] plugin-load-add=mysql_clone.so clone=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 'clone_user'@'%';
新建克隆名目
# mkdir /data/mysql # chown -R mysql.mysql /data/mysql
新建当地克隆
# mysql -uclone_user -pclone_pass mysql> clone local data directory='/data/mysql/3307';
其中，“/data/mysql/3307” 是克隆名目，其需知足下列几点请求：
- 克隆名目必需是绝对途径。
- “/data/mysql”必需存在，且MySQL对其有可写权限。
- 3307不克不及存在。
查看克隆名目的内容
# ll /data/mysql/3307 total 172996 drwxr-x--- 2 mysql mysql 89 May 24 22:37 #clone -rw-r----- 1 mysql mysql 3646 May 24 22:37 ib_buffer_pool -rw-r----- 1 mysql mysql 12582912 May 24 22:37 ibdata1 -rw-r----- 1 mysql mysql 50331648 May 24 22:37 ib_logfile0 -rw-r----- 1 mysql mysql 50331648 May 24 22:37 ib_logfile1 drwxr-x--- 2 mysql mysql 6 May 24 22:37 mysql -rw-r----- 1 mysql mysql 25165824 May 24 22:37 mysql.ibd drwxr-x--- 2 mysql mysql 20 May 24 22:37 slowtech drwxr-x--- 2 mysql mysql 28 May 24 22:37 sys -rw-r----- 1 mysql mysql 10485760 May 24 22:37 undo_001 -rw-r----- 1 mysql mysql 11534336 May 24 22: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 'user'@'host':port IDENTIFIED BY 'password' [DATA DIRECTORY [=] 'clone_dir'] [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_user'@'%' identified by 'donor_pass'; mysql> grant backup_admin on *.* to 'donor_user'@'%'; mysql> install plugin clone soname 'mysql_clone.so';
backup_admin是克隆操纵必须权限。
接着，在Recipient实例上新建克隆会员，加载Clone Plugin。
mysql> create user 'recipient_user'@'%' identified by 'recipient_pass'; mysql> grant clone_admin on *.* to 'recipient_user'@'%'; mysql> install plugin clone soname 'mysql_clone.so';
这里的clone_admin，隐式含有backup_admin（阻塞DDL）和shutdown（重新启动实例）权限。
设定Donor白名单。Recipient只能克隆白名单中的实例。
mysql> set global clone_valid_donor_list = '192.168.244.10:3306';
设定该参数需要SYSTEM_VARIABLES_ADMIN权限。
在Recipient上发起克隆下令
# mysql -urecipient_user -precipient_pass mysql> clone instance from 'donor_user'@'192.168.244.10':3306 identified by '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/data/ ... -rw-r----- 1 mysql mysql 3646 May 25 07:20 ib_buffer_pool -rw-r----- 1 mysql mysql 3646 May 27 07:31 ib_buffer_pool.#clone -rw-r----- 1 mysql mysql 12582912 May 27 07:31 ibdata1 -rw-r----- 1 mysql mysql 12582912 May 27 07:31 ibdata1.#clone -rw-r----- 1 mysql mysql 50331648 May 27 07:32 ib_logfile0 -rw-r----- 1 mysql mysql 50331648 May 27 07:31 ib_logfile0.#clone ... -rw-r----- 1 mysql mysql 25165824 May 27 07:31 mysql.ibd -rw-r----- 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表。
mysql> select * from performance_schema.clone_status\G
*************************** 1\. row ***************************
ID: 1
PID: 0
STATE: Completed
BEGIN_TIME: 2020-05-27 07:31:24.220
END_TIME: 2020-05-27 07:33:08.185
SOURCE: 192.168.244.10:3306
DESTINATION: LOCAL INSTANCE
ERROR_NO: 0
ERROR_MESSAGE:
BINLOG_FILE: mysql-bin.000009
BINLOG_POSITION: 665197555
GTID_EXECUTED: 59cd4f8f-8fa1-11ea-a0fe-000c29f66609:1-560
1 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> 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-27 07:31:28.581661 | 2020-05-27 07:31:35.855706 | 1 | 0 | 0 | 0 | 0 | 0 | | 1 | FILE COPY | Completed | 2020-05-27 07:31:35.855952 | 2020-05-27 07:31:58.270881 | 2 | 482463294 | 482463294 | 482497011 | 0 | 0 | | 1 | PAGE COPY | Completed | 2020-05-27 07:31:58.271250 | 2020-05-27 07:31:58.719085 | 2 | 10977280 | 10977280 | 11014997 | 0 | 0 | | 1 | REDO COPY | Completed | 2020-05-27 07:31:58.720128 | 2020-05-27 07:31:58.930804 | 2 | 465408 | 465408 | 465903 | 0 | 0 | | 1 | FILE SYNC | Completed | 2020-05-27 07:31:58.931094 | 2020-05-27 07:32:01.063325 | 2 | 0 | 0 | 0 | 0 | 0 | | 1 | RESTART | Completed | 2020-05-27 07:32:01.063325 | 2020-05-27 07:32:59.844119 | 0 | 0 | 0 | 0 | 0 | 0 | | 1 | RECOVERY | Completed | 2020-05-27 07:32:59.844119 | 2020-05-27 07:33:08.185367 | 0 | 0 | 0 | 0 | 0 | 0 | +------+-----------+-----------+----------------------------+----------------------------+---------+-----------+-----------+-----------+------------+---------------+ 7 rows in set (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> select * from performance_schema.clone_status\G
*************************** 1\. row ***************************
...
BINLOG_FILE: mysql-bin.000009
BINLOG_POSITION: 665197555
GTID_EXECUTED: 59cd4f8f-8fa1-11ea-a0fe-000c29f66609:1-560
1 row in set (0.06 sec) 这里，区分两种场景，GTID复制和基于位置点的复制。
1、GTID复制
mysql> CHANGE MASTER TO MASTER_HOST = 'master_host_name', MASTER_PORT = master_port_num,
...
MASTER_AUTO_POSITION = 1;
mysql> START SLAVE; 需要注意的是，无需额外施行set global gtid_purged操纵。通过克隆数据启动的实例，gtid_purged已经初始化结束。
mysql> show global variables like 'gtid_purged'; +---------------+--------------------------------------------+ | Variable_name | Value | +---------------+--------------------------------------------+ | gtid_purged | 59cd4f8f-8fa1-11ea-a0fe-000c29f66609:1-560 | +---------------+--------------------------------------------+ 1 row in set (0.00 sec)
2、基于位置点的复制
这里，一样要区分两种场景。
场景1，Recipient要作为Donor的从库。
mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;
mysql> CHANGE MASTER TO MASTER_HOST = 'master_host_name', MASTER_PORT = master_port_num,
...
MASTER_LOG_FILE = 'master_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主库的从库。
mysql> SELECT MASTER_LOG_NAME, MASTER_LOG_POS FROM mysql.slave_relay_log_info;
mysql> CHANGE MASTER TO MASTER_HOST = 'master_host_name', MASTER_PORT = master_port_num,
...
MASTER_LOG_FILE = 'master_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：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 8.0.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相干。
相干免费学习举荐：mysql视频教程
以上就是看看MySQL 8 新特性Clone Plugin的细致内容，更多请关注 百分百源码网 其它相干文章！
