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

如果服务器加入该组，它会通过从现有服务器获取丢失的状态来自动更新自己。如果一台服务器离开该组，例如它被关闭进行维护，其余服务器会注意到它已经离开并自动重新配置该组。

Group Replication 有一个组成员服务，它定义了哪些服务器在线并参与到该组中。在线服务器列表称为 视图。组中的每个服务器都有一个一致的视图，即哪些服务器是在给定时刻积极参与组的成员。

组成员不仅必须就事务提交达成一致，还必须就当前视图达成一致。如果现有成员同意新服务器应成为该组的一部分，则该组将重新配置以将该服务器集成到其中，这会触发视图更改。如果服务器离开该组，无论是自愿还是非自愿，该组都会动态重新安排其配置并触发视图更改。

在成员自愿离开组的情况下，它首先启动动态组重新配置，在此期间所有成员必须在没有离开服务器的情况下就新视图达成一致。但是，如果一个成员非自愿地离开了组，例如因为它意外停止或网络连接断开，则它无法启动重新配置。在这种情况下，Group Replication 的故障检测机制会在短时间后识别出该成员已离开，并建议在没有故障成员的情况下重新配置该组。与自愿离开的成员一样，重新配置需要组中大多数服务器的同意。但是，如果小组无法达成一致，例如，因为它以没有大多数服务器在线的方式进行分区，系统无法动态更改配置，并阻止以防止出现裂脑情况。这种情况需要管理员干预。

成员可能会短时间脱机，然后在故障检测机制检测到其故障之前以及重新配置组以删除该成员之前再次尝试重新加入组。在这种情况下，重新加入的成员会忘记其先前的状态，但如果其他成员向其发送的消息是针对其崩溃前状态的，则可能会导致包括可能的数据不一致在内的问题。如果处于这种情况的成员参与 XCom 的共识协议，它可能会导致 XCom 通过在失败前后做出不同的决定，为同一轮共识提供不同的价值。

为了应对这种可能性，从 MySQL 5.7.22 和 MySQL 8.0 开始，Group Replication 检查同一服务器的新化身试图加入该组而其旧化身（具有相同的地址和端口号）仍然存在的情况列为会员。新的化身被阻止加入该组，直到旧的化身可以通过重新配置被删除。请注意，如果 group_replication_member_expel_timeout 系统变量允许成员在被驱逐之前有更多时间重新连接到组，如果在怀疑超时之前重新连接到组，则被怀疑的成员可以作为其当前化身再次活跃在组中。当成员超过驱逐超时并被驱逐出组时，或者当组复制因STOP GROUP_REPLICATION语句或服务器故障而在服务器上停止时，它必须作为新的化身重新加入。