☘️博主介绍☘️：
✨又是一天没白过，我是奈斯，DBA一名✨
✌✌️擅长Oracle、MySQL、SQLserver、Linux，也在扩展大数据方向的知识面✌✌️
❣️❣️❣️大佬们都喜欢静静的看文章，并且也会默默的点赞收藏加关注❣️❣️❣️
各位小伙伴，今天我为大家介绍一下 MySQL Clone Plugin 这个插件，简单来说，就是MySQL 8.0.17版本之后的一个物理克隆数据工具，它能够帮助我们快速、高效地克隆或复制数据库，极大地简化了数据库迁移、备份和恢复的过程，让我们在处理大量数据时更加得心应手。
为了确保大家能够充分利用这个强大的工具，我们将分为三篇内容来详细介绍MySQL Clone Plugin。今天我们将从基础入手，首先深入探讨Clone的用途、使用的前提条件、存在的限制，以及它的备份原理。第二篇介绍Clone的本地克隆数据，第三篇介绍Clone的远程克隆数据，通过三篇的介绍我们将会深入了解这个插件是如何工作的，以及为什么它可以成为数据库管理员的得力助手。
希望大家通过今天的分享，能够更好地理解和掌握MySQL Clone Plugin。在接下来的内容中，我们将一起探索这个工具的奥秘，为我们的数据库管理之旅增添更多便利和效率。现在，让我们开始第一篇的旅程吧！
Clone技术涉及到理论介绍、本地克隆方式介绍、远程克隆方式介绍，所以都整理到一篇中着实会感觉到阅读疲劳，所以我将分为三篇文章介绍，三篇文章分别如下：
第一篇：自带物理克隆数据工具Clone插件介绍（当前篇）
第二篇：通过Clone插件进行本地克隆数据
第三篇：通过Clone插件进行远程克隆数据
目录
点赞和关注，是我写文案的动力源泉！
官方文档对Clone Plugin的详细介绍：
MySQL :: MySQL 8.0 Reference Manual :: 5.6.7 The Clone Plugin
clone插件介绍：
MySQL8.0.17中引入的克隆插件允许在本地或从远程MySQL服务器实例中克隆数据（传输数据）。存储的数据的物理快照。InnoDB它包括架构、表、表空间和数据字典元数据。所述克隆数据包括一个功能齐全的数据目录，该目录允许使用用于MySQL服务器配置的克隆插件。
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的用途：
1、SQL命令进行备份。
2、Slave节点快速搭建。
3、MGR节点快速扩充
clone Plugin与XtraBackup的对比：
ps：xtrabackup由Percona提供，开源工具，支持对InnoDB做热备，物理备份工具。余后将独论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（克隆数据）插件的前提条件：
1、使用clone（克隆数据）插件的donor（源库）和recipient（目标库）MySQL版本（包括小版本）必须一致并且都要在8.0.17版本以上，且都要安装Clone Plugin。不然会报错：
ERROR 3864 (HY000): Clone Donor MySQL version: 8.0.20 is different from Recipient MySQL version 8.0.19.
2、主机的操作系统和位数（32位，64位）必须一致。两者可根据version_compile_os，version_compile_machine参数获取。
3、字符集（character_set_server），校验集（collation_server），character_set_filesystem必须一致。
4、innodb_page_size（页大小）必须一致。会检查innodb_data_file_path中ibdata的数量和大小。
5、目前Clone Plugin（8.0.20）的实现，无论是Donor，还是Recipient，同一时间，只能执行一个克隆操作。后续会支持多个克隆操作并发执行。不然会报错：
ERROR 3634 (HY000): Too many concurrent clone operations. Maximum allowed - 1.
6、Recipient需要重启，所以其必须通过mysqld_safe或systemd等进行管理。如果是通过mysqld进行启动，实例关闭后，需要手动启动。不然会报错：
ERROR 3707 (HY000): Restart server failed (mysqld is not managed by supervisor process).
clone（克隆数据）插件的限制：
1、8.0.17到8.0.26版本在克隆期间，允许DML不会影响正在执行的事务，DDL会被克隆的backup lock阻塞。不过可以通过设置clone_ddl_timeout参数在克隆期间允许DDL不过会导致克隆失败，在8.0.27版本新增clone_block_ddl参数在克隆期间允许DDL同时不会导致克隆失败。
2、Clone Plugin不会拷贝Donor（源库）的配置参数。
3Clone Plugin不会拷贝Donor（源库）的二进制日志文件。
4、Clone Plugin只会拷贝InnoDB表的数据，对于其它存储引擎的表只会拷贝表结构（mysql8.0废除了MyISAM、MEMORY存储引擎）
5、Donor（源库）实例中如果有表通过DATA DIRECTORY指定了绝对路径，在进行本地克隆时，会提示文件已存在。在进行远程克隆时，绝对路径必须存在且有可写权限。
6、不允许通过MySQL Router连接到Donor（源库）实例。
7、执行CLONE INSTANCE操作时，指定的Donor端口不能为X Protocol端口。
clone插件克隆数据的两种方式：
(1)本地克隆数据
本地克隆操作从MySQL服务器实例中克隆数据，其中克隆操作启动到MySQL服务器实例运行的同一服务器或节点上的目录。
语法：
CLONE LOCAL DATA DIRECTORY [=] 'clone_dir'; ---用户需要有BACKUP_ADMIN权限
(2)远程克隆数据
远程克隆操作涉及本地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子句，克隆将在默认情况下尝试建立加密连接，如果安全连接尝试失败，则返回到不安全连接。无论是否指定此子句，克隆加密数据时都需要安全连接。
Clone plugin备份原理：
MYSQL> select * from performance_schema.clone_progress;
克隆操作可细分为以下5个阶段：
[INIT] ---> [FILE COPY] ---> [PAGE COPY] ---> [REDO COPY] -> [Done]
第一阶段：INIT
初始化一个克隆对象。需要持有backup lock, 阻止ddl进
第二阶段：FILE COPY（DROP DATA、FILE COPY）
按照文件进行拷贝，同时开启page tracking功能，记录在拷贝过程中修改的page, 此时会设置buf_pool->track_page_lsn为当前lsn，track_page_lsn在flush page阶段用到：
buf_flush_page: if (!fsp_is_system_temporary(bpage->id.space()) && buf_pool->track_page_lsn != LSN_MAX) { page_t *frame; lsn_t frame_lsn; frame = bpage->zip.data; if (!frame) { frame = ((buf_block_t *)bpage)->frame; } frame_lsn = mach_read_from_8(frame + FIL_PAGE_LSN); //对于在track_page_lsn之后的page, 如果frame_Lsn大于track_page_lsn, 表示已经记录下page id了，无需重复记录 arch_page_sys->track_page(bpage, buf_pool->track_page_lsn, frame_lsn, false); // 将page id记录下来，表示在track_page_lsn后修改过的page } 会创建一个后套线程page_archiver_thread()，将内存记录的page id flush到disk上
第三阶段：PAGE COPY（PAGE COPY）
这里有两个动作:
(1)开启redo archiving功能，从当前点开始存储新增的redo log，这样从当前点开始所有增量修改都不会丢失.
(2)同时上一步在page track的page被发送到目标端。确保当前点之前所做的变更一定发送到目标端
关于redo archiving，实际上这是官方早就存在的功能，主要用于官方的企业级备份工具，但这里clone利用了该特性来维持增量修改产生的redo。在开始前会做一次check point，开启一个后台线程log_archiver_thread()来做日志归档。当有新的写入时(notify_about_advanced_write_lsn)也会通知他去archive当arch_log_sys处于活跃状态时，他会控制日志写入以避免未归档的日志被覆盖(log_writer_wait_on_archiver), 注意如果log_writer等待时间过长的话，archive任务会被中断掉。
第四阶段：REDO COPY（REDO COPY）
停止Redo Archiving", 所有归档的日志被发送到目标端，这些日志包含了从page copy阶段开始到现在的所有日志，另外可能还需要记下当前的复制点，例如最后一个事务提交时的binlog位点或者gtid信息，在系统页中可以找到
第五阶段：Done（FILE SYNC、RESTART、RECOVERY）
目标端重启实例，通过crash recovery将redo log应用上去。
604
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
