在 MySQL Group Replication 中，一组服务器组成一个复制组。该组有一个名称，采用 UUID 形式。该组是动态的，服务器可以随时加入或离开该组。组会在服务器加入或离开时自动调整自己。

如果服务器加入组，它将自动将自己更新到最新状态，从现有的服务器中获取缺失的状态。如果服务器离开组，例如它被停机维护，剩余的服务器会注意到它已经离开，并自动重新配置组。

Group Replication 有一个组成员服务，该服务定义了哪些服务器在线并参与该组。在线服务器列表称为view。每个服务器在该组中都有一个一致的视图，显示当前参与该组的服务器成员。

组成员不仅需要同意事务提交，还需要同意当前视图。如果现有成员同意让新服务器加入组，该组将被重新配置以包含该服务器，这触发了视图变化。如果服务器离开组，无论是自愿或否，组将动态地重新配置自己，并触发视图变化。

在成员自愿离开组的情况下，它首先会启动动态组重配置，期间所有成员都需要同意新的视图，不包括离开的服务器。然而，如果成员非自愿地离开组，例如因为它突然停止或网络连接中断，它不能启动重配置。在这种情况下，Group Replication的故障检测机制在短时间内识别出成员已经离开，然后提出不包括失败成员的组重配置。与自愿离开的成员一样，这种重配置需要大多数服务器在组中的同意。然而，如果组无法达成一致，例如因为它分区到这样一种情况下没有在线的多数服务器，那么系统不能动态地更改配置，并阻止出现脑裂情况。这情况需要管理员的干预。

一个成员可能会在短时间内离线，然后再次尝试加入组，前提是故障检测机制还没有检测到它的失败，也没有将其从组中删除。如果这个情况下成员参与XCom的一致性协议，它可能会导致XCom在同一个一致性回合中deliver不同的值，通过在失败前后做出不同决定。

为了防止这种可能性，MySQL Group Replication 检查情况，即新的服务器实例试图加入组，而其旧实例（具有相同的地址和端口号）仍然列为成员。新实例直到旧实例可以被重新配置移除时才会被阻止加入组。请注意，如果通过group_ replication_member_expel_timeout系统变量添加等待期限，允许成员在被驱逐前重新连接组，以便在当前实例中保持活动状态。如果成员在等待期限内重新连接组，它将可以再次成为组中的活跃成员。成员超过驱逐超时并从组中被驱逐，或者Group Replication 在服务器上停止（通过STOP GROUP_ REPLICATION语句或服务器故障），它必须重新加入组作为新实例。