在MySQL组复制中，一组服务器构成一个复制组。群组具有名称，该名称采用UUID的形式。该组是动态的，服务器可以随时离开（自愿或非自愿）并加入。每当服务器加入或离开时，该组都会进行自我调整。

如果服务器加入该组，它将通过从现有服务器获取丢失的状态来自动使自己处于最新状态。如果服务器离开了该组，例如已被拆除以进行维护，则其余服务器会注意到该服务器已离开并自动重新配置该组。

组复制具有组成员资格服务，该服务定义了哪些服务器处于联机状态并参与该组。联机服务器列表称为 视图。组中的每台服务器都具有一致的视图，即在给定的时间哪些成员是积极参与组的服务器。

组成员不仅必须就事务提交达成共识，而且必须就当前观点达成一致。如果现有成员同意将新服务器纳入组，则将组重新配置为将该服务器集成到其中，从而触发视图更改。如果服务器自愿离开该组，则该组将动态重新排列其配置，并触发视图更改。

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

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

为了应对这种可能性，从MySQL 5.7.22和MySQL 8.0开始，服务器在加入组时会被赋予唯一的标识符。这样，组复制就可以了解以下情况：同一台服务器的新实例（具有相同的地址，但有一个新的标识符）正试图加入该组，而旧实例仍被列为成员。新的化身被阻止加入该组，直到可以通过重新配置将旧的化身移除为止。如果 group_replication_member_expel_timeout 系统变量已设置为允许成员有更多时间在被驱逐之前返回到该组，被怀疑的成员可以重新加入，只要该成员实际上并未失败即可。如果组复制在服务器上停止并重新启动，则该成员将成为新的化身，并且在怀疑超时之前不能重新加入。