Responses to Failure Detection and Network Partitioning rejoin procedure does not succeed or is not attempted, the expelled member then follows the exit action specified by  group_replication_exit_state_action . The waiting period before expelling a member only applies to members that have previously been active in the group. Non-members that were never active in the group do not get this waiting period and are removed after the initial detection period because they took too long to join. If  group_replication_member_expel_timeout  is set to 0, there is no waiting period, and a suspected member is liable for expulsion immediately after the 5-second detection period ends. This setting is the default up to and including MySQL 8.0.20. This is also the behavior of a group member which is at a MySQL Server version that does not support the group_replication_member_expel_timeout  system variable. From MySQL 8.0.21, the value defaults to 5, meaning that a suspected member is liable for expulsion 5 seconds after the 5- second detection period. It is not mandatory for all members of a group to have the same setting for group_replication_member_expel_timeout , but it is recommended in order to avoid unexpected expulsions. Any member can create a suspicion of any other member, including itself, so the effective expel timeout is that of the member with the lowest setting. Consider increasing the value of  group_replication_member_expel_timeout  from the default in the following scenarios: You can specify an expel timeout up to a maximum of 3600 seconds (1 hour). It is important to ensure that XCom’s message cache is sufficiently large to contain the expected volume of messages in your specified time period, plus the initial 5-second detection period, otherwise members cannot reconnect. You can adjust the cache size limit using the  group_replication_message_cache_size  system variable. For more information, see Section 18.7.5, “XCom Cache Management” . If any members in a group are currently under suspicion, the group membership cannot be reconfigured (by adding or removing members or electing a new leader). If group membership changes need to be implemented while one or more members are under suspicion, and you want the suspect members to remain in the group, take any actions required to make the members active again, if that is possible. If you cannot make the members active again and you want them to be expelled from the group, you can force the suspicions to time out immediately. Do this by changing the value of group_replication_member_expel_timeout  on any active members to a value lower than the time that has already elapsed since the suspicions were created. The suspect members then become liable for expulsion immediately. If a replication group member stops unexpectedly and is immediately restarted (for example, because it was started with  mysqld_safe ), it automatically attempts to rejoin the group if group_replication_start_on_boot=on  is set. In this situation, it is possible for the restart and rejoin attempt to take place before the member’s previous incarnation has been expelled from the group, in which case the member cannot rejoin. From MySQL 8.0.19, Group Replication automatically uses a Group Communication System (GCS) feature to retry the rejoin attempt for the member 10 times, with a 5-second interval between each retry. This should cover most cases and allow enough time 3782 •The network is slow and the default 5 or 10 seconds before expulsion is not long enough for group members to always exchange at least one message. •The network sometimes has transient outages and you want to avoid unnecessary expulsions and primary member changes at these times. •The network is not under your direct control and you want to minimize the need for operator intervention. •A temporary network outage is expected and you do not want some or all of the members to be expelled due to this. •An individual machine is experiencing a slowdown and you do not want it to be expelled from the group.