在 MySQL 组复制中，一组服务器形成一个复制组。一个组有一个名称，它采用 UUID 的形式。该组是动态的，服务器可以在任何时候离开（自愿或非自愿）并加入它。无论何时服务器加入或离开，该组都会调整自身。

如果服务器加入组，它会自动从现有服务器获取缺失的状态，从而使自身更新。如果服务器离开组，例如它被关闭以进行维护，则剩余的服务器会注意到它已离开，并自动重新配置组。

组复制有一个组成员资格服务，该服务定义哪些服务器在线并参与组。在线服务器的列表称为 视图。组中的每个服务器都对哪些服务器是当前正在积极参与组的成员具有一致的视图。

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

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

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

为了抵消这种可能性，MySQL 组复制会检查相同服务器的新化身尝试加入组，而其旧化身（具有相同的地址和端口号）仍被列为成员的情况。在新化身可以被重新配置删除之前，它会被阻止加入组。请注意，如果 group_replication_member_expel_timeout 系统变量添加了等待时间以允许成员在被驱逐之前有更多时间重新连接到组，则如果成员在被怀疑超时之前重新连接到组，则被怀疑的成员可以在其当前化身下再次在组中变为活动状态。当成员超过驱逐超时并且被驱逐出组时，或者当通过 STOP GROUP_REPLICATION 语句或服务器故障在服务器上停止组复制时，它必须作为新化身重新加入。