Rechercher dans le manuel MySQL
18.4.3.1 Cloning for Distributed Recovery
MySQL Server's clone plugin is available from MySQL 8.0.17. If you want to use remote cloning operations for distributed recovery in a group, you must set up existing members and joining members beforehand to support this function. If you do not want to use this function in a group, do not set it up, in which case Group Replication only uses state transfer from the binary log.
To use cloning, at least one existing group member and the
joining member must be set up beforehand to support remote
cloning operations. As a minimum, you must install the clone
plugin on the donor and joining member, grant the
BACKUP_ADMIN
permission to the
replication user for distributed recovery, and set the
group_replication_clone_threshold
system variable to an appropriate level. To ensure the maximum
availability of donors, it is advisable to set up all current
and future group members to support remote cloning operations.
Be aware that a remote cloning operation removes user-created tablespaces and data from the joining member before transferring the data from the donor. If the operation is stopped while in progress, the joining member might be left with partial data or no data. This can be repaired by retrying the remote cloning operation, which Group Replication does automatically.
18.4.3.1.1 Prerequisites for Cloning
For full instructions to set up and configure the clone plugin, see Section 5.6.7, “The Clone Plugin” . Detailed prerequisites for a remote cloning operation are covered in Section 5.6.7.3, “Cloning Remote Data” . For Group Replication, note the following key points and differences:
The donor (an existing group member) and the recipient (the joining member) must have the clone plugin installed and active. For instructions to do this, see Section 5.6.7.1, “Installing the Clone Plugin” .
The donor and the recipient must run on the same operating system, and must have the same MySQL Server version (which must be MySQL 8.0.17 or above to support the clone plugin). Cloning is therefore not suitable for groups where members run different MySQL Server versions.
If distributed recovery is configured to use SSL (
group_replication_recovery_use_ssl=ON
), Group Replication applies this setting for remote cloning operations. Group Replication automatically configures the settings for the clone SSL options (clone_ssl_ca
,clone_ssl_cert
, andclone_ssl_key
) to match your settings for the corresponding Group Replication distributed recovery options (group_replication_recovery_ssl_ca
,group_replication_recovery_ssl_cert
, andgroup_replication_recovery_ssl_key
).You do not need to set up a list of valid donors in the
clone_valid_donor_list
system variable for the purpose of joining a replication group. Group Replication configures this setting automatically for you after it selects a donor from the existing group members. Note that remote cloning operations use the server's SQL protocol hostname and port.The clone plugin has a number of system variables to manage the network load and performance impact of the remote cloning operation. Group Replication does not configure these settings, so you can review them and set them if you want to, or allow them to default. Note that when a remote cloning operation is used for distributed recovery, the clone plugin's
clone_enable_compression
setting applies to the operation, rather than the Group Replication compression setting.To invoke the remote cloning operation on the recipient, Group Replication uses the internal
mysql.session
user, which already has theCLONE_ADMIN
privilege, so you do not need to set this up.As the clone user on the donor for the remote cloning operation, Group Replication uses the replication user that you set up for distributed recovery (which is covered in Section 18.2.1.3, “User Credentials”). You must therefore give the
BACKUP_ADMIN
privilege to this replication user on all group members that support cloning. Also give the privilege to the replication user on joining members when you are configuring them for Group Replication, because they can act as donors after they join the group. To give this privilege to the replication user on existing members, you can issue this statement on each group member individually with binary logging disabled, or on one group member with binary logging enabled:
When group members have been set up to support cloning, the
group_replication_clone_threshold
system variable specifies a threshold, expressed as a number
of transactions, for the use of a remote cloning operation in
distributed recovery. If the gap between the transactions on
the donor and the transactions on the joining member is larger
than this number, a remote cloning operation is used for state
transfer to the joining member when this is technically
possible. Group Replication calculates whether the threshold
has been exceeded based on the
gtid_executed
sets of the
existing group members. Using a remote cloning operation in
the event of a large transaction gap lets you add new members
to the group without transferring the group's data to the
server manually beforehand, and also enables a member that is
very out of date to catch up more efficiently.
The default setting for the
group_replication_clone_threshold
Group Replication system variable is extremely high (the
maximum permitted sequence number for a transaction in a
GTID), so it effectively deactivates cloning wherever state
transfer from the binary log is possible. To enable Group
Replication to select a remote cloning operation for state
transfer where this is more appropriate, set the system
variable to specify a number of transactions as the
transaction gap above which you want cloning to take place.
Do not use a low setting for
group_replication_clone_threshold
in an active group. If a number of transactions above the
threshold takes place in the group while the remote cloning
operation is in progress, the joining member triggers a
remote cloning operation again after restarting, and could
continue this indefinitely. To avoid this situation, ensure
that you set the threshold to a number higher than the
number of transactions that you would expect to occur in the
group during the time taken for the remote cloning
operation.
Group Replication attempts to execute a remote cloning
operation regardless of your threshold when state transfer
from a donor's binary log is impossible, for example because
the transactions needed by the joining member are not
available in the binary log on any existing group member.
Group Replication identifies this based on the
gtid_purged
sets of the
existing group members. You cannot use the
group_replication_clone_threshold
system variable to deactivate cloning when the required
transactions are not available in any member's binary log
files, because in that situation cloning is the only
alternative to transferring data to the joining member
manually.
When group members and joining members are set up for cloning, Group Replication manages remote cloning operations for you. A remote cloning operation might take some time to complete, depending on the size of the data. See Section 5.6.7.9, “Monitoring Cloning Operations” for information on monitoring the process.
When state transfer is complete, Group Replication restarts
the joining member to complete the process. If
group_replication_start_on_boot=OFF
is set on the joining member, you must issue
START GROUP_REPLICATION
manually again following this restart. If
group_replication_start_on_boot=ON
and other settings required to start Group Replication were
set in a configuration file or using a SET
PERSIST
statement, you do not need to intervene
and the process continues automatically to bring the joining
member online.
A remote cloning operation clones settings that are persisted
in tables from the donor to the recipient, as well as the
data. Group Replication manages the settings that relate
specifically to Group Replication channels. The credentials
used by the donor for the
group_replication_recovery
replication
channel (the replication user and password) are transferred to
and used by the joining member after cloning, and they must be
valid there. All group members that received state transfer by
a remote cloning operation therefore use the same replication
user and password for distributed recovery. However, Group
Replication preserves the channel settings that relate to the
use of SSL, so these are unique to the individual member.
Group Replication member settings that are persisted in
configuration files, such as the group replication local
address, are not cloned and are not changed on the joining
member.
Traduction non disponible
Le manuel MySQL n'est pas encore traduit en français sur l'infobrol. Seule la version anglaise est disponible pour l'instant.
Document créé le 26/06/2006, dernière modification le 26/10/2018
Source du document imprimé : https://www.gaudry.be/mysql-rf-group-replication-cloning.html
L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.
Références
Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.