The Clone Plugin During the cloning operation, both the binary log position (filename, offset) and the  gtid_executed GTID set are extracted and transferred from the donor MySQL server instance to the recipient. This data permits initiating replication at a consistent position in the replication stream. The binary logs and relay logs, which are held in files, are not copied from the donor to the recipient. To initiate replication, the binary logs required for the recipient to catch up to the donor must not be purged between the time that the data is cloned and the time that replication is started. If the required binary logs are not available, a replication handshake error is reported. A cloned instance should therefore be added to a replication group without excessive delay to avoid required binary logs being purged or the new member lagging behind significantly, requiring more recovery time. mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status; mysql> SELECT @@GLOBAL.GTID_EXECUTED; By default in MySQL 8.0, the replication metadata repositories are held in tables that are copied from the donor to the recipient during the cloning operation. The replication metadata repositories hold replication- related configuration settings that can be used to resume replication correctly after the cloning operation. •Issue this query on a cloned MySQL server instance to check the binary log position that was transferred to the recipient: •Issue this query on a cloned MySQL server instance to check the  gtid_executed  GTID set that was transferred to the recipient: •In MySQL 8.0.17 and 8.0.18, only the table  mysql.slave_master_info  (the connection metadata repository) is copied. •From MySQL 8.0.19, the tables  mysql.slave_relay_log_info  (the applier metadata repository) and  mysql.slave_worker_info  (the applier worker metadata repository) are also copied. 1. For a new group member for Group Replication, first configure the MySQL Server instance for Group Replication, following the instructions in Section 18.2.1.6, “Adding Instances to the Group” . Also set up the prerequisites for cloning described in Section 18.5.3.2, “Cloning for Distributed Recovery” . When you issue  START GROUP_REPLICATION  on the joining member, the cloning operation is managed automatically by Group Replication, so you do not need to carry out the operation manually, and you do not need to perform any further setup steps on the joining member. 2. For a replica in a source/replica MySQL replication topology, first clone the data from the donor MySQL server instance to the recipient manually. The donor must be a source or replica in the replication topology. For cloning instructions, see Section 5.6.7.3, “Cloning Remote Data” . 3. After the cloning operation completes successfully, if you want to use the same replication channels on the recipient MySQL server instance that were present on the donor, verify which of them can resume replication automatically in the source/replica MySQL replication topology, and which need to be set up manually. •For GTID-based replication, if the recipient is configured with  gtid_mode=ON  and has cloned from a donor with  gtid_mode=ON ,  ON_PERMISSIVE , or  OFF_PERMISSIVE , the  gtid_executed  GTID set from the donor is applied on the recipient. If the recipient is cloned from a replica already in the topology, replication channels on the recipient that use GTID auto-positioning can resume replication For a list of what is included in each table, see Section 17.2.4.2, “Replication Metadata Repositories” . Note that if the settings  master_info_repository=FILE  and  relay_log_info_repository=FILE  are used on the server (which is not the default in MySQL 8.0 and is deprecated), the replication metadata repositories are not cloned; they are only cloned if  TABLE  is set. To clone for replication, perform the following steps: 1120