The MySQL Clone Plugin: Fast Provisioning for New Replicas

1. The provisioning problem on large Magento databases

A new replica initially needs a consistent, complete copy of the primary server's data before it can be kept in sync with ongoing changes through regular replication. Classically this happened via mysqldump followed by a logical import, a process that runs a full INSERT plus index maintenance for every single row and can easily take many hours on a 200 gigabyte database.

External tools like Percona's xtrabackup already solved this problem considerably faster through a physical copy of the underlying data files, but required a separate installation, their own operating system level privileges, and an additional prepare step after the actual copy. That exact gap is closed by the clone plugin, fully integrated into the server since MySQL 8.0.17.

2. What CLONE INSTANCE technically does: physical instead of logical

The key technical difference from mysqldump is that the clone plugin does not generate SQL statements and does not insert row by row, it directly copies the underlying InnoDB data files at the page level, exactly as they physically exist on the donor server's disk. Indexes do not need to be rebuilt because they are transferred in exactly the form they already have on the donor.

That makes the approach fundamentally different from a logical dump, which treats structure and data separately and effectively recreates every table, every index and every foreign key relationship on import. The physical approach is much closer to a classic filesystem snapshot, but it has the advantage over a plain snapshot of working directly over a regular network connection between two running MySQL servers, without needing operating system level access to the donor.

3. Prerequisites and installing the clone plugin

The clone plugin needs to be installed on both the donor server and the recipient server. Both instances also need a database user with the BACKUP_ADMIN privilege, introduced specifically for clone operations, and the donor needs the recipient server's network address explicitly allowed via clone_valid_donor_list.

This explicit allowlist is a deliberate security feature: without a matching entry, the donor refuses every incoming clone request, even with correct credentials. For production environments, an encrypted connection between both servers is also recommended, since potentially sensitive customer data could otherwise be transferred unencrypted across the network during the clone unless SSL is explicitly enforced.

-- Install the clone plugin on both donor and recipient
INSTALL PLUGIN clone SONAME 'mysql_clone.so';

-- Explicitly allow the recipient address on the donor
SET GLOBAL clone_valid_donor_list = 'db-replica-new.internal:3306';

-- Create a user with the privileges needed for clone operations
CREATE USER 'clone_user'@'%' IDENTIFIED BY 'a-strong-password';
GRANT BACKUP_ADMIN ON *.* TO 'clone_user'@'%';

4. The clone process step by step

The actual clone operation is started on the recipient with the CLONE INSTANCE FROM command and runs through several internal phases: first a file copy phase that transfers the raw InnoDB tablespace data, followed by a page copy phase that reapplies changes made on the donor concurrently during the transfer, and finally a redo copy phase that guarantees the last consistent state through the redo log.

Once completed successfully, the recipient server automatically restarts and comes back up with exactly the data set the donor had at the moment the clone completed. From the administrator's point of view, the entire process is a single SQL command, the server handles every detail of consistency internally.

-- Run on the empty recipient server
CLONE INSTANCE FROM 'clone_user'@'db-primary.internal':3306
  IDENTIFIED BY 'a-strong-password';

-- Watch the progress of a running clone operation
SELECT STAGE, STATE, BEGIN_TIME, END_TIME
FROM performance_schema.clone_progress;

5. Automatic replication setup after the clone

A particularly practical advantage of the clone plugin over a plain file copy: the server automatically records the exact GTID position at which the data set on the donor was consistent, in the internal mysql.clone_status table, during cloning. That position can be used directly to set up the replication connection, with no manual work to figure out a binlog file name and byte offset.

With GTID-based replication enabled, a single CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION=1 command is enough to seamlessly attach the freshly cloned recipient to the running replication chain. The server determines the correct starting position on its own, a considerable practical advantage over the classic, error-prone manual position determination in a mysqldump-based setup.

6. Speed comparison to mysqldump-based replica setup

The speed gap between a physical clone and a logical mysqldump import grows disproportionately with database size. While a mysqldump import runs a full INSERT plus index update for every row and additionally suffers from transaction log overhead on large tables, the clone plugin transfers the already fully indexed data pages directly, without processing a single row individually.

On a realistic, several hundred gigabyte Magento production database, that often means the difference in practice between a mysqldump import that runs overnight and a clone operation that finishes in one to two hours, depending on available network bandwidth. The actual duration mainly depends on network bandwidth between donor and recipient, not on the row count of the largest tables.

7. Speed comparison to xtrabackup

Compared to xtrabackup, the raw transfer mechanism is similar, both copy physical InnoDB pages instead of logical SQL statements. The practical difference lies mainly in integration: the clone plugin needs no separate installation of an external package, no own configuration file, and no additional, manually executed prepare step, which xtrabackup needs to bring the copied files into a consistent, startable state.

That prepare step is unnecessary with the clone plugin because the redo copy phase already guarantees a consistent end state during the clone itself. For teams already running xtrabackup in production and relying on its incremental backup capabilities, it remains relevant, but for the specific task of fast replica provisioning, the clone plugin is the simpler, fully server-integrated alternative.

8. Limitations: InnoDB only and matching versions

The clone plugin only copies InnoDB tables, other storage engines such as MyISAM are not transferred during a clone. For Magento shops with a clean declarative schema structure that runs on InnoDB almost exclusively, this is usually uncritical, but for older installations migrated from Magento 1 with a handful of leftover MyISAM tables, it is worth checking beforehand which tables would be affected.

Another central limitation concerns version compatibility: donor and recipient need either the exact same MySQL version or at least compatible versions within the same major release line, since the internal format of the redo log and the undo log can differ between versions. Cloning from a MySQL 8.0 instance to an older 5.7 instance is refused by the plugin outright.

9. Practical pitfalls in production use

A common pitfall is uncontrolled network bandwidth usage: a clone operation can nearly saturate the available network bandwidth between donor and recipient during the file copy phase, which can cause noticeable latency issues for regular application load on a production donor server. The system variable clone_max_data_bandwidth lets you deliberately throttle the clone operation to avoid this effect.

The recipient server also needs to be genuinely empty before cloning, the server refuses to clone into an already initialized, actively used data directory. If a clone operation fails or is interrupted, for example by a network outage, the performance_schema.clone_status and clone_progress tables show exactly which phase it failed in before a new attempt is started.

10. Summary

11. FAQ: MySQL Clone Plugin for Replica Provisioning