我们以本地clone为例，因为去除网络部分，理解起来会相对简单点。 也不会过度接触代码部分，仅仅做简单的原理性阐述

本地clone无需启动额外mysqld, 只要在实例上执行一条sql语句，指定下目标目录即可:

需要BACKUP_ADMIN权限

• 需要指定绝对路径，并且路径目录必须不存在
• 在接受机器上启动mysqld，执行上述语句连接到目标机器，就能从目标机器上clone数据到本地，注意如果没有指定data directory的话，就默认配置的目录，已有的文件会被清理掉，并在clone完成后重启
• 两个实例上都需要安装clone plugin
• 必须有相同的字符集设置

官方文档列出的一些限制：

1. ddl包括truncate table在clone期间不允许执行 //被block住
2. An instance cannot be cloned from a different MySQL server version. The donor and recipient must have the same MySQL server version.
3. The clone plugin does not support cloning of MySQL server configurations
4. 不支持clone binlog
5. The clone plugin only clones data stored in InnoDB. Other storage engine data is not cloned
6. Connecting to the donor MySQL server instance through MySQL Router is not supported.
7. Local cloning operations do not support cloning of general tablespaces that were created with an absolute path. A cloned tablespace file with the same path as the source tablespace file would cause a conflict.

主要流程包含如下几个过程： [INIT] —> [FILE COPY] —> [PAGE COPY] —> [REDO COPY] -> [Done]

INIT 阶段

FILE COPY 阶段

按照文件进行拷贝，同时开启page tracking功能，记录在拷贝过程中修改的page, 此时会设置buf_pool->track_page_lsn为当前lsn，track_page_lsn在flush page阶段用到:

PAGE COPY

这里有两个动作

• 开启redo archiving功能，从当前点开始存储新增的redo log，这样从当前点开始所有的增量修改都不会丢失
• 同时上一步在page track的page被发送到目标端。确保当前点之前所做的变更一定发送到目标端

关于redo archiving，实际上这是官方早就存在的功能，主要用于官方的企业级备份工具，但这里clone利用了该特性来维持增量修改产生的redo。 在开始前会做一次checkpoint， 开启一个后台线程log_archiver_thread()来做日志归档。当有新的写入时(notify_about_advanced_write_lsn)也会通知他去archive

当arch_log_sys处于活跃状态时，他会控制日志写入以避免未归档的日志被覆盖(log_writer_wait_on_archiver), 注意如果log_writer等待时间过长的话， archive任务会被中断掉

Redo Copy

停止Redo Archiving”, 所有归档的日志被发送到目标端，这些日志包含了从page copy阶段开始到现在的所有日志，另外可能还需要记下当前的复制点，例如最后一个事务提交时的binlog位点或者gtid信息，在系统页中可以找到

Done

参考文档

官方博客:Clone: Create MySQL instance replica

WL#9209: InnoDB: Clone local replica

WL#9682: InnoDB: Support cloning encrypted and compressed database