Deploying Group Replication in Single-Primary Mode system variable, it cannot join the group. These system variables are all identified in Section 18.9, “Group Replication System Variables” . 18.2.1.3 User Credentials For Distributed Recovery 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.5.3, “Distributed Recovery” . The same replication user must be used for distributed recovery on every group member. The process of creating 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. Important 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 and create a replication user that requires SSL, see Section 18.6.3, “Securing Distributed Recovery Connections” By default, users created in MySQL 8 use Section 6.4.1.2, “Caching SHA-2 Pluggable Authentication” . If the replication user for distributed recovery uses the caching SHA-2 authentication plugin, and you are  not  using SSL for distributed recovery connections, RSA key-pairs are used for password exchange. You can either copy the public key of the replication user to the joining member, or configure the donors to provide the public key when requested. For instructions to do this, see Section 18.6.3.1, “Secure User Credentials for Distributed Recovery” . To create the replication user for distributed recovery, follow these steps: 1. Start the MySQL server instance, then connect a client to it. 2. 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: 3. 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: mysql>  SET SQL_LOG_BIN=0; mysql>  CREATE USER  rpl_user @’%’ IDENTIFIED BY ’ password ’; mysql>  GRANT REPLICATION SLAVE ON *.* TO  rpl_user @’%’; mysql>  GRANT BACKUP_ADMIN ON *.* TO  rpl_user @’%’; 3707