1组复制背景
MySQL组复制（MySQL Group Replication）是一种用于创建高可用性、自动故障恢复和数据复制的技术。在构建冗余和容错系统时，需要解决多台服务器之间的协调、一致性和分布式系统问题。MySQL组复制通过引入分布式状态机复制以及强大的协调性来应对这些挑战。
主要概念和特点包括：
- 分布式状态机复制： MySQL组复制使多台服务器能够作为一个分布式状态机运行，确保它们就数据库状态转换达成一致，从而实现数据的复制和同步。
- 自动协调性： 一旦服务器加入同一个组，它们可以自动协调并维护组的一致性。可以选择单主模式或多主模式，其中服务器在接受更新时的角色会有所不同。
- 动态成员管理： 组成员资格服务能够实时维护组的视图，即哪些服务器属于组。服务器可以自由加入或离开组，组视图会相应更新。
- 分布式事务一致性： 组内的大多数服务器需要就全局事务序列的顺序达成一致，以保证数据的一致性。即使在网络分区情况下，也会通过自动的裂脑保护机制来确保一致性。
- 群组通信系统（GCS）： GCS协议提供了故障检测、成员管理和有序消息传递等功能。它是整个系统的关键部分，通过实现Paxos算法来实现高效的通信和协调。
MySQL组复制的核心思想是将数据库状态的变化以及数据复制和同步的逻辑合理地融合在一起，以确保多台服务器在分布式环境下可以达成一致。这样可以实现高可用性、自动故障恢复和数据冗余，使数据库系统更健壮和可靠。
2什么是组复制
Group Replication 是一种用于实现容错系统的技术。复制组是一组服务器，每个服务器都拥有自己的完整数据副本（一种共享无内容复制方案），它们通过消息传递进行交互。通信层提供了一组保证，如原子消息和全序消息传递。这些功能转化为非常强大的属性，可以用来构建更高级的数据库复制解决方案。
MySQL Group Replication 在这些属性和抽象的基础上构建，并实现了一个多源更新全球复制协议。复制组由多台服务器组成，组内的每个服务器可以独立执行事务。然而，所有读写事务只有在组批准后才提交。换句话说，对于任何读写事务，组都需要决定是否提交，因此提交操作不是来自原始服务器的单方面决定。只读事务在组内无需协调，可以立即提交。
当原始服务器准备在读写事务中提交时，服务器会原子地广播写入值（更改的行）和相应的写入集（更新的行的唯一标识）。由于事务通过原子广播发送，组中的所有服务器要么都接收事务，要么都不接收。如果它们接收，那么它们都按照与之前发送的其他事务相同的顺序接收。因此，所有服务器都按相同顺序接收相同的事务集，建立了事务的全局总序。
然而，不同服务器上同时执行的事务可能存在冲突。这种冲突通过检查和比较两个不同且并发事务的写入集来检测，这个过程称为认证。在认证期间，冲突检测在行级别进行：如果在不同服务器上执行的两个并发事务更新了同一行，则存在冲突。冲突解决过程规定，先订阅的事务在所有服务器上都提交，而后订阅的事务中止，在原始服务器上被回滚，并且在组中的其他服务器上被丢弃。例如，如果 t1 和 t2 在不同站点并发执行，都更改了同一行，并且 t2 在 t1 之前订阅，则 t2 赢得冲突，t1 被回滚。这实际上是一种分布式的“先提交者胜利”规则。需要注意的是，如果两个事务经常发生冲突，最好的做法是在同一台服务器上启动它们，这样它们有机会在本地锁管理器上同步，而不会由于认证而被回滚。
在应用和外部化认证事务时，如果不破坏一致性和有效性，Group Replication 允许服务器偏离事务的约定顺序。Group Replication 是一个最终一致性系统，这意味着一旦传入流量减少或停止，所有组成员都具有相同的数据内容。在流量流动时，事务可以以稍微不同的顺序进行外部化，或者在某些成员之前进行外部化。例如，在多主模式下，本地事务可能会在认证后立即进行外部化，尽管全局顺序中较早的远程事务尚未应用。当认证过程确定事务之间没有冲突时，允许这样做。在单主模式下，对于主服务器，非冲突的本地事务可能会在与 Group Replication 同意的全局顺序不同的顺序中提交和外部化。对于不接受客户端写入的从服务器，在同意的顺序中始终提交和外部化事务。
3组复制用例
Group Replication 允许您创建具有冗余性的容错系统，通过将系统状态复制到一组服务器。 即使某些服务器随后发生故障，只要不是全部或大多数服务器，系统仍然可用。根据失败的服务器数量，组可能会出现性能降级或可扩展性降低，但仍然可用。服务器故障是隔离且独立的。它们由一个组成员资格服务跟踪，该服务依赖于分布式故障检测器，能够在任何服务器离开组时发出信号，无论是自愿离开还是由于意外停机。存在分布式恢复过程，以确保服务器加入组时会自动更新到最新状态。无需服务器故障转移，多源更新全局模式确保即使在单个服务器故障的情况下，更新也不会被阻塞。总之，MySQL Group Replication 保证了数据库服务的持续可用性。
需要理解的重要一点是，尽管数据库服务可用，但在发生意外的服务器退出时，连接到该服务器的客户端必须被重定向或故障转移到其他服务器。这不是 Group Replication 试图解决的问题。连接器、负载均衡器、路由器或某种中间件更适合处理这个问题。
总结来说，MySQL Group Replication 提供了高度可用、高度弹性、可靠的 MySQL 服务。
- *提示：**为了部署多个 MySQL 实例，您可以使用 InnoDB Cluster，它使您能够在 MySQL Shell 中轻松管理一组 MySQL 服务器实例。InnoDB Cluster 在编程环境中封装了 MySQL Group Replication，使您可以轻松部署一组 MySQL 实例以实现高可用性。此外，InnoDB Cluster 与 MySQL Router 接口无缝衔接，使您的应用程序可以连接到集群，无需编写自己的故障转移过程。
- *示例用例：**以下是 Group Replication 的典型用例示例。
- 弹性复制（Elastic Replication）： 需要非常灵活的复制基础设施的环境，其中服务器数量必须动态增减，并且副作用尽可能少。例如，云端的数据库服务。
- 高可用分片（Highly Available Shards）： 分片是实现写入扩展的一种常用方法。使用 MySQL Group Replication 来实现高可用分片，其中每个分片映射到一个复制组。
- 替代异步源-复制（Alternative to Asynchronous Source-Replica Replication）： 在某些情况下，使用单个源服务器会造成单一的争用点。在某些情况下，写入整个组可能更具可扩展性。
- 自主系统（Autonomic Systems）： 此外，您可以纯粹为了内建在复制协议中的自动化部署 MySQL Group Replication。
4单主 多主
单主模式
在单主模式（group_replication_single_primary_mode=ON）下，组只有一个被设置为读写模式的主服务器。组中的所有其他成员都被设置为只读模式（使用 super_read_only=ON）。通常情况下，主服务器是第一个引导组的服务器。加入组的所有其他服务器会了解到主服务器，并自动被设置为只读模式。
在单主模式下，Group Replication 强制只有一个服务器对组进行写入，因此与多主模式相比，一致性检查可以更加宽松，DDL 语句不需要额外的处理。选项 group_replication_enforce_update_everywhere_checks 可以启用或禁用组的严格一致性检查。在部署单主模式或将组更改为单主模式时，必须将此系统变量设置为 OFF。
被指定为主服务器的成员可能以以下方式更改：
- 如果现有的主服务器离开组，无论是自愿还是意外离开，新的主服务器都会自动选举出来。
- 您可以使用 group_replication_set_as_primary() 函数指定一个特定的成员作为新的主服务器。
- 如果您使用 group_replication_switch_to_single_primary_mode() 函数将运行在多主模式下的组更改为单主模式，新的主服务器会自动选举出来，或者您可以通过函数指定新的主服务器。
这些函数只能在所有组成员都运行 MySQL 8.0.13 或更高版本时使用。当自动选举出新的主服务器或手动指定时，它会自动设置为读写模式，其他组成员仍然作为次要服务器，因此是只读模式。图 18.4 显示了这个过程。
主选举算法
自动主成员选举过程涉及每个成员查看组的新视图，对潜在的新主成员进行排序，并选择最合适的成员。每个成员在本地做出自己的决定，遵循其 MySQL Server 版本中的主选举算法。因为所有成员必须达成相同的决定，所以如果其他组成员运行较低版本的 MySQL Server，成员会适应其主选举算法，以使其行为与组中具有最低 MySQL Server 版本的成员相同。
成员在选举主时考虑的因素如下：
- 首先考虑哪个成员或哪些成员运行了最低的 MySQL Server 版本。如果所有组成员都运行 MySQL 8.0.17 或更高版本，则首先按其发布的修补版本对成员进行排序。如果任何成员运行 MySQL Server 5.7 或 MySQL 8.0.16 或更低版本，则首先按其发布的主要版本进行排序，而修补版本将被忽略。
- 如果有多个成员运行了最低的 MySQL Server 版本，则第二个考虑因素是这些成员的每个成员权重，由 group_replication_member_weight 系统变量在成员上指定。如果组中有任何成员运行 MySQL Server 5.7，在那里该系统变量是不可用的，这个因素将被忽略。
- group_replication_member_weight 系统变量在 0 到 100 范围内指定一个数字。所有成员默认的权重为 50，因此可以将权重设置在此之下以降低其排序，将权重设置在此之上以提高其排序。您可以使用此加权函数来优先使用更好的硬件，或者在主服务器计划维护期间确保故障转移到特定成员。
- 如果有多个成员运行了最低的 MySQL Server 版本，并且其中多个成员具有最高的成员权重（或正在忽略成员权重），则第三个考虑因素是每个成员生成的服务器 UUID 的字典序顺序，由 server_uuid 系统变量指定。具有最低服务器 UUID 的成员被选择为主服务器。此因素充当一个保证和可预测的决策因素，以便如果任何重要因素都无法确定，所有组成员都达到相同的决策。
查找主服务器
要在部署在单主模式下时找出当前主服务器是哪个服务器，请使用 performance_schema.replication_group_members 表中的 MEMBER_ROLE 列。例如：
sqlCopy code mysql> SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members; +-------------------------+-------------+ | MEMBER_HOST | MEMBER_ROLE | +-------------------------+-------------+ | remote1.example.com | PRIMARY | | remote2.example.com | SECONDARY | | remote3.example.com | SECONDARY | +-------------------------+-------------+
警告： group_replication_primary_member 状态变量已被弃用，计划在将来的版本中删除。或者，可以使用 group_replication_primary_member 状态变量。
多主模式
在多主模式（group_replication_single_primary_mode=OFF）下，没有成员具有特殊角色。任何与其他组成员兼容的成员在加入组时都会被设置为读写模式，并且可以处理写事务，即使它们是同时发出的。
如果成员停止接受写事务，例如，在意外服务器退出的情况下，连接到它的客户端可以重新定向或故障转移到任何处于读写模式的其他成员。Group Replication 不处理客户端端的故障转移，因此您需要使用中间件框架（如 MySQL Router 8.0）、代理、连接器或应用程序本身来安排。
- *多主模式是一个最终一致性系统。**这意味着一旦传入的流量减少或停止，所有组成员都具有相同的数据内容。在流量流动时，事务可以在一些成员上进行外部化，然后再在其他成员上进行外部化，特别是如果某些成员的写吞吐量比其他成员低，可能会导致陈旧的读取。在多主模式下，速度较慢的成员也可能会累积大量要认证和应用的事务，导致冲突和认证失败的风险增加。为了限制这些问题，您可以激活并调整 Group Replication 的流量控制机制，以减小快速和慢速成员之间的差异。
从 MySQL 8.0.14 开始，如果您希望对组中的每个事务都具有一致的事务一致性保证，可以使用 group_replication_consistency 系统变量来实现。您可以选择适合组的工作负载和数据读写的设置，考虑到提高一致性所需的同步的性能影响。您还可以为单个会话设置系统变量，以保护特别对并发性敏感的事务。
事务检查
当一个组在多主模式下部署时，会对事务进行检查以确保它们与该模式兼容。在以多主模式部署 Group Replication 时，将进行以下严格一致性检查：
- 如果事务在 SERIALIZABLE 隔离级别下执行，则在与组同步时，其提交将失败。
- 如果事务针对具有级联约束的外键的表执行，则在与组同步时，其提交将失败。
这些检查由 group_replication_enforce_update_everywhere_checks 系统变量控制。在多主模式下，该系统变量通常应设置为 ON，但可以通过将该系统变量设置为 OFF 来选择性地停用检查。在部署单主模式时，该系统变量必须设置为 OFF。
数据定义语句
在以多主模式运行的 Group Replication 拓扑中，在执行数据定义语句（也称为数据定义语言，DDL）时需要特别注意。
MySQL 8.0 引入了对原子数据定义语言（DDL）语句的支持，其中完整的 DDL 语句要么作为单个原子事务提交，要么回滚。然而，无论是原子还是非原子的 DDL 语句，都会隐式地终止当前会话中活动的任何事务，就好像在执行语句之前已经提交了一个 COMMIT。这意味着不能在另一个事务内执行 DDL 语句，在事务控制语句（如 START TRANSACTION ... COMMIT）内执行，或在同一事务内与其他语句组合使用 DDL 语句。
Group Replication 基于一种乐观复制模式，在此模式下，语句会乐观地执行，如果有必要，稍后回滚。每个服务器在没有先获得组一致性的情况下执行。因此，在多主模式下复制 DDL 语句时需要更多的注意。如果对同一个对象进行模式更改（使用 DDL）和数据更改（使用 DML），则在模式操作尚未完成且在全局复制之前，需要通过同一服务器处理这些更改。如果不这样做，当操作被中断或只部分完成时，可能导致数据不一致。如果组在单主模式下部署，则不会发生此问题，因为所有更改都通过同一服务器（即主服务器）执行。
版本兼容性
为了实现最佳兼容性和性能，组的所有成员应该运行相同版本的 MySQL Server，因此也运行相同版本的 Group Replication。在多主模式下，这更为重要，因为所有成员通常都会以读写模式加入组。如果组包括运行多个 MySQL Server 版本的成员，则存在某些成员与其他成员不兼容的可能性，因为它们支持其他成员不支持的功能，或者缺少其他成员拥有的功能。为了防范这种情况，在新成员加入（包括升级并重新启动的以前的成员）时，该成员会针对其余组成员进行兼容性检查。
这些兼容性检查的一个重要结果在多主模式下特别重要。如果要加入的成员的 MySQL Server 版本高于现有组成员所运行的最低版本，它会加入组，但保持为只读模式。（在以单主模式运行的组中，新添加的成员默认为只读模式。）运行 MySQL 8.0.17 或更高版本的成员在检查其兼容性时将考虑其发布的补丁版本。运行 MySQL 8.0.16 或更低版本，或 MySQL 5.7 的成员只考虑主要版本。
在以多主模式运行的组中，如果成员使用不同的 MySQL Server 版本，Group Replication 会自动管理运行 MySQL 8.0.17 或更高版本的成员的读写和只读状态。如果一个成员离开组，现在的最低版本运行的成员会自动设置为读写模式。当您将以单主模式运行的组更改为以多主模式运行时，使用 group_replication_switch_to_multi_primary_mode() 函数，Group Replication 会自动将成员设置为正确的模式。如果正在运行的 MySQL Server 版本高于组中存在的最低版本，那么会自动将成员置于只读模式，而运行最低版本的成员则置于读写模式。
组复制成员个数
MySQL Group Replication是一种数据库复制技术，其中一组服务器形成一个复制组。每个组都有一个以UUID形式表示的名称。该组是动态的，服务器可以随时加入（自愿或非自愿地）并离开该组，组在服务器加入或离开时会自动调整自身。
当服务器加入组时，它会通过从现有服务器获取丢失的状态来自动使自己保持最新。如果服务器离开组，例如因维护而关闭，剩余的服务器会注意到它已经离开，并自动重新配置组。
Group Replication具有组成员服务，用于定义哪些服务器在线并参与组复制。在线服务器的列表被称为视图（view）。组内的每个服务器在给定时间点都有一个一致的视图，显示哪些服务器是活跃参与组复制的成员。
组成员不仅必须在事务提交上达成一致，还必须就当前视图达成一致。如果现有成员同意将新服务器纳入组内，组将重新配置以整合该服务器，从而触发视图更改。如果服务器自愿或非自愿地离开组，组会动态重新排列其配置并触发视图更改。
在成员自愿离开组的情况下，它首先启动动态组重新配置，在此期间，所有成员必须就不包括离开服务器在内的新视图达成一致。然而，如果成员非自愿地离开组，例如因为意外停止或网络连接中断，它无法启动重新配置。在这种情况下，Group Replication的故障检测机制会在短时间内识别出成员已经离开，并提出在没有失败成员的情况下重新配置组。与自愿离开的成员一样，重新配置需要组内大多数服务器的同意。然而，如果组无法达成一致意见，例如由于出现了无法形成大多数在线服务器的分区，系统将无法动态更改配置，并会阻止以防止分裂脑的情况。这种情况需要管理员的干预。
成员可能在短时间内下线，然后在故障检测机制检测到其故障之前尝试重新加入组，也在组被重新配置以删除该成员之前。在这种情况下，重新加入的成员会忘记其先前的状态，但如果其他成员向其发送针对其崩溃前状态的消息，可能会引发问题，包括可能的数据不一致性。如果处于这种情况的成员参与了XCom的共识协议，它有可能在故障前后做出不同的决策，从而导致XCom为同一共识轮提供不同的值。
为了应对这种可能性，从MySQL 5.7.22版本开始，在MySQL 8.0中，Group Replication会检查同一服务器的新实例是否尝试加入组，而其旧实例（具有相同的地址和端口号）仍然被列为成员。在旧实例通过重新配置被移除之前，新实例将被阻止加入组。需要注意的是，如果通过group_replication_member_expel_timeout系统变量添加了等待期，以在成员被驱逐之前允许成员在超时前重新连接到组，则在怀疑成员时，如果成员在怀疑超时之前重新连接到组，则可以作为其当前实例重新变为组内的活跃成员。当成员超过驱逐超时并从组中驱逐出去，或者当通过STOP GROUP_REPLICATION语句或服务器故障停止Group Replication时，它必须以新实例重新加入。
MySQL Group Replication是MySQL的插件，它建立在现有的MySQL复制基础架构之上，利用了诸如二进制日志、基于行的日志记录和全局事务标识符等功能。它与当前的MySQL框架集成，例如性能模式或插件和服务基础架构。以下图示展示了MySQL Group Replication的总体架构的块图。
MySQL Group Replication插件包括一组用于捕获、应用和生命周期的API，这些API控制插件与MySQL服务器的交互方式。这些接口使信息能够在服务器和插件之间流动。这些接口将MySQL服务器核心与Group Replication插件隔离开来，主要是放置在事务执行流水线中的钩子。从一个方向来看，从服务器到插件，有针对事件的通知，如服务器启动、服务器恢复、服务器准备好接受连接，以及服务器即将提交事务。在另一个方向上，插件会指示服务器执行诸如提交或中止正在进行的事务，或在中继日志中排队事务。
Group Replication插件架构的下一层是一组在通知路由到它们时做出反应的组件。捕获组件负责跟踪正在执行的事务相关的上下文。应用程序组件负责在数据库上执行远程事务。恢复组件管理分布式恢复，负责通过选择捐赠者、管理赶上过程并对捐赠者故障做出反应，使加入组的服务器保持最新。
继续向下堆栈，复制协议模块包含复制协议的具体逻辑。它处理冲突检测，并将事务接收并传播到组中。
Group Replication插件架构的最后两层是Group Communication System（GCS）API和基于Paxos的组通信引擎（XCom）的实现。GCS API是一个高级API，它抽象出构建复制状态机所需的属性
