5.6.7.6 Cloning for Replication

The clone plugin supports replication. In addition to cloning
data, a cloning operation extracts replication coordinates from
the donor and transfers them to the recipient, which enables
using the clone plugin for provisioning Group Replication
members and replication slaves. Using the clone plugin for
provisioning is considerably faster and more efficient than
replicating a large number of transactions.

Group Replication members can also be configured to use the
clone plugin as an option for distributed recovery, in which
case joining members automatically choose the most efficient way
to retrieve group data from existing group members. For more
information, see Section 18.4.3.1, “Cloning for Distributed Recovery”.

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.

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:

mysql> SELECT @@GLOBAL.GTID_EXECUTED;

When
master_info_repository=TABLE
and
relay_log_info_repository=TABLE
are set on the recipient (which is the default in MySQL 8.0),
the slave status logs are held in tables that are copied from
the donor to the recipient during the cloning operation. The
slave status logs hold replication-related configuration
settings that can be used to resume replication correctly after
the cloning operation.

In MySQL 8.0.17 and 8.0.18, only the table
mysql.slave_master_info (the master info
log) is copied.

From MySQL 8.0.19, the tables
mysql.slave_relay_log_info (the relay log
info log) and mysql.slave_worker_info
(the slave worker log) are also copied.

For a slave in a master/slave MySQL replication topology,
first clone the data from the donor MySQL server instance to
the recipient manually. The donor must be a master or slave
in the replication topology. For cloning instructions, see
Section 5.6.7.3, “Cloning Remote Data”.

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
master/slave 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 slave already in the
topology, replication channels on the recipient that use
GTID auto-positioning (as specified by the
MASTER_AUTO_POSITION option on the
CHANGE MASTER TO
statement) can resume replication automatically after
the cloning operation when the channel is started. You
do not need to perform any manual setup if you just want
to use these same channels.

For binary log file position based replication, if the
recipient is at MySQL 8.0.17 or 8.0.18, the binary log
position from the donor is not applied on the recipient,
only recorded in the Performance Schema
clone_status table.
Replication channels on the recipient that use binary
log file position based replication must therefore be
set up manually to resume replication after the cloning
operation. Ensure that these channels are not configured
to start replication automatically at server startup, as
they will not have the binary log position and will
attempt to start replication from the beginning.

For binary log file position based replication, if the
recipient is at MySQL 8.0.19 or above, the binary log
position from the donor is applied on the recipient.
Replication channels on the recipient that use binary
log file position based replication automatically
attempt to carry out the relay log recovery process,
using the cloned relay log information, before
restarting replication. For a single-threaded slave
(slave_parallel_workers
is set to 0), relay log recovery should succeed in the
absence of any other issues, enabling the channel to
resume replication with no further setup. For a
multithreaded slave
(slave_parallel_workers
is greater than 0), relay log recovery is likely to fail
because it cannot usually be completed automatically. In
this case, an error message is issued, and you must set
the channel up manually.

If you need to set up cloned replication channels manually,
or want to use different replication channels on the
recipient, the following instructions provide a summary and
abbreviated examples for adding a recipient MySQL server
instance to a replication topology. Also refer to the
detailed instructions that apply to your replication setup.

To add a recipient MySQL server instance to a MySQL
replication topology that uses GTID-based transactions
as the replication data source, configure the instance
as required, following the instructions in
Section 17.1.3.4, “Setting Up Replication Using GTIDs”. Add
replication channels for the instance as shown in the
following abbreviated example. The
CHANGE MASTER TO
statement must define the host address and port number
of the master, and the
MASTER_AUTO_POSITION option should be
enabled, as shown:

To add a recipient MySQL server instance to a MySQL
replication topology that uses binary log file position
based replication, configure the instance as required,
following the instructions in
Section 17.1.2, “Setting Up Binary Log File Position Based Replication”. Add replication
channels for the instance as shown in the following
abbreviated example, using the binary log position that
was transferred to the recipient during the cloning
operation: