Upon suspicion of a problem in the group, is there a special member responsible for triggering a reconfiguration? No, there is no special member in the group in charge of triggering a reconfiguration. Any member can suspect that there is a problem. All members need to (automatically) agree that a given member has failed. One member is in charge of expelling it from the group, by triggering a reconfiguration. Which member is responsible for expelling the member is not something you can control or set. Group Replication is designed to provide highly available replica sets; data and writes are duplicated on each member in the group. For scaling beyond what a single system can provide, you need an orchestration and sharding framework built around a number of Group Replication sets, where each replica set maintains and manages a given shard or partition of your total dataset. This type of setup, often called a “sharded cluster” , allows you to scale reads and writes linearly and without limit. If SELinux is enabled, which you can verify using  sestatus -v , then you need to enable the use of the Group Replication communication port. See Setting the TCP Port Context for Group Replication. If  iptables  is enabled, then you need to open up the Group Replication port for communication between the machines. To see the current rules in place on each machine, issue  iptables -L . Assuming the port configured is 33061, enable communication over the necessary port by issuing  iptables -A INPUT -p tcp --dport 33061 -j ACCEPT . The replication channels used by Group Replication behave in the same way as replication channels used in asynchronous source to replica replication, and as such rely on the relay log. In the event of a change of the  relay_log  variable, or when the option is not set and the host name changes, there is a chance of errors. See Section 17.2.4.1, “The Relay Log”  for a recovery procedure in this situation. Alternatively, another way of fixing the issue specifically in Group Replication is to issue a  STOP GROUP_REPLICATION statement and then a  START GROUP_REPLICATION  statement to restart the instance. The Group Replication plugin creates the  group_replication_applier  channel again. Group Replication uses two bind addresses in order to split network traffic between the SQL address, used by clients to communicate with the member, and the  group_replication_local_address , used internally by the group members to communicate. For example, assume a server with two network interfaces assigned to the network addresses  203.0.113.1  and  198.51.100.179 . In such a situation you could use  203.0.113.1:33061  for the internal group network address by setting group_replication_local_address=203.0.113.1:33061 . Then you could use  198.51.100.179 for  hostname  and  3306  for the  port . Client SQL applications would then connect to the member at  198.51.100.179:3306 . This enables you to configure different rules on the different networks. Similarly, the internal group communication can be separated from the network connection used for client applications, for increased security. Upon suspicion of a problem in the group, is there a special member responsible for triggering a reconfiguration? Can I use Group Replication for sharding? How do I use Group Replication with SELinux? How do I use Group Replication with iptables? How do I recover the relay log for a replication channel used by a group member? Why does Group Replication use two bind addresses? 3837