MySQL Clone Plugin: Architecture, Usage Guide, and Performance Evaluation

Oracle released MySQL 8.0.17 in July 2019, which introduced a new functional plugin called Clone. The plugin simplifies adding new Group Replication nodes and, more generally, all backup‑restore operations, reducing the required time compared to traditional methods.

Principle

The Clone plugin creates a consistent data image of a remote MySQL instance. After installing the plugin, a client can connect to an empty (recommended) Recipient instance and issue the CLONE command to obtain a consistent snapshot of the Donor instance; progress can be monitored via tables in information_schema .

Recipient = the instance that initiates the clone (usually empty). Donor = the source instance whose data is copied. The plugin copies all InnoDB data, system tables, users, and privileges because all MySQL system tables are InnoDB since 8.0.

Clone Process

Clear data on the Recipient.

Copy Donor's data files.

Copy Donor's data pages.

Copy Donor's redo log.

Synchronize Donor's data files.

Restart the Recipient.

Perform crash recovery on the Recipient.

Usage Restrictions

MySQL version must be ≥ 8.0.17.

Only InnoDB tables are supported (up to 8.0.17).

Donor’s I/O and CPU usage increase noticeably during cloning.

Typical Scenarios

The Clone plugin is ideal for creating new replicas, temporary test instances, or consistent backups of large (TB‑scale) MySQL databases, where traditional tools (xtrabackup, mysqlbackup, dump, snapshots) suffer from time or space limitations.

Operation Steps

Install the Clone Plugin

INSTALL PLUGIN CLONE SONAME "mysql_clone.so";
CREATE USER clone_user IDENTIFIED BY "clone_password";
GRANT BACKUP_ADMIN ON *.* TO clone_user;

Grant additional privileges to monitor progress:

GRANT SELECT ON performance_schema.* TO clone_user;
GRANT EXECUTE ON *.* TO clone_user;

Execute Clone on the Recipient

##登录到Recipient的mysql client端执行
SET GLOBAL clone_valid_donor_list = 'donor.host.com:3306';
##Clone 操作推荐在shell命令行下挂到后台执行
CLONE INSTANCE [email protected]:3306 IDENTIFIED BY "clone_password";

Monitor Progress

SELECT STATE, CAST(BEGIN_TIME AS DATETIME) AS "START TIME",
       CASE WHEN END_TIME IS NULL THEN
            LPAD(sys.format_time(POWER(10,12)*(UNIX_TIMESTAMP(NOW())-UNIX_TIMESTAMP(BEGIN_TIME))),10,' ')
       ELSE
            LPAD(sys.format_time(POWER(10,12)*(UNIX_TIMESTAMP(END_TIME)-UNIX_TIMESTAMP(BEGIN_TIME))),10,' ')
       END AS DURATION
FROM performance_schema.clone_status;

Performance Test

The test compared Clone, LVM snapshots, and Xtrabackup on a 1 TB dataset (4 tables × 1 B rows each) using identical MySQL configurations. Hardware included HP DL360 Gen9 servers with SSDs for data directories and SAS disks for backup storage.

Workloads simulated with sysbench ranged from no writes to standard read‑write load (16 threads, ~60 % CPU idle). Xtrabackup could not handle high‑write scenarios due to redo‑log rotation, so only low‑write cases were measured.

Clone Configuration for the Test

# Example tuning parameters
clone_autotune_concurrency = OFF
clone_buffer_size = 268435456
clone_ddl_timeout = 300
clone_enable_compression = ON
clone_max_concurrency = 24
clone_max_data_bandwidth = 0
clone_max_network_bandwidth = 0

Results

Clone completed in roughly 40 % of the time required for an LVM snapshot and 18 % of the time for Xtrabackup.

CPU and I/O read load on the Donor were the main sources of overhead; write performance impact stayed below 10 % under moderate load and rose to ~28 % under full read‑write load.

Clone cannot be used when the source instance is unavailable; traditional recovery methods are still needed for disaster scenarios.

Overall, the Clone plugin provides a significant speed advantage for creating consistent MySQL replicas or backups, especially for large datasets, provided the donor instance can tolerate the temporary resource consumption.