Why MySQL Clone Plugin Outperforms Xtrabackup

​Introduction​
This article provides an initial introduction to the principles of the MySQL Clone Plugin and its differences and similarities with Xtrabackup, as well as the overall implementation framework. Authored by Dai Junxian (Xiaoguang), a former senior database system engineer at NetEase Games' Billing Group and now a database operations expert at Tianyi Cloud.

​Xtrabackup's Limitations​
During the Xtrabackup process, the most significant issue is the inability to keep up with the speed of Redo Log generation on the production server. Since Redo Logs are reused, if Xtrabackup fails to copy the old Redo Logs before they are overwritten by new ones, data consistency during the backup process cannot be guaranteed.

‍

​Basic Principles of Clone Implementation​
The Clone Plugin addresses this issue through a five-step process:

1. ​INIT: The clone object is initialized with a locator.
2. ​FILE COPY: The state changes from INIT to "FILE COPY" when the snapshot_copy interface is called. Page Tracking starts at the "CLONE START LSN" to monitor InnoDB PAGE changes.
3. ​PAGE COPY: After all files are copied, Redo Archiving starts at the "CLONE FILE END LSN", and Page Tracking stops. Modified pages identified by Page IDs between "CLONE START LSN" and "CLONE FILE END LSN" are read from the buffer pool and sent.
4. ​REDO COPY: After all modified pages are sent, Redo Archiving stops at the "CLONE LSN". Redo Logs from archived files are sent to the target.
5. ​Done: The clone object remains in this state until destroyed by the snapshot_end() call.

​Key Aspects:​​

• ​FILE COPY: Similar to Xtrabackup, it physically copies all InnoDB tablespace files and starts Page Tracking.
• ​PAGE COPY: A unique phase in Clone Plugin, involving Redo Archiving and sending dirty pages from the buffer pool.
• ​REDO COPY: Involves capturing replication coordinates and sending archived Redo Logs.

‍

​Code Structure and Call Logic​
The implementation is divided into three parts:

• ​SQL/Server Layer: Adds support for Clone syntax and handles SQL commands.
• ​Plugin Layer: Includes specific Clone operations, system-level functions, and client-server interfaces.

• ‍
• ​InnoDB Engine Layer: Implements clone tasks, runtime operations, and data copy methods.

‍

​Page Archiving System​
Page Archiving, a new feature in Clone Plugin, reduces the amount of Redo Log copying by tracking and collecting dirty pages during the tablespace copy process.

​Summary​
The Clone Plugin offers a more convenient method for data cloning compared to Xtrabackup, with less Redo Log copying and fewer failure risks. However, high system load during cloning may impact performance.