This blog post discusses the limitations of the MySQL Clone plugin.
The MySQL clone plugin significantly simplifies the process of replica provisioning. All you need to do is:
- Ensure that the source server has binary logs enabled
- Grant appropriate permissions
- Execute the CLONE INSTANCE command on the recipient
This works extremely easily when you provision a new replica that doesn’t have any data.
Due to its simplicity, you may want to use the clone plugin instead of a backup to restore a server that survives data inconsistency or corruption. E.g., after crash.
However, if you have data on your replica, you need to consider how you will recover if the CLONE INSTANCE command fails with an error.
CLONE INSTANCE command, by default, works as follows:
- Checks prerequisites on the replica
- Wipes out data directory
- Copies data from the source server to the replica
- Finalizes data on the replica
Let’s discuss these steps in detail.
Checking prerequisites on the replica
This is a safe operation that stops the clone if any of the prerequisites listed at https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-remote.html#clone-remote-prerequisites are not met. Data and user settings are left intact if failure happens at this stage.
However, not every option affecting the future clone operation could be verified. Debugging options, such as innodb_force_recovery, could cause clone operation failure at further steps, as reported in MySQL Bug 109035. Unfortunately, even if Oracle adds this option into the prerequisites check, it would not zero all risks of option incompatibility failures that could occur during the CLONE INSTANCE operation.
Wiping the data directory
By default, after prerequisites are checked, the clone plugin wipes out the content of the data directory. This leads to the situation when all subsequent failures during the CLONE INSTANCE operation will leave your server unusable.
This means that you may have to re-install the MySQL server and re-apply all clone-related settings in order to repeat the CLONE INSTANCE operation.
To avoid the negative effect of possible failures, use clause DATA DIRECTORY of the CLONE INSTANCE command. It will add an extra step to the finalization step but will save you in case of failure. Note that you must have enough disk space to store your current data on the replica together with the data copied from the source server.
Copying data from the source server to the replica
This stage is the most risky because MySQL has limited control over data transfer. If something bad happens to your network while MySQL copies data, the clone operation will be stopped with an error. You need to be prepared for this, and if you decide not to use the DATA DIRECTORY option, be ready to re-install the replica MySQL server from scratch.
Note. Some options control data retrieval in case of network failure. So, the copy operation will be retrieved if the network is recovered within clone_donor_timeout_after_network_failure minutes. However, this option does not protect you from all possible disaster scenarios.
Finalizing data on the replica
If the clone operation completes successfully, the replica is automatically restarted. Otherwise, an error is reported.
Recovering from error if data is wiped out
After the error is reported, you need to fix the error before restarting the clone operation. If data is already wiped, you should try fixing the error without restarting the replica while your privileges are still in the memory cache. If fixing the error requires a replica restart, as in the case of mistakenly setting option innodb_force_recovery, your only option is to re-initialize the MySQL instance on the replica from scratch as you would do for any new MySQL installation.
Recovering from error if you used option DATA DIRECTORY
In this case, just remove data in the directory specified by the option DATA DIRECTORY, fix the error, and repeat the CLONE INSTANCE command. In this case, you can safely restart the replica without the risk of losing your clone-related privileges and settings.
Conclusion
The MySQL clone plugin simplifies new replica provisioning but does not simplify server restore after failure unless you are ready to re-install your MySQL instance from scratch. Using the MySQL clone plugin on servers with data is not easier than using traditional backup tools, such as Percona XtraBackup.
MySQL clone plugin resources
Provisioning Replication With Clone Plugin
MySQL 8.0.17 Clone Plugin: How to Create a Slave from Scratch
The MySQL Clone Wars: Plugin vs. Percona XtraBackup
