Deploying Group Replication in Single-Primary Mode Similar to the procedure for server s1, with the option file in place you launch the server. Then configure the distributed recovery credentials as follows. The commands are the same as used when setting up server s1 as the user is shared within the group. This member needs to have the same replication user configured in Section 18.2.1.3, “User Credentials For Distributed Recovery” . If you are relying on distributed recovery to configure the user on all members, when s2 connects to the seed s1 the replication user is replicated or cloned to s1. If you did not have binary logging enabled when you configured the user credentials on s1, and a remote cloning operation is not used for state transfer, you must create the replication user on s2. In this case, connect to s2 and issue: SET SQL_LOG_BIN=0; CREATE USER  rpl_user @’%’ IDENTIFIED BY ’ password ’; GRANT REPLICATION SLAVE ON *.* TO  rpl_user @’%’; GRANT BACKUP_ADMIN ON *.* TO  rpl_user @’%’; FLUSH PRIVILEGES; SET SQL_LOG_BIN=1; CHANGE MASTER TO MASTER_USER=’ rpl_user ’, MASTER_PASSWORD=’ password ’ \\  FOR CHANNEL ’group_replication_recovery’; Or from MySQL 8.0.23: CHANGE REPLICATION SOURCE TO SOURCE_USER=’ rpl_user ’, SOURCE_PASSWORD=’ password ’ \\  FOR CHANNEL ’group_replication_recovery’; If you are providing user credentials using a  CHANGE REPLICATION SOURCE TO  |  CHANGE MASTER TO statement, issue the following statement after that: If you are using the caching SHA-2 authentication plugin, the default in MySQL 8, see Replication User With The Caching SHA-2 Authentication Plugin. If necessary, install the Group Replication plugin, see Section 18.2.1.4, “Launching Group Replication” . Start Group Replication and s2 starts the process of joining the group. Or if you are providing user credentials for distributed recovery on the  START GROUP_REPLICATION statement (which you can from MySQL 8.0.21): Unlike the previous steps that were the same as those executed on s1, here there is a difference in that you do  not  need to bootstrap the group because the group already exists. In other words on s2  group_replication_bootstrap_group  is set to  OFF , and you do not issue  SET GLOBAL group_replication_bootstrap_group=ON;  before starting Group Replication, because the group has already been created and bootstrapped by server s1. At this point server s2 only needs to be added to the already existing group. When Group Replication starts successfully and the server joins the group it checks the  super_read_only  variable. By setting  super_read_only  to ON in the member’s configuration file, you can ensure that servers which fail when starting Group Replication for any reason do not accept transactions. If the server should join the group as a read-write instance, for example as the primary in a single-primary group or as a member of a multi-primary group, when the super_read_only  variable is set to ON then it is set to OFF upon joining the group. mysql>  START GROUP_REPLICATION; mysql>  START GROUP_REPLICATION USER=’ rpl_user ’, PASSWORD=’ password ’; Tip 3711 Tip