在传统的的主从复制拓扑中，如果主库宕机，那数据库服务就停了，这意味着主库是单一故障点。解决这种单点故障的传统解决方法就是为系统增加冗余，MySQL组复制解决了这种场景需求，多台MySQL服务器在同一组中会自动保持同步状态，当某台服务器故障时，整个复制组依然可以保持正常并对外提供服务。但同时组复制也会遇到各种典型的分布式系统问题，例如脑裂（Split Brain）。
组复制有一个成员管理服务（Group Membership Service）管理整个组的成员视图并保证成员的状态一致性，当Server加入或者离开组的时候，视图会自动更新。如果Server意外宕机，错误检查（Failure Detection）机制会发现异常并通知更新组成员视图。
目录
4.1 组成员服务（Group Membership Service）
4.2 错误检测机制（Failure Detection Mechanism）
一、组复制介绍
在介绍具体细节前，我们先看一下传统的MySQL主从复制与主复制的细节差异。
异步复制
传统的主从复制架构是1个主库，1个或多个备库，主库通过binlog记录事务并发送到从库relay log 并在备库执行事务，主库事务提交和备库是完全异步的。
半同步复制
半同步复制相对于异步复制，增加了一步确认操作，主库在提交前需要等待至少一个备库将事务写入relay log并返回确认信息（ACK）。
组复制
组复制是由多台MySQL server组成的一套系统，提供了容错功能，组中每个成员都拥有完整的数据（无共享复制方案 shared-nothing replication scheme），组成员间通过消息传递服务进行通信。组复制中的成员可以独立的发起和提交事务（多主模式），当事务准备提交时，需要在组中广播将要修改的数据集，将事务加入全局事务列表，所有组成员必须就全局事务列表中给定事务的顺序达成一致，且事务必须由组服务批准后才能提交。只读的事务不需要组服务协调，可以立刻提交。
在多主模式下，由于不同的server可能会同时会修改相同的数据，事务之间会产生冲突，因此组复制有一个验证进程（Certification）检查此类冲突，即事务提交前有个certify的动作，这个检查是行级别的。当不同server发起的事务修改同一行数据时，即发生冲突。冲突的解决方案是先到事务提交，后到事务回滚，后到的事务会在发起的server上回滚并被其他成员丢弃。
二、组复制应用场景
组复制通过在组的成员中同步数据状态来建立一套具有容错功能的系统，可以提供不间断的数据库服务。即使部分服务器故障，只要大部分服务器正常，系统就是可用的（根据故障的服务器数量可能会有性能和扩展性下降）。
故障监测服务会自动监测服务器的状态，自动将故障或主动离开的server从组中剔除。当组成员恢复并重新加入组时，也会自动将其状态同步到最新，不需要故障转移。
当服务器故障时，组复制虽然可以继续提供数据库服务，但那些连接到故障服务器上的会话必须重新连接，或者failover到其他正常的服务器上，组复制并不提供会话failover的功能，需要其他的解决方案，例如MySQL Router。
在下列应用场景中，可以采用组复制方案：
弹性复制：环境需要动态调整，经常有服务器动态加入或者离开，例如云数据库服务。
高可用分片：可以利用组复制来实现高可用分片，每个分片映射到一个复制组。
单主性能提升：单一主机有时会引起热点资源争用，组复制在多主模式下，所有服务器都可以同时接收数据更新，对数据冲突进行检测，以确保数据的一致性。当单一主库负载过大时，可以通过组复制的多主模式分散写入负载。
三、组复制工作模式
组复制可以工作在2种模式下：单主模式和多主模式
3.1 单主模式（Single-primay mode）
在单主模式下（group_replication_single_primary_mode=on）只有一台服务器被设置为读写模式，其他的服务器都被设置为只读模式（super_read_only=on）。新加入的服务器会自动和主服务器同步状态并被设置为只读模式。
super_read_only：当参数read_only=on时，普通用户无法更新，但是不会阻止具有connection admin和super权限的用户更新，如果super_read_only和read_only同时设置为on，那么即使具有connection admin和super权限的用户也无法更新。
当运行在单主模式下，由于只有一台服务器可以更新数据，相对于多主模式，一致性检查不需要那么严格且DDL也不用担心多主更新冲突。因此运行在单主模式下，强一致性检查需要关闭，group_replication_enforce_update_everywhere_checks必须设置为off。
主库的选举
如果当前的主库离开了组，则会自动选举出一台作为新的主库（读写）。
你也可以用group_replication_set_as_primary()显式指定某台服务器作为主库（MySQL 8.0.13以上版本）。
当用group_replicatoin_switch_to_single_primary_mode() 从多主模式切换到单主模式时，会自动选举出一台主库，当然你也可以自己指定（下图中主库S1失败后S2被选举为主库）。
当进行自动主库选举时会按照下列优先级进行：
- 1.低版本优先，当组复制中同时存在高版本和低版本MySQL时，低版本会被选举为主库（向下兼容）。
- 2.如果有多个低版本，则会参考group_replication_member_weight(0-100)变量的值，默认为50，数字越大优先级越高。
- 3.如果版本，group_replication_member_weight都一样，最后考虑的因素是UUID的排序，UUID最小的选举为主库。
运行在单主模式下时，你可以通过performance_schema.replicaiton_group_members表中member_role字段 或 group_replication_primary_member 系统变量查看各服务器的角色。
3.2 多主模式（Multi-primary mode）
在多主模式下（group_replication_single_primary_mode=off），所有服务器都是相同的角色，没有主从之分，事务可以在不同的服务器上并行提交。
如果某个成员失败，连接到其上的会话可以重新连接（redirect）或者故障转移（failover）到其他成员上，但是MySQL的组复制并未提供此功能，你需要使用其他中间件来完成此项工作（例如 MySQL Router）。
事务检查
在多主模式下，冲突的可能性变高，事务提交前会检查其与多主模式的兼容性：
- 在serializable隔离级别下，当与组其他成员同步时，提交失败。
- 当更新的表存在级联的外键约束时，与其他组成员同步时会导致提交失败。
- 上面的检查由group_replication_enforce_update_everywhere_checks 参数控制，在多主模式下，此参数应该设置为ON，但你也可以选择关闭此项检查。在单主模式下，该参数必须设置为OFF。
四、组复制相关服务
MySQL组复制的功能由一系列组复制的相关服务实现，下面列举了组复制的各项服务功能。
4.1 组成员服务（Group Membership Service）
组成员服务维护了一个列表，其中包含了所有当前在线的组成员名单，这份名单叫做视图（View）。每个组成员都保存一份同样的视图，组成员不仅需要就事务达成一致，也需要对视图的内容达成一致。
在组复制中，成员可以动态的加入和离开组，当成员发生变化时，都会更新视图。当某个成员主动离开组时，它会触发一个视图更新的动作，所有的组成员必须就视图内容达成一致（剔除将要离开的成员），某一组成员的离开时需要得到大部分的组成员同意，如果达不到这个要求，系统会处于阻塞状态以防发生脑裂（split brain）。这种情况需要管理员进行干预。
如果组成员被动离，例如网络故障，它不会触发视图更新。过一段时间后，组复制的错误检测机制（Failure Detection Mechanism）会发现成员的离开，然后触发一个视图更新动作。
4.2 错误检测机制（Failure Detection Mechanism）
在组复制中，每个成员都与其他成员点对点连接，就像网一样。
而错误检测机制是一个分布式的服务，用来检测成员是否可以与组内其他成员进行通信。如果5秒内无法收到其他成员的通信，则会怀疑其失败，并在自己的performance_schema的replication_group_members将其标注为unreachable。
当无法通信时，两台成员会互相怀疑对方失败，但是更新视图需要大部分的成员同意，而失败的成员无法获得其他成员的同意，这种怀疑没有意义。
其他大部分的成员会一致决定将失败的成员驱除出组。所以组复制只要大部分成员在线，就可以继续提供服务。
4.3 容错（Fault-tolerance）
由于所有决定都必须要大部分成员同意，因此为了容忍N台服务器故障，服务器的数量至少为2*N+1。为了容忍一台故障，组内必须具有至少三台服务器。但如果第二台服务器又失败了，此时整个系统就会阻塞，因为没有大多数成员可以做出决定。
五、组复制插件架构
组复制的实现是一个MySQL插件，它以现有的MySQL复制架构为基础，利用了MySQL的二进制日志(Binary log)、基于行的日志记录(Row-based logging)和全局事务标识符（GTID）等功能。它与当前的MySQL架构融合，共同实现组复制。
组复制插件的架构示意图：
组复制架构顶层包含一组捕获、应用和生命周期API（第一层 APIs:Capture/Apply/Lifecycle），这些API控制插件与MySQL server进行交互。这些将MySQL sever的核心与组复制插件隔离开。数据流方面，从MySQL server到插件，包括server启动，恢复，准备好接受连接，准备提交事务等。从插件到MySQL server，插件通知MySQL server进行提交或放弃事务，或事务在中继日志中的排队等动作。
插件体系结构的下一层是一系列功能实现组件（第二层 Capture Applier Recovery），
- 捕获组件（Capture）负责跟踪与正在执行的事务相关的上下文。
- 应用组件（Applier）负责在数据库上执行远程事务。
- 恢复组件（Recovery）管理分布式数据恢复，选择数据捐赠者，对故障做出反应，执行追赶程序，使加入该组的服务器更新到最新状态。
第三层复制协议逻辑（Replication Protocol Logics）模块包含复制协议的逻辑。它处理冲突检测（conflict detection），接收事务并将其传播到组。
最后两层是组通信系统（Group Communication System，GCS）API和基于Paxos的组通信引擎（XCom）的实现。GCS API将消息传递层的实现与插件上层分离，组通信引擎处理与复制组成员的通信。
1632
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
