Documentation Home
MySQL 8.0 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 47.2Mb
PDF (A4) - 47.3Mb
PDF (RPM) - 42.7Mb
HTML Download (TGZ) - 10.9Mb
HTML Download (Zip) - 10.9Mb
HTML Download (RPM) - 9.4Mb
Man Pages (TGZ) - 229.9Kb
Man Pages (Zip) - 335.5Kb
Info (Gzip) - 4.2Mb
Info (Zip) - 4.2Mb
Excerpts from this Manual

5.6.7.6 Cloning for Replication

The clone plugin supports replication. In addition to cloning data, a cloning operation extracts and transfers replication coordinates from the donor and applies them on 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.

Note

Group Replication members can also be configured to use the clone plugin as an alternative method of recovery, so that members automatically choose the most efficient way to retrieve group data from seed members. For more information, see Section 18.4.3.1, “Cloning for Distributed Recovery”.

Both binary log position (filename, offset) and GTID coordinates are extracted and transferred from the donor MySQL server instance.

  • Issue this query on a cloned MySQL server instance to view the binary log position that was applied:

    mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;
  • Issue this query on a cloned MySQL server instance to view the GTID of last transaction cloned to the recipient:

    mysql> SELECT @@GLOBAL.GTID_EXECUTED;

    If a recipient running with GTID_MODE=ON clones from a donor with GTID_MODE=OFF, both the GTID and binary log position replication coordinates are applied on the recipient.

The replication coordinates that are applied on the recipient permit initiating replication from the donor at a consistent position in the replication stream, assuming that the binary logs required for the recipient to catch up to the donor are not 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 be added to a group or cluster without excessive delay to avoid required binary logs being purged or the new member lagging behind significantly, requiring more recovery time.

The cloning operation does not configure or modify replication-related configuration settings on the recipient MySQL server instance.

To clone for replication, perform the following steps:

  1. Clone data from the donor MySQL server instance to the recipient.

    • If you are adding a member to a Group Replication cluster, the donor must be a member in the cluster.

    • If you are adding a slave to a MySQL replication group, the donor must be a master or slave in the replication group.

    For cloning instructions, see Section 5.6.7.3, “Cloning Remote Data”.

  2. After the cloning operation completes successfully, add the recipient MySQL server instance to the Group Replication cluster or MySQL replication group.

    The instructions that follow provide abbreviated examples for adding a recipient MySQL server instance to a Group Replication cluster, a replication group that uses GTID-based transactions as the replication data source, and a replication group that uses binary log file position based replication. Refer to the instructions that apply to your replication setup.

    • Adding to a Group Replication cluster.  To add the recipient MySQL server instance to a Group Replication cluster, configure the instance for Group Replication, and add the instance to the group, as shown in this abbreviated example:

      mysql> CHANGE MASTER TO MASTER_USER = 'user_name', MASTER_PASSWORD = 'password',
             ...
             FOR CHANNEL 'group_replication_recovery';
      mysql> START GROUP_REPLICATION;

      For detailed information about adding an instance to a Group Replication cluster, refer to Section 18.2.1.6, “Adding Instances to the Group”.

    • Adding to a replication group that uses GTID-based transactions.  To add a recipient MySQL server instance to a MySQL replication group that uses GTID-based transactions as the replication data source, configure the instance as required, and add the instance as shown in the following abbreviated example.

      The CHANGE MASTER TO statement must define the host address and port number of the donor instance, and the MASTER_AUTO_POSITION option should be enabled, as shown:

      mysql> CHANGE MASTER TO MASTER_HOST = 'donor_host_name', MASTER_PORT = donor_port_num,
             ...
             MASTER_AUTO_POSITION = 1;
      mysql> START SLAVE USER = 'user_name' PASSWORD = 'password';

      For detailed information about adding an instance to a MySQL replication group that uses GTID-based transactions as the replication data source, refer to Section 17.1.3, “Replication with Global Transaction Identifiers”.

    • Adding to a MySQL replication group that uses binary log file position.  To add a recipient MySQL server instance to a MySQL replication group that uses binary log file position based replication, configure the instance as required, and add the instance as shown in the following abbreviated example.

      Adding the recipient MySQL server instance to the group requires knowing the binary log position applied to the recipient instance.

      mysql> SELECT BINLOG_FILE, BINLOG_POSITION FROM performance_schema.clone_status;  
      mysql> CHANGE MASTER TO MASTER_HOST = 'donor_host_name', MASTER_PORT = donor_port_num,
             ...
             MASTER_LOG_FILE = 'master_log_name',
             MASTER_LOG_POS = master_log_pos;
      mysql> START SLAVE USER = 'user_name' PASSWORD = 'password';

      For detailed information about adding an instance to a MySQL replication group that uses binary log file position based replication, refer to Section 17.1.2, “Setting Up Binary Log File Position Based Replication”.