In this post, we will discuss a new feature – the MySQL 8.0.17 clone plugin. Here I will demonstrate how easy it is to use to create the “classic” replication, building the standby replica from scratch.
The clone plugin permits cloning data locally or from a remote MySQL server instance. The cloned data is a physical snapshot of data stored in InnoDB, and this means, for example, that the data can be used to create a standby replica.
Let’s go to the hands-on and see how it works.
Installation & validation process of the MySQL 8.0.17 clone plugin
Installation is very easy and it works in the same as installing other plugins. Below is the command line to install the clone plugin:
1 2 | master [localhost:45008] {msandbox} ((none)) > INSTALL PLUGIN clone SONAME 'mysql_clone.so'; Query OK, 0 rows affected (0.00 sec) |
And how to check if the clone plugin is active:
1 2 3 4 5 6 7 8 | master [localhost:45008] {msandbox} ((none)) > SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'clone'; +-------------+---------------+ | PLUGIN_NAME | PLUGIN_STATUS | +-------------+---------------+ | clone | ACTIVE | +-------------+---------------+ 1 row in set (0.00 sec) |
Note that these steps need to be executed on the Donor (aka master) and on the Recipient (aka slave if the clone is being used to create a replica).
After executing the installation, the plugin will be loaded automatically across restarts, so you don’t need to worry about this anymore.
Next, we will create the user with the necessary privilege on the Donor, so we can connect to the instance remotely to clone it.
1 2 3 4 5 | master [localhost:45008] {msandbox} ((none)) > create user clone_user@'%' identified by 'sekret'; Query OK, 0 rows affected (0.01 sec) master [localhost:45008] {msandbox} ((none)) > GRANT BACKUP_ADMIN ON *.* TO 'clone_user'@'%'; Query OK, 0 rows affected (0.00 sec) |
As a security measure, I recommend replacing the % for the IP/hostname or network mask of the Recipient so the connections will be accepted only by the future replica server. Now, on the Recipient server, the clone user requires the CLONE_ADMIN privilege for replacing recipient data, blocking DDL during the cloning operation and automatically restarting the server.
1 2 3 4 5 | slave1 [localhost:45009] {msandbox} ((none)) > create user clone_user@'localhost' identified by 'sekret'; Query OK, 0 rows affected (0.01 sec) slave1 [localhost:45009] {msandbox} ((none)) > GRANT CLONE_ADMIN ON *.* TO 'clone_user'@'localhost'; Query OK, 0 rows affected (0.00 sec) |
Next, with the plugin installed and validated, and users created on both Donor and Recipient servers, let’s proceed to the cloning process.
Cloning process
As mentioned, the cloning process can be executed locally or remotely. Also, it supports replication, which means that the cloning operation extracts and transfers replication coordinates from the donor and applies them on the recipient. It can be used for GTID or non-GTID replication.
So, to begin the cloning process, first, let’s make sure that there’s a valid donor. This is controlled by clone_valid_donor_list parameter. As it is a dynamic parameter, you can change it while the server is running. Using the show variables command will show if the parameter has a valid donor:
1 2 3 4 5 6 7 | slave1 [localhost:45009] {msandbox} ((none)) > SHOW VARIABLES LIKE 'clone_valid_donor_list'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | clone_valid_donor_list | | +------------------------+-------+ 1 row in set (0.01 sec) |
In our case, we need to set it. So let’s change it:
1 2 | slave1 [localhost:45009] {msandbox} ((none)) > set global clone_valid_donor_list = '127.0.0.1:45008'; Query OK, 0 rows affected (0.00 sec) |
The next step is not mandatory, but using the default log_error_verbosity the error log does not display much information about the cloning progress. So, for this example, I will adjust the verbosity to a higher level (on the Donor and the Recipient):
1 2 | mysql > set global log_error_verbosity=3; Query OK, 0 rows affected (0.00 sec) |
Now, let’s start the cloning process on the Recipient:
1 2 | slave1 [localhost:45009] {msandbox} ((none)) > CLONE INSTANCE FROM clone_user@127.0.0.1:45008 identified by 'sekret'; Query OK, 0 rows affected (38.58 sec) |
It is possible to observe the cloning progress in the error log of both servers. Below is the output of the Donor:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | 2019-07-31T12:48:48.558231Z 47 [Note] [MY-013273] [Clone] Plugin Clone reported: 'Server: Acquired backup lock.' 2019-07-31T12:48:48.558307Z 47 [Note] [MY-013457] [InnoDB] Clone Begin Master Task by clone_user@localhost 2019-07-31T12:48:48.876138Z 47 [Note] [MY-013273] [Clone] Plugin Clone reported: 'Server: COM_INIT: Storage Initialize.' 2019-07-31T12:48:48.876184Z 47 [Note] [MY-013273] [Clone] Plugin Clone reported: 'Server: COM_RES_COMPLETE.' 2019-07-31T12:48:53.996976Z 48 [Note] [MY-013458] [InnoDB] Clone set state change ACK: 1 2019-07-31T12:48:53.997046Z 48 [Note] [MY-013273] [Clone] Plugin Clone reported: 'Server: COM_ACK: Storage Ack.' 2019-07-31T12:48:53.997148Z 48 [Note] [MY-013273] [Clone] Plugin Clone reported: 'Server: COM_RES_COMPLETE.' 2019-07-31T12:48:54.096766Z 47 [Note] [MY-013458] [InnoDB] Clone Master received state change ACK 2019-07-31T12:48:54.096847Z 47 [Note] [MY-013458] [InnoDB] Clone State Change : Number of tasks = 1 2019-07-31T12:48:54.096873Z 47 [Note] [MY-013458] [InnoDB] Clone State BEGIN FILE COPY ... 2019-07-31T12:49:33.939968Z 47 [Note] [MY-013457] [InnoDB] Clone End Master Task ID: 0 Passed, code: 0: 2019-07-31T12:49:33.940016Z 47 [Note] [MY-013273] [Clone] Plugin Clone reported: 'Server: COM_EXIT: Storage End.' 2019-07-31T12:49:33.940115Z 47 [Note] [MY-013273] [Clone] Plugin Clone reported: 'Server: COM_RES_COMPLETE.' 2019-07-31T12:49:33.940150Z 47 [Note] [MY-013273] [Clone] Plugin Clone reported: 'Server: Exiting clone protocol.' |
And the Recipient:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | 2019-07-31T12:48:48.521515Z 8 [Note] [MY-013272] [Clone] Plugin Clone reported: 'Client: Task Connect.' 2019-07-31T12:48:48.557855Z 8 [Note] [MY-013272] [Clone] Plugin Clone reported: 'Client: Master ACK Connect.' 2019-07-31T12:48:48.557923Z 8 [Note] [MY-013457] [InnoDB] Clone Apply Begin Master Version Check 2019-07-31T12:48:48.558474Z 8 [Note] [MY-013457] [InnoDB] Clone Apply Version End Master Task ID: 0 Passed, code: 0: 2019-07-31T12:48:48.558507Z 8 [Note] [MY-013457] [InnoDB] Clone Apply Begin Master Task 2019-07-31T12:48:48.558749Z 8 [Warning] [MY-013460] [InnoDB] Clone removing all user data for provisioning: Started 2019-07-31T12:48:48.558769Z 8 [Note] [MY-011977] [InnoDB] Clone Drop all user data 2019-07-31T12:48:48.863134Z 8 [Note] [MY-011977] [InnoDB] Clone: Fix Object count: 371 task: 0 2019-07-31T12:48:53.829493Z 8 [Note] [MY-011977] [InnoDB] Clone Drop User schemas 2019-07-31T12:48:53.829948Z 8 [Note] [MY-011977] [InnoDB] Clone: Fix Object count: 5 task: 0 2019-07-31T12:48:53.838939Z 8 [Note] [MY-011977] [InnoDB] Clone Drop User tablespaces 2019-07-31T12:48:53.839800Z 8 [Note] [MY-011977] [InnoDB] Clone: Fix Object count: 6 task: 0 2019-07-31T12:48:53.910728Z 8 [Note] [MY-011977] [InnoDB] Clone Drop: finished successfully ... 2019-07-31T12:49:33.836509Z 8 [Note] [MY-013272] [Clone] Plugin Clone reported: 'Client: Command COM_EXECUTE.' 2019-07-31T12:49:33.836998Z 8 [Note] [MY-013272] [Clone] Plugin Clone reported: 'Client: Master ACK COM_EXIT.' 2019-07-31T12:49:33.839498Z 8 [Note] [MY-013272] [Clone] Plugin Clone reported: 'Client: Master ACK Disconnect : abort: false.' 2019-07-31T12:49:33.851403Z 0 [Note] [MY-013272] [Clone] Plugin Clone reported: 'Client: Command COM_EXECUTE.' 2019-07-31T12:49:33.851796Z 0 [Note] [MY-013272] [Clone] Plugin Clone reported: 'Client: Task COM_EXIT.' 2019-07-31T12:49:33.852398Z 0 [Note] [MY-013272] [Clone] Plugin Clone reported: 'Client: Task Disconnect : abort: false.' 2019-07-31T12:49:33.852472Z 0 [Note] [MY-013457] [InnoDB] Clone Apply End Task ID: 1 Passed, code: 0: 2019-07-31T12:49:33.940156Z 8 [Note] [MY-013272] [Clone] Plugin Clone reported: 'Client: Task COM_EXIT.' 2019-07-31T12:49:33.940810Z 8 [Note] [MY-013272] [Clone] Plugin Clone reported: 'Client: Task Disconnect : abort: false.' 2019-07-31T12:49:33.944244Z 8 [Note] [MY-013457] [InnoDB] Clone Apply End Master Task ID: 0 Passed, code: 0: |
Note that the MySQL server on the Recipient will be restarted after the cloning process finishes. After this, the database is ready to be accessed and the final step is setting up the replica.
The replica process
Both binary log position (filename, offset) and GTID coordinates are extracted and transferred from the donor MySQL server instance.
The queries below can be executed on the cloned MySQL server instance to view the binary log position or the GTID of the last transaction that was applied:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | # Binary log position slave1 [localhost:45009] {msandbox} ((none)) > SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status; +------------------+-----------------+ | BINLOG_FILE | BINLOG_POSITION | +------------------+-----------------+ | mysql-bin.000001 | 437242601 | +------------------+-----------------+ 1 row in set (0.01 sec) # GTID slave1 [localhost:45009] {msandbox} ((none)) > SELECT @@GLOBAL.GTID_EXECUTED; +----------------------------------------------+ | @@GLOBAL.GTID_EXECUTED | +----------------------------------------------+ | 00045008-1111-1111-1111-111111111111:1-32968 | +----------------------------------------------+ 1 row in set (0.00 sec) |
With the information in hand, we need to execute the CHANGE MASTER command accordingly:
1 2 3 4 5 | slave1 [localhost:45009] {msandbox} ((none)) > CHANGE MASTER TO MASTER_HOST = '127.0.0.1', MASTER_PORT = 45008,MASTER_USER='root',MASTER_PASSWORD='msandbox',MASTER_AUTO_POSITION = 1; Query OK, 0 rows affected, 2 warnings (0.02 sec) slave1 [localhost:45009] {msandbox} ((none)) > start slave; Query OK, 0 rows affected (0.00 sec) |
Limitations
The clone plugin has some limitations and they are described here. In my opinion, two major limitations will be faced by the community. First, it is the ability to clone only InnoDB tables. This means that MyISAM and CSV tables stored in any schema including the sys schema will be cloned as empty tables.
The other limitation is regarding DDL, including TRUNCATE TABLE, which is not permitted during a cloning operation. Concurrent DML, however, is permitted. If a DDL is running, then the clone operation will wait for the lock:
1 2 3 4 5 | +----+-----------------+-----------------+------+------------------+-------+---------------------------------------------------------------+----------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+-----------------+------+------------------+-------+---------------------------------------------------------------+----------------------------------+ | 63 | clone_user | localhost:34402 | NULL | clone | 3 | Waiting for backup lock | NULL | +----+-----------------+-----------------+------+------------------+-------+---------------------------------------------------------------+----------------------------------+ |
Otherwise, if the clone operation is running, the DDL will wait for the lock:
1 2 3 4 5 6 7 8 | +----+-----------------+-----------------+------+------------------+-------+---------------------------------------------------------------+----------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+-----------------+------+------------------+-------+---------------------------------------------------------------+----------------------------------+ | 52 | msandbox | localhost | test | Query | 5 | Waiting for backup lock | alter table joinit engine=innodb | | 60 | clone_user | localhost:34280 | NULL | clone | 15 | Receiving from client | NULL | | 61 | clone_user | localhost:34282 | NULL | clone | 15 | Receiving from client | NULL | | 62 | clone_user | localhost:34284 | NULL | clone | 6 | Receiving from client | NULL | +----+-----------------+-----------------+------+------------------+-------+---------------------------------------------------------------+----------------------------------+ |
Conclusion
Creating replicas has become much easier with the help of the MySQL 8.0.17 clone plugin. This feature can be used using SSL connections and with encrypted data as well. At the moment of publication of this blog post, the clone plugin can be used to set up not only asynchronous replicas but provisioning Group Replication members too. Personally, I believe that in the near future this feature will also be used for Galera clusters. This is my two cents for what the future holds.
Useful Resources
Finally, you can reach us through the social networks, our forum or access our material using the links presented below:
- Blog: https://www.percona.com/blog/
- Solution Briefs: https://www.percona.com/resources/solution-brief
- White Papers: https://www.percona.com/resources/white-papers
- Ebooks: https://www.percona.com/resources/ebooks
- Technical Presentations archive: https://www.percona.com/resources/technical-presentations
- Videos/Recorded Webinars: https://www.percona.com/resources/videos
- Forum: https://www.percona.com/forums/
- Knowledge Base (Percona Subscriber exclusive content): https://customers.percona.com
Comments (8)
I have read you article ….very informative… Thank you…
I think Galera cluster with mariadb Right? It is not related to MySQL.
Hi Adam,
Galera cluster is open-source and it is not only for MariaDB. For example, Percona XtraDB cluster(which is open-source too) is based on MySQL and Galera too. If you want to check more:
https://www.percona.com/software/mysql-database/percona-xtradb-cluster
This is incredible. Any plan to support RocksDB?
Hi Bruno,
We are constantly developing Percona Server versions. Currently, the RocksDB engine is supported on Percona Server versions. Because MySQL 8.0.17(which contains the clone plugin) was released only a few days ago (10 days from the time of this post), we still don’t have the roadmap for this feature. You can check our blogs or sign the newsletter to follow our releases.
Maybe it’s time to promote MySQL InnoDB Cluster (Group Replication) with Percona Server too 😉
One of my colleagues published something about it a while:
https://www.percona.com/blog/2018/11/05/how-to-quickly-add-a-node-to-an-innodb-cluster-or-group-replication/
Surely it is in the radar the GR and I saw great improvements on it recently. Maybe it is time to revisit it 😀
A couple thoughts as we start testing it out:
* Compression does not seem to be used during a clone which may take longer than say PXB
* Same for multiple file copy threads, compared to xbstream
* Master disk usage may increase in the #ib_archive directory
Pretty exciting to see, also cool you can specify DATA DIRECTORY for remote backups
tag: load data from master
Oh I had missed the compression and threads options:
https://dev.mysql.com/doc/refman/8.0/en/clone-plugin-options-variables.html