MySQL Clone Plugin – Installation, Usage, Progress Monitoring, Implementation Details, Limitations, and Comparison with XtraBackup

Clone Plugin is a major feature introduced in MySQL 8.0.17. It was added mainly to improve the experience of adding new nodes to Group Replication, where data gaps are filled by Distributed Recovery.

Before MySQL 8.0.17 the only recovery method was Binlog. If the required Binlog had been purged, administrators had to fall back to full data sync with external tools (XtraBackup, mydumper, mysqldump) and then apply incremental data via Distributed Recovery. This added operational overhead compared with competitors such as PXC (which bundles XtraBackup for State Snapshot Transfer) and MongoDB (which provides native Initial Sync).

MySQL’s official response was the Clone Plugin, which leverages the existing MySQL Enterprise Backup code path.

Contents covered in this article :

Installation of Clone Plugin

Usage of Clone Plugin

How to monitor clone progress

How to build a replica from cloned data

Implementation details of Clone Plugin

Limitations of Clone Plugin

Comparison with XtraBackup

Parameter reference

1. Installation

Clone Plugin can be installed in two ways.

(1) Configuration‑file specification

[mysqld]
plugin-load-add=mysql_clone.so
clone=FORCE_PLUS_PERMANENT

The clone entry is the plugin name; the value controls its behavior. Four possible values are:

ON – enable the plugin

OFF – disable the plugin

FORCE – force enable; MySQL will not start if the plugin fails to initialize

FORCE_PLUS_PERMANENT – same as FORCE but prevents UNINSTALL PLUGIN from removing it

(2) Dynamic loading

[mysqld]
plugin-load-add=mysql_clone.so
clone=FORCE_PLUS_PERMANENT

After installation, verify success:

mysql> show plugins;
...| clone | ACTIVE | CLONE | mysql_clone.so | GPL |...

When the state shows ACTIVE , the plugin is loaded.

2. Usage

Clone Plugin supports two cloning modes: local and remote.

2.1 Local clone

Syntax:

CLONE LOCAL DATA DIRECTORY = 'clone_dir';

Example demo:

Create a clone user with backup privileges:

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

Create a writable directory for the clone:

# mkdir /data/mysql
# chown -R mysql.mysql /data/mysql

Run the clone command:

# mysql -uclone_user -pclone_pass
mysql> clone local data directory='/data/mysql/3307';

Requirements for the clone directory:

Absolute path

The parent directory must exist and be writable by MySQL

The target directory must not already exist

Inspect the cloned files (no need for a separate prepare step):

# ll /data/mysql/3307
... (list of InnoDB files) ...

Start the cloned instance:

# /usr/local/mysql/bin/mysqld --no-defaults --datadir=/data/mysql/3307 --user mysql --port 3307 &

2.2 Remote clone

Remote cloning involves a Donor (source) and a Recipient (target). The command is issued on the Recipient:

CLONE INSTANCE FROM 'user'@'host':port IDENTIFIED BY 'password' [DATA DIRECTORY = 'clone_dir'] [REQUIRE [NO] SSL];

Create clone users on both sides and install the plugin, then set the donor whitelist on the Recipient:

mysql> set global clone_valid_donor_list = '192.168.244.10:3306';

Run the remote clone:

# mysql -urecipient_user -precipient_pass
mysql> clone instance from 'donor_user'@'192.168.244.10':3306 identified by 'donor_pass';

The remote clone proceeds through the stages described in section 5.

3. Monitoring Clone Progress

Two performance‑schema tables provide status and progress:

performance_schema.clone_status – shows overall state, timestamps, source/destination, error codes, GTID and binlog positions.

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
BINLOG_FILE: mysql-bin.000009
BINLOG_POSITION: 665197555
GTID_EXECUTED: 59cd4f8f-8fa1-11ea-a0fe-000c29f66609:1-560

Key fields:

PID – processlist ID (can be killed to abort the clone)

STATE – Not Started / In Progress / Completed / Failed

BEGIN_TIME / END_TIME – start and finish timestamps

SOURCE / DESTINATION – donor address and target location

GTID_EXECUTED / BINLOG_FILE / BINLOG_POSITION – consistency coordinates for building replicas

performance_schema.clone_progress – detailed per‑stage 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             |
| ... (other stages) ...
+------+-----------+-----------+----------------------------+----------------------------+---------+-----------+-----------+-----------+------------+---------------+

Each row corresponds to a stage (DROP DATA, FILE COPY, PAGE COPY, REDO COPY, FILE SYNC, RESTART, RECOVERY) and shows its state, timing, thread count, and data transferred.

4. Building a Replica from Cloned Data

Use the GTID or binlog coordinates obtained from clone_status to configure replication.

GTID‑based replication :

CHANGE MASTER TO MASTER_HOST='master_host_name', MASTER_PORT=3306, MASTER_AUTO_POSITION=1;
START SLAVE;

Binlog‑position replication (Recipient becomes a replica of the Donor):

SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;
CHANGE MASTER TO MASTER_HOST='master_host_name', MASTER_PORT=3306,
    MASTER_LOG_FILE='master_log_name', MASTER_LOG_POS=master_log_pos;
START SLAVE;

When the Donor itself is a replica, use mysql.slave_relay_log_info to obtain the master’s coordinates.

It is recommended to start the instance with --skip-slave-start to avoid automatic START SLAVE after startup.

5. Implementation Details

The clone operation consists of five phases:

[INIT] → [FILE COPY] → [PAGE COPY] → [REDO COPY] → [Done]

INIT : create a clone object.

FILE COPY : copy all data files while recording a start LSN (the current checkpoint) and enabling page‑tracking.

PAGE COPY : copy pages modified between the start LSN and the end‑of‑file LSN, sorting them to reduce random I/O, and enable redo archiving.

REDO COPY : copy redo logs generated after the file‑copy phase up to the final consistency LSN.

Done : call snapshot_end() to destroy the clone object.

6. Limitations

DDL statements are prohibited during cloning; they block the clone and vice‑versa.

Clone Plugin does not copy Donor configuration parameters or binary logs.

Only InnoDB tables are fully cloned; other storage engines are copied as table definitions only.

Tables that use DATA DIRECTORY with absolute paths must have those paths present and writable on the Recipient.

MySQL Router cannot be used to connect to the Donor.

The donor port for CLONE INSTANCE cannot be an X Protocol port.

Version, OS/architecture, character set, and innodb_page_size must match between Donor and Recipient.

Only one clone operation can run per instance (as of 8.0.20).

7. Comparison with XtraBackup

Both perform FILE COPY and REDO COPY; Clone Plugin adds a PAGE COPY stage, resulting in faster recovery.

XtraBackup lacks redo‑archiving, so redo logs may be overwritten before being backed up.

When using GTID, no extra SET GLOBAL gtid_purged is required after cloning.

8. Parameter Reference

clone_autotune_concurrency – ON/OFF, controls whether the number of clone threads is auto‑tuned (default ON, max controlled by clone_max_concurrency ).

clone_buffer_size – size of the local buffer for local clone (default 4 MiB).

clone_ddl_timeout – max wait time (seconds) for acquiring the backup lock when DDL is running (default 300).

clone_enable_compression – enable compression for remote clone data transfer.

clone_max_data_bandwidth – per‑thread data copy limit (MiB/s) for remote clone.

clone_max_network_bandwidth – per‑thread network transfer limit (MiB/s) for remote clone.

clone_valid_donor_list – whitelist of allowed donor instances.

clone_ssl_ca / clone_ssl_cert / clone_ssl_key – SSL configuration for secure remote cloning.

9. References

InnoDB: Clone local replica – https://dev.mysql.com/worklog/task/?id=9209

InnoDB: Clone remote replica – https://dev.mysql.com/worklog/task/?id=9210

InnoDB: Clone Replication Coordinates – https://dev.mysql.com/worklog/task/?id=9211

InnoDB: Clone Remote provisioning – https://dev.mysql.com/worklog/task/?id=11636

MySQL/InnoDB data clone plugin analysis – https://zhuanlan.zhihu.com/p/79328512