Using MySQL 8.0 CLONE Plugin to Create Instance Replicas

In many scenarios a reliable and efficient way to clone MySQL instance data is required, especially for high‑availability setups or classic replication where a new server must be added as a slave. Manually backing up, transferring, restoring and configuring the new node involves many error‑prone steps.

The MySQL 8.0.17 CLONE plugin introduces a CLONE SQL statement that turns the source server (the "donor") into a consistent snapshot and copies all InnoDB data and metadata to the target server (the "recipient"). After the statement finishes the recipient automatically restarts with the donor’s data.

Important notes : the plugin does not clone MySQL configuration parameters, binary logs, or non‑InnoDB tables (they are created empty). It blocks concurrent DDL on the donor, and the recipient discards its existing data and binary logs before the clone.

Clone experiment : the article walks through a real‑world example. First, the donor is prepared by installing the plugin and granting BACKUP_ADMIN , SELECT ON performance_schema , and EXECUTE to a dedicated user. Then the recipient is prepared similarly, with CLONE_ADMIN granted and the donor added to clone_valid_donor_list .

Step 1 – Prepare donor :

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

Step 2 – Prepare recipient :

INSTALL PLUGIN CLONE SONAME "mysql_clone.so";
SET GLOBAL clone_valid_donor_list = "donor.host.com:3306";
CREATE USER clone_user IDENTIFIED BY "clone_password";
GRANT CLONE_ADMIN ON *.* TO clone_user;

Step 3 – Execute CLONE :

CLONE INSTANCE
  -> FROM [email protected]:3306
  -> IDENTIFIED BY "clone_password";

The command may run for several minutes depending on data size and donor load. Progress can be observed with queries against performance_schema.clone_status and performance_schema.clone_progress , which report stage, state, start time, duration, estimated size and completion percentage.

Sample progress query:

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;

Typical output shows stages such as DROP DATA, FILE COPY, PAGE COPY, REDO COPY, FILE SYNC, RESTART and RECOVERY, each moving from In Progress to Completed . After the final RESTART and RECOVERY phases the server becomes unavailable briefly while it applies redo logs and synchronises GTID.

Step 4 – Verify completion : after the CLONE command returns, the recipient restarts automatically. If the client loses the connection, it must reconnect (or rely on an auto‑reconnect mechanism) and query performance_schema.clone_status to ensure the final state is Completed with no errors. The article shows the final status output confirming a successful clone in about 17 minutes.

Once the clone finishes, the recipient is an exact InnoDB replica of the donor, ready to join a high‑availability group using GTID or binary‑log coordinates.