01 多主方式
在多主方式下（group_replication_single_primary_mode = OFF），一切成员不会区别primary和standby人物。参加该组时，与其他组成员兼容的任何成员都被设置为读写方式，而且能够处理写业务，即便它们是并发履行的。
假如组仿制中的某个成员停止承受写业务，例如，在某个节点意外宕机的状况下，能够将与其衔接的客户端重定向或毛病转移到处于读写方式的任何其他健康的成员。组仿制本身不处理客户端毛病转移，因而需求运用中间件结构（例如MySQL Router 8.0，代理，衔接器或使用程序本身）来完结。下图说明晰MGR集群的多主方式下毛病转移的完结：
组仿制在集群内确保了体系的最终共同性。一旦入栈流量削减，一切组成员将具有相同的数据内容。当流量在集群内部下发时，业务能够在某些成员之间先进行耐久化，特别是假如某些成员的写入吞吐量小于其他成员的状况下，则或许导致功用差的节点上读取到旧数据。在多主方式下，写入速度较慢的成员还或许积压过多的业务，从而导致更大的抵触和认证失利风险。为了避免这些问题，能够针对不同的业务场景运用组仿制自带的流控机制，以最大程度地削减不同成员之间的业务差异。关于MGR的流控机制，咱们在后面进行详细评论。
从MySQL 8.0.14开始，假如要为集群中的每个业务都具有一个业务共同性确保，则能够运用group_replication_consistency体系变量来做到这一点。能够选择合适集群作业负载和数据读写优先级的设置，一起考虑到进步共同性整个集群对功用的影响。还能够为单个会话设置该体系变量，用来维护特别是对并发敏感的业务。有关业务共同性的更多信息，咱们在后面的章节详细描述。
02 业务描述
当MGR集群是以多主的方式在线上运转时，集群经过以下两条原则对不同成员之间的业务进行严格的共同性检测，以确保这些业务能够在集群内提交成功：
1.假如在SERIALIZABLE阻隔级别下履行业务，则在集群中同步数据时，该业务将提交失利。
2.假如业务是针对具有具有级联约束的外键的表履行的，则在集群中同步数据时，该业务将提交失利。
group_replication_enforce_update_everywhere_checks体系变量操控上述行为。在多主方式下，一般应将体系变量设置为ON，可是能够选择将体系变量设置为OFF来禁用查看。在单主方式下部署时，有必要将体系变量设置为OFF。
03 在多主方式的仿制拓补中，履行DDL需求分外小心
MySQL 8.0引入了对原子数据界说言语（DDL）句子的支撑，其间完整的DDL句子作为单个原子业务被提交或回滚。可是，DDL句子隐式完毕当时会话中处于活动状况的业务，就好像在履行该句子之前履行了COMMIT相同。这意味着DDL句子不能在另一个业务中履行，例如在业务操控句子（START TRANSACTION … COMMIT）中履行，也不能与同一业务中的其他句子组合。
假如对同一目标进行更改（运用DDL）并更改目标包括的数据（运用DML），则需求经过同一个节点处理更改，而DDL操作尚未完结并在各处仿制。否则，当操作中止或仅部分完结时，或许导致数据不共同。假如集群以单主服务器方式部署，则不会产生此问题，由于一切数据更改都是经过同一个节点（主节点）履行的。
04 版别兼容性
为了取得最佳的兼容性和功用，集群中的一切成员应运转相同版别的MySQL Server，因而应运转相同版别的组仿制。在多主方式下，这更为重要，由于一切成员一般都将以读写方式参加该集群。假如集群中包括运转多个MySQL Server版别的成员，则某些成员或许与其他成员不兼容，由于它们支撑其他成员不具备的功用或短少其他成员具有的功用。为了避免这种状况，当新成员参加（包括曾经已晋级并重新发动的成员）时，该成员将对组的其他成员履行兼容性查看。
这些兼容性查看的成果在多主方式下特别重要。假如新参加成员所运转的MySQL Server版别高于现有组成员所运转的最低版别，则它将参加该组，但坚持只读方式。（在以单主方式运转的集群中，无论如何，新增加的成员在任何状况下均默认为只读。）运转MySQL 8.0.17或更高版别的成员在查看其兼容性时会考虑该发行版的补丁程序版别。运转MySQL 8.0.16或更低版别或MySQL 5.7的成员仅考虑首要版别。
在具有运用不同MySQL Server版别的成员的多主方式下运转的集群中，组仿制会主动办理运转在MySQL 8.0.17或更高版别的成员的读写状况和只读状况。假如成员离开集群，则运转当时最低版别的成员将主动设置为读写方式。当运用group_replication_switch_to_multi_primary_mode自界说函数时，将以单主方式运转的组更改为以多主方式运转时，组仿制会主动将成员设置为正确的方式。假如新增成员运转的MySQL版别高于组中存在的最低版别的成员，则该成员将主动置于只读方式，而运转最低版别的成员将处于读写方式。
05MGR服务
5.1成员资历：
仿制组由一组MySQL Server构成。集群具有一个唯一的称号，称号方式为UUID字符串。集群内的成员是动态的，成员能够随时脱离集群，也能够随时参加集群。每逢有Server参加或脱离集群时，集群的相关信息都会进行主动调整。
假如一个Server参加了集群，则它会从集群的现有成员中主动获取本身缺失的数据状况以便和集群坚持数据同步。假如一个成员脱离了集群，其他的成员会发现该成员脱离了集群，并主动重新配置集群。
组仿制界说了集群内哪些成员在线且是活泼成员。在线成员列表被称为组视图。集群中的每个成员都具有一个共同的视图，即表明在给定的时间集群中哪些成员是活泼成员。
组成员不仅在业务提交时有必要达到共同，对于组视图的改变也有必要达到共同。假如现有成员同意新的Server参加集群，则集群将被重新配置，以便将新节点集成到集群中，这将触发组视图的改变。假如组成员脱离集群，该集群将动态地重新配置，并触发组视图的改变。
在成员自愿脱离集群的状况下，它首先发动动态组重新配置，在此期间，一切组成员有必要就新的组视图达到共同。可是，假如某个组成员是非自愿地脱离了集群，例如：由于意外宕机了或网络衔接中止了，那么脱离集群的成员就不能发动动态重新配置。在这种状况下，组仿制的毛病检测机制会在短时间内识别出该成员现已脱离了集群，并主张将已脱离组成员排除在外并进行动态重新配置组。重新配置组需求得到组中大大都组成员的同意。可是，假如此刻集群内不能达到共同，例如：由于集群内活泼节点数量少于节点总数量的半数时，体系就不能动态重新配置集群，这种状况下集群会堵塞写访问以避免呈现脑裂的状况。直到人工介入处理。
在毛病检测机制检测到其毛病之前，或在重新配置集群以删去该毛病成员之前，答应组成员时间短离线，然后测验重新参加集群。在这种状况下，重新参加的成员或许会丢失它曾经的业务数据，假如此刻其他成员向它发送了包括该成员崩溃前的状况的音讯，则这就或许会导致一些问题（例如：或许导致数据不共同。）
为了处理这个问题，从MySQL 5.7.22及其之后的版别中，当Server参加一个集群时，会被赋予一个唯一的标识符。这使组仿制能够察觉到同一Server的新化身（尽管具有相同的地址，但不同的化身具有不同的标识符）企图参加组时，而其旧化身依然会作为成员列出。在经过重新配置组并删去旧的化身之前，将阻止新的化身参加组。假如经过体系变量group_replication_member_expel_timeout的设置增加了疑似毛病的成员在被驱逐出集群之前答应回来集群的等待时间，则只需疑似毛病的成员不是真的毛病了，那么被置疑的那个成员在这个等待时间内就能够测验重新参加集群。假如在被置疑出毛病的成员上履行了重启组仿制，则该成员将成为新的化身，在置疑超时之前（置疑期时间内）不能重新参加组。
5.2毛病检测：
组仿制支撑一种毛病检测机制，该机制能够发现和列出哪些组成员是静默的，并假定静默的组成员现已挂机。整体上讲，毛病检测器是一种分布式服务，它供给关于哪些组成员或许死机的信息。当组成员静默时就会引发置疑。当组成员A在给定的时间段内没有接收来自组成员B的音讯时，将产生音讯超时并引发置疑。稍后，假如组内其他一切的成员经过协商之后，都同意对该成员的置疑或许是真实的（大都节点断定的成果），则集群就会断定被置疑的成员确实产生了毛病。这意味着组中其他成员能够经过采纳协调共同的决议计划来将毛病成员驱逐出组（被断定为产生毛病的成员）。
假如某个组成员与组中的其他成员产生了网络阻隔，那么它会置疑集群中其他一切成员都产生毛病了。由于无法与组内的其他成员进行协商（由于裁定成员数不足），它的置疑无效。此刻，它也无法履行任何本地业务（只读业务能够履行）。
5.3容错性：
组仿制建立在Paxos分布式算法的完结之上，以供给组成员之间的分布式协调。因而，它需求大大都组成员处于活泼状况才能达到裁定成员数，才能够做出决议计划。该要求会直接影响到体系在不影响本身和全体可用性的状况下能够容忍产生毛病的成员数量。能够容忍产生毛病的成员数量（假设为f个）和要求组内总成员数量（假设为n个）之间的关系为：n = 2 x f + 1。
假如要容忍至少一个组成员产生毛病，那么，组内的总成员数量至少需求3个。因而，当一个组成员产生毛病时，依然有2个组成员是活泼成员，即活泼成员占大都（三分之二），此刻，集群内可经过裁定机制主动驱逐毛病成员并答应体系持续对外供给服务。可是，假如第二个组成员再产生毛病（非自愿脱离组），则该集群（剩余一个成员）会产生堵塞，由于短少大都成员来做出合理的决议计划，所以无法主动康复到能对外供给服务的状况，此刻需求人工介入处理。
一般，基于功用和维护本钱的考虑，组内的成员总数量不主张超越7个，最大只能9个。
5.4可观察性：
尽管MGR插件内置了许多主动化功用。但有时或许需求了解幕后产生了什么。假如有需求，能够经过performance_schema下的表查询集群的整个状况(包括视图、抵触统计信息和服务状况等)。仿制协议的分布式特性、以及组成员在业务和元数据上的共同性，要求组内的一些元数据和状况信息在组内一切成员间彼此同步，这就使得查看组的状况等信息变得愈加简单。你只需求衔接到集群内的任意一个成员中，并经过performance_schema下的相关仿制状况信息表履行select句子进行查询，就能够获取到组相关的本地和大局信息。有关更多信息，咱们放在MGR状况监控中会详细评论。
06 MGR插件架构
MGR的整体架构图如下：
MGR 插件包括一组用于捕获，使用和生命循环的API，这些API操控着MGR插件如何与MySQL Server交互。这些接口是放置在业务履行管道中的一些钩子（它们将MySQL Server的中心与MGR插件阻隔开来），逻辑上将MySQL Server内核与MGR插件阻隔开来。其间有一些接口供给把通讯信息从Server发送给MGR插件（例如：Server发动、康复、承受衔接以及Server行将提交业务的事情告诉），有一些接口供给把通讯信息从MGR插件发送给MySQL Server（例如：MGR插件命令MySQL Server提交、停止一个正在履行的业务，或许让该业务写入relay log中排队等候处理）。
在这些API的下一层，是一组组件(capture、applier、Recovery)，组仿制中的三个中心模块，当上层API产生调用，将依据调用类型路由到下面这三个模块履行相应的逻辑：
capture 组件担任跟踪与正在履行的业务相关的上下文信息。
applier 组件担任在数据库上使用远程业务，其实便是读取relay log中数据进行回放。
Recovery 组件办理数据库节点的分布式康复相关的作业，以及担任在一个新的Server参加集群时选择一个引导节点，协调新参加节点的数据追赶的更新过程（包括相关的数据回追，失利处理等），以及对选择引导节点失利之后做出一些呼应。简而言之便是办理集群成员的recovery。
持续沿着仓库向下，仿制协议模块包括仿制协议中的一些特定逻辑。例如：处理抵触检测，接收和传播业务到集群中。
MGR 插件体系结构的最终两层是组通讯体系(GCS) API和基于paxos的组通讯引擎(XCom)的完结。GCS API是一个高档API，它抽象了构建仿制状况机所需的属性，详细属性咱们在前文现已描述过了。因而，它将音讯层的完结与插件的其他上层组件解耦。组通讯引擎处理与仿制组成员之间的通讯，首要供给基于Paxos协议的变体完结数据共同性的中心功用。
