Group Replication uses the asynchronous replication protocol to
Section 17.9.5, “Distributed Recovery”,
synchronizing group members before joining them to the group.
The distributed recovery process relies on a replication channel
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:
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
channel the next time it needs to recover its state from another
member. Issue the following, replacing
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
replication channel and the
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
recovery process can fail. It is recommended that operating
systems running MySQL have a properly configured unique
hostname, either using DNS or local settings.
hostname can be verified in the
Member_host column of the
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
configure a unique
hostname to be
externalized by each of the servers.