Can I deploy Group Replication across wide-area networks? Can I deploy Group Replication across wide-area networks? Yes, but the network connection between each member  must  be reliable and have suitable perfomance. Low latency, high bandwidth network connections are a requirement for optimal performance. If network bandwidth alone is an issue, then Section 18.7.3, “Message Compression”  can be used to lower the bandwidth required. However, if the network drops packets, leading to re-transmissions and higher end-to-end latency, throughput and latency are both negatively affected. When the network round-trip time (RTT) between any group members is 5 seconds or more you could encounter problems as the built-in failure detection mechanism could be incorrectly triggered. Warning Do members automatically rejoin a group in case of temporary connectivity problems? This depends on the reason for the connectivity problem. If the connectivity problem is transient and the reconnection is quick enough that the failure detector is not aware of it, then the server may not be removed from the group. If it is a "long" connectivity problem, then the failure detector eventually suspects a problem and the server is removed from the group. From MySQL 8.0, two settings are available to increase the chances of a member remaining in or rejoining a group: • group_replication_member_expel_timeout  increases the time between the creation of a suspicion (which happens after an initial 5-second detection period) and the expulsion of the member. You can set a waiting period of up to 1 hour. From MySQL 8.0.21, a waiting period of 5 seconds is set by default. • group_replication_autorejoin_tries  makes a member try to rejoin the group after an expulsion or unreachable majority timeout. The member makes the specified number of auto-rejoin attempts five minutes apart. From MySQL 8.0.21, this feature is activated by default and the member makes three auto-rejoin attempts. If a server is expelled from the group and any auto-rejoin attempts do not succeed, you need to join it back again. In other words, after a server is removed explicitly from the group you need to rejoin it manually (or have a script doing it automatically). If the member becomes silent, the other members remove it from the group configuration. In practice this may happen when the member has crashed or there is a network disconnection. The failure is detected after a given timeout elapses for a given member and a new configuration without the silent member in it is created. When is a member excluded from a group? What happens when one node is significantly lagging behind? There is no method for defining policies for when to expel members automatically from the group. You need to find out why a member is lagging behind and fix that or remove the member from the group. Otherwise, if the server is so slow that it triggers the flow control, then the entire group slows down as well. The flow control can be configured according to the your needs. 3836