Several aspects of Group Replication's distributed recovery process can be configured to suit your system.
Distributed recovery requires a replication user that has the correct permissions so that Group Replication can establish direct member-to-member replication channels. The replication user must also have the correct permissions to act as the clone user on the donor for a remote cloning operation. For instructions to set up this replication user, see Section 18.104.22.168, “User Credentials”.
State transfer from the binary log is Group Replication's base mechanism for distributed recovery, and if the donors and joining members in your replication group are not set up to support cloning, this is the only available option. As state transfer from the binary log is based on classic asynchronous replication, it might take a very long time if the server joining the group does not have the group's data at all, or has data taken from a very old backup image. In this situation, it is therefore recommended that before adding a server to the group, you should set it up with the group's data by transferring a fairly recent snapshot of a server already in the group. This minimizes the time taken for distributed recovery, and reduces the impact on donor servers, since they have to retain and transfer fewer binary log files.
For state transfer from the binary log, Group Replication limits the number of attempts a joining member makes when trying to connect to a donor from the pool of donors. If the connection retry limit is reached without a successful connection, the distributed recovery procedure terminates with an error. Note that this limit specifies the total number of attempts that the joining member makes to connect to a donor. For example, if 2 group members are suitable donors, and the connection retry limit is set to 4, the joining member makes 2 attempts to connect to each of the donors before reaching the limit.
The default connection retry limit is 10. You can configure
this setting using the
system variable. The following command sets the maximum number
of attempts to connect to a donor to 5:
mysql> SET GLOBAL group_replication_recovery_retry_count= 5;
For remote cloning operations, this limit does not apply. Group Replication makes only one connection attempt to each suitable donor for cloning, before starting to attempt state transfer from the binary log.
For state transfer from the binary log, the
system variable defines how much time the distributed recovery
process should sleep between donor connection attempts. Note
that distributed recovery does not sleep after every donor
connection attempt. As the joining member is connecting to
different servers and not to the same one repeatedly, it can
assume that the problem that affects server A does not affect
server B. Distributed recovery therefore suspends only when it
has gone through all the possible donors. Once the server
joining the group has made one attempt to connect to each of
the suitable donors in the group, the distributed recovery
process sleeps for the number of seconds configured by the
system variable. For example, if 2 group members are suitable
donors, and the connection retry limit is set to 4, the
joining member makes one attempt to connect to each of the
donors, then sleeps for the connection retry interval, then
makes one further attempt to connect to each of the donors
before reaching the limit.
The default connection retry interval is 60 seconds, and you can change this value dynamically. The following command sets the distributed recovery donor connection retry interval to 120 seconds:
mysql> SET GLOBAL group_replication_recovery_reconnect_interval= 120;
For remote cloning operations, this interval does not apply. Group Replication makes only one connection attempt to each suitable donor for cloning, before starting to attempt state transfer from the binary log.
When distributed recovery has successfully completed state
transfer from the donor to the joining member, the joining
member can be marked as online in the group and ready to
participate. By default, this is done after the joining member
has received and applied all the transactions that it was
missing. Optionally, you can allow a joining member to be
marked as online when it has received and certified (that is,
completed conflict detection for) all the transactions that it
was missing, but before it has applied them. If you want to do
this, use the
system variable to specify the alternative setting
You can optionally use SSL for distributed recovery
connections between group members. SSL for distributed
recovery is configured separately from SSL for normal group
communications, which is determined by the server's SSL
settings and the
system variable. For distributed recovery connections,
dedicated Group Replication distributed recovery SSL system
variables are available to configure the use of certificates
and ciphers specifically for distributed recovery.
By default, SSL is not used for distributed recovery
connections. To activate this, set
and configure the Group Replication distributed recovery SSL
system variables as described in
Section 18.5.2, “Group Replication Secure Socket Layer (SSL) Support”.
You need a replication user that is set up to use SSL.
When distributed recovery is configured to use SSL, Group
Replication applies this setting for remote cloning
operations, as well as for state transfer from a donor's
binary log. Group Replication automatically configures the
settings for the clone SSL options
clone_ssl_key) to match your
settings for the corresponding Group Replication distributed
If you are not using SSL for distributed recovery (so
is set to
OFF), and the replication user
account for Group Replication authenticates with the
caching_sha2_password plugin (which is the
default in MySQL 8.0) or the
sha256_password plugin, RSA key-pairs are
used for password exchange. In this case, either use the
system variable to specify the RSA public key file, or use the
system variable to request the public key from the master, as
Using Group Replication and the Caching SHA-2 User Credentials Plugin.
From MySQL 8.0.18, you can optionally configure compression
for distributed recovery by the method of state transfer from
a donor's binary log. Compression can benefit distributed
recovery where network bandwidth is limited and the donor has
to transfer many transactions to the joining member. The
system variables configure permitted compression algorithms,
zstd compression level, used when
carrying out state transfer from a donor's binary log. For
more information, see
Section 4.2.6, “Connection Compression Control”.
Note that these compression settings do not apply for remote
cloning operations. When a remote cloning operation is used
for distributed recovery, the clone plugin's