18.2.1.3 User Credentials

Inhoudsopgave

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.

Important

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:
1. mysql> SET SQL_LOG_BIN=0;
Create a MySQL user with the REPLICATION SLAVE privilege to use for distributed recovery, and if the server is set up to support cloning, the BACKUP_ADMIN privilege to use as the donor in a cloning operation. In this example the user rpl_user with the password password is shown. When configuring your servers use a suitable user name and password:
1. mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
2. mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
3. mysql> GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
4. mysql> FLUSH PRIVILEGES;
If you disabled binary logging, enable it again as soon as you have created the user, by issuing the following statement:
1. mysql> SET SQL_LOG_BIN=1;
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, replacing rpl_user and password with the values used when creating the user:
1. mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
2. FOR CHANNEL 'group_replication_recovery';
If these credentials are not set correctly for the group_replication_recovery replication channel and the rpl_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.

Zoek in de MySQL-handleiding

Nederlandse vertaling

U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.

Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.

Bij voorbaat dank.

Document heeft de 26/06/2006 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/mysql-rf-group-replication-user-credentials.html

De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.

Referenties

Manuel MySQL : https://dev.mysql.com/

Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.

Inhoudsopgave Haut