Rechercher dans le manuel MySQL
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.
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:
Issue this query on a cloned MySQL server instance to view the GTID of last transaction cloned to the recipient:
If a recipient running with
GTID_MODE=ON
clones from a donor withGTID_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:
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”.
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:
- ...
- FOR CHANNEL 'group_replication_recovery';
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 theMASTER_AUTO_POSITION
option should be enabled, as shown:- ...
- MASTER_AUTO_POSITION = 1;
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.
- ...
- MASTER_LOG_FILE = 'master_log_name',
- MASTER_LOG_POS = master_log_pos;
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”.
Document created the 26/06/2006, last modified the 26/10/2018
Source of the printed document:https://www.gaudry.be/en/mysql-rf-clone-plugin-replication.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
References
These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.