Rechercher dans le manuel MySQL
18.2.1.3 User Credentials
Group Replication uses a distributed recovery process to
synchronize group members when joining them to the group.
Distributed recovery involves transferring transactions from a
donor's binary log to a joining member using a replication
channel named group_replication_recovery
. You
must therefore set up a replication user with the correct
permissions so that Group Replication can establish direct
member-to-member replication channels. If group members have
been set up to support the use of a remote cloning operation as
part of distributed recovery, which is available from MySQL
8.0.17, this replication user is also used as the clone user on
the donor , and requires the correct permissions for this role
too. For a complete description of distributed recovery, see
Section 18.4.3, “Distributed Recovery”.
The process of setting up the replication user for distributed recovery can be captured in the binary log, and then you can rely on distributed recovery to replicate the statements used to create the user. Alternatively, you can disable binary logging before creating the replication user, and then create the user manually on each member, for example if you want to avoid the changes being propagated to other server instances. If you do this, ensure you re-enable binary logging once you have configured the user.
If you have set up cloning for your replication group, the
replication user and password used by the donor for the
group_replication_recovery
replication
channel are transferred to the joining member after cloning, and
used by the joining member afterwards, so 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.
If distributed recovery connections for your group use SSL, the replication user must be created on each server before the joining member connects to the donor. For instructions to set up SSL for distributed recovery connections, see Section 18.5.2, “Group Replication Secure Socket Layer (SSL) Support”
To create the replication user for distributed recovery, follow these steps:
Start the MySQL server instance, then connect a client to it.
If you want to disable binary logging in order to create the replication user separately on each instance, do so by issuing the following statement:
Create a MySQL user with the
REPLICATION SLAVE
privilege to use for distributed recovery, and if the server is set up to support cloning, theBACKUP_ADMIN
privilege to use as the donor in a cloning operation. In this example the userrpl_user
with the passwordpassword
is shown. When configuring your servers use a suitable user name and password:If you disabled binary logging, enable it again as soon as you have created the user, by issuing the following statement:
When the user has been configured, use a
CHANGE MASTER TO
statement to configure the server to use the given credentials for state transfer by distributed recovery or a remote cloning operation. Issue the following statement, replacingrpl_user
andpassword
with the values used when creating the user:- FOR CHANNEL 'group_replication_recovery';
If these credentials are not set correctly for the
group_replication_recovery
replication channel and therpl_user
as shown, the server cannot connect to a donor to carry out state transfer and therefore cannot join the group.
Using Group Replication and the Caching SHA-2 User Credentials Plugin
By default, users created in MySQL 8 use
Section 6.4.1.3, “Caching SHA-2 Pluggable Authentication”. If
the rpl_user
you configure for
distributed recovery uses the caching SHA-2 authentication
plugin and you are not using
Section 18.5.2, “Group Replication Secure Socket Layer (SSL) Support”
for the group_replication_recovery
replication channel, RSA key-pairs are used for password
exchange, see Section 6.3.3, “Creating SSL and RSA Certificates and Keys”. You
can either copy the public key of the
rpl_user
to the joining member, or
configure the donors to provide the public key when requested.
The more secure approach is to copy the public key of the
rpl_user
to the joining member. Then you
need to configure the
group_replication_recovery_public_key_path
system variable on the joining member with the path to the
public key for the rpl_user
.
Optionally, a less secure approach is to set
group_replication_recovery_get_public_key=ON
on donors so that they provide the public key of the
rpl_user
to joining members. There is no
way to verify the identity of a server, therefore only set
group_replication_recovery_get_public_key=ON
when you are sure there is no risk of server identity being
compromised, for example by a man-in-the-middle attack.
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-user-credentials.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.