Documentation Home
MySQL 8.0 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 44.6Mb
PDF (A4) - 44.7Mb
PDF (RPM) - 40.5Mb
HTML Download (TGZ) - 10.5Mb
HTML Download (Zip) - 10.5Mb
HTML Download (RPM) - 9.1Mb
Man Pages (TGZ) - 205.6Kb
Man Pages (Zip) - 308.9Kb
Info (Gzip) - 3.9Mb
Info (Zip) - 3.9Mb
Excerpts from this Manual

18.2.1.3 User Credentials

Group Replication uses the asynchronous replication protocol to achieve Section 18.10.5, “Distributed Recovery”, synchronizing group members before joining them to the group. The distributed recovery process relies on a replication channel named group_replication_recovery which is used to transfer transactions from donor members to members that join the group. Therefore you need to set up a replication user with the correct permissions so that Group Replication can establish direct member-to-member recovery replication channels.

Start the server using the options file:

mysql-8.0/bin/mysqld --defaults-file=data/s1/s1.cnf

Create a MySQL user with the REPLICATION-SLAVE privilege. This process 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 and then create the user manually on each member, for example if you want to avoid the changes being propagated to other server instances. To disable binary logging, connect to server s1 and issue the following statements:

mysql> SET SQL_LOG_BIN=0;

In the following example the user rpl_user with the password password is shown. When configuring your servers use a suitable user name and password.

mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
mysql> FLUSH PRIVILEGES;

If binary logging was disabled, enable it again once the user has been created.

mysql> SET SQL_LOG_BIN=1;

Once the user has been configured, use the CHANGE MASTER TO statement to configure the server to use the given credentials for the group_replication_recovery replication channel the next time it needs to recover its state from another member. Issue the following, replacing rpl_user and password with the values used when creating the user.

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' \\
		      FOR CHANNEL 'group_replication_recovery';

Distributed recovery is the first step taken by a server that joins the group and does not have the same set of transactions as the group members. 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 the donor members and run the distributed recovery process to gain synchrony with the other group members, and hence ultimately cannot join the group.

Similarly, if the server cannot correctly identify the other members via the server's hostname the recovery process can fail. It is recommended that operating systems running MySQL have a properly configured unique hostname, either using DNS or local settings. This hostname can be verified in the Member_host column of the performance_schema.replication_group_members table. If multiple group members externalize a default hostname set by the operating system, there is a chance of the member not resolving to the correct member address and not being able to join the group. In such a situation use report_host to configure a unique hostname to be externalized by each of the servers.

Using Group Replication and the Caching SHA-2 User Credentials Plugin

By default, users created in MySQL 8 use Section 6.5.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, “Secure Socket Layer Support (SSL)” for the group_replication_recovery replication channel, RSA key-pairs are used for password exchange, see Section 6.4.3, “Creating SSL and RSA Certificates and Keys”. You can either copy the public key of the rpl_user to the member that should recover its state from the group, 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 member that should recover the group state from the donors. Then you need to configure the group_replication_recovery_public_key_path system variable on the member joining the group 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 members when they join the group. 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.


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.