在MySQL组复制中，一组服务器形成一个复制组。组有一个名称，其形式为 UUID。该组是动态的，服务器可以随时离开（自愿或非自愿）并加入该组。每当服务器加入或离开时，该组就会自行调整。
如果服务器加入该组，它会通过从现有服务器获取丢失的状态来自动更新自身。如果服务器离开组，例如它被停机进行维护，其余服务器会注意到它已离开并自动重新配置组。
组复制具有组成员资格服务，该服务定义哪些服务器在线并参与该组。在线服务器列表称为 视图。组中的每个服务器都有一个一致的视图，即哪些服务器是在给定时刻积极参与组的成员。
组成员不仅必须就事务提交达成一致，还必须就当前的观点达成一致。如果现有成员同意新服务器应成为该组的一部分，则该组将被重新配置以将该服务器集成到其中，从而触发视图更改。如果服务器离开组，无论是否自愿，组都会动态地重新安排其配置并触发视图更改。
在成员自愿离开组的情况下，它首先启动动态组重新配置，在此期间所有成员必须在没有离开服务器的情况下就新视图达成一致。但是，如果成员非自愿离开组，例如由于意外停止或网络连接断开，则无法启动重新配置。在这种情况下，组复制的故障检测机制会在短时间内识别出该成员已离开，并建议在没有故障成员的情况下重新配置组。与自愿离开的成员一样，重新配置需要得到组中大多数服务器的同意。但是，如果该组无法达成一致，例如因为它的分区方式导致没有大多数服务器在线，则系统无法动态更改配置，并会阻止以防止裂脑情况。这种情况需要管理员的干预。
成员可能会短时间离线，然后在故障检测机制检测到其故障之前以及在重新配置组以删除该成员之前再次尝试重新加入组。在这种情况下，重新加入的成员会忘记其先前的状态，但如果其他成员向其发送旨在用于其崩溃前状态的消息，则可能会导致包括可能的数据不一致在内的问题。如果这种情况下的成员参与 XCom 的共识协议，则可能会导致 XCom 在失败之前和之后做出不同的决策，从而为同一轮共识提供不同的值。
为了应对这种可能性，从 MySQL 5.7.22 和 MySQL 8.0 开始，组复制会检查同一服务器的新版本尝试加入组而其旧版本（具有相同地址和端口号）仍然存在的情况。列为会员。新的化身将被阻止加入该组，直到可以通过重新配置删除旧的化身。请注意，如果系统变量添加了等待期， group_replication_member_expel_timeout 以便成员在被驱逐之前有额外的时间重新连接到群组，则如果受到怀疑的成员重新连接到群组，则可以再次以当前的身份在群组中变得活跃。在怀疑结束之前。当成员超过驱逐超时并被从组中驱逐时，或者当组复制因语句STOP GROUP_REPLICATION或服务器故障而在服务器上停止时，它必须作为新的化身重新加入。
