MYSQL--架构--MGR--理论--02--架构

MYSQL–架构–MGR–理论–02–架构

---

1、架构图

1.1、主要组成

1. APIs接口层
2. 组件层
3. 复制协议模块层
4. GCS API+Paxos 引擎层

1.2、事务进入 MGR 层内部处理过程

1. 应用发来的事务从 MySQL Server 经过 MGR 的 APIs接口层 分发到组件层。
2. 组件层去 处理 事务相关信息，然后经过复制协议层进行事务传输，最后经过 GCS API+Paxos 引擎层保证事务在各个节点数据最终一致性

2、单主模式(single-primary mode)

2.1、介绍

1. 主节点1个，且可写可读，从节点N个，且只读
2. 当主节点故障时，会自动选举一个新的主节点，选举成功后，它将设置为可写，其他slave将指向这个新的主节点。
3. 多数情况下都是配置单主模型的MGR
4. 优点：
   1. 没有数据不一致的危险
   2. 限制少
   3. 配置简单
   4. 学习成本低
5. 缺点：性能比多主模型差

2.2、选举

2.2.1、指定主节点

1. 使用group_replication_set_as_primary()指定特定成员作为新的主节点
2. MySQL 8.0.13或 更高版本

2.2.2、自动选举主节点(优先级从高到低)

1. 哪个成员运行的MySQL 版本最低最优先。低版本优先是考虑到高版本同步到低版本，高版本可能有一些新特性，无法在从库正常回放，导致同步出现问题。
   1. MySQL 8.0.17或以上版本：组成员将首先按照发布的补丁版本进行排序。
   2. MySQL 8.0.16或以下版本：成员将首先按其发布的主要版本排序，并忽略补丁版本。
2. 版本号一致的情况下会按照节点自身存在权重设置进行选举,权重高的优先选举
   1. 由group_replication_member_weight参数控制,默认50
3. 如果上述条件无法完成选主则按照server_uuid排序进行选举，选取UUID最小的成员作为主成员

2.3、从节点提升为主前，要处理积压的事务

1. 可靠性优先：如果有积压的事务，需要等积压的事务全被应用完，才能在新主上进行读写操作。
   1. group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER
2. 可用性优先：不管是否有积压的事务，直接在新主上进行读写操作，性能最好，单主模式下基本适用；
   1. group_replication_consistency=EVENTUAL

3、多主模式(multi-primary mode)

3.1、介绍

1. 任何一个节点都可写可读,都是主节点，是真正意义上的并发，这种部署对于高并发有很好的的处理能力。
2. 通过Group Replication Protocol协议及Paxos协议，形成的整体高可用解决方案
3. 只要突然故障的节点数量不太多，这个多主模式就能继续可用。
4. 优点：性能比单主模型高
5. 缺点：
   1. 必须要深入理解组复制的理论
   2. 限制较多，其一致性、安全性还需要多做测试。

3.2、选举

不存在选举主节点，因为所有节点都是主节点。

3.3、缺陷

1. 不支持SERIALIZABLE事务隔离级别
2. 不能完全支持级联外键约束。

3.4、事务冲突检查

1. 增加了certify的概念,负责检查事务是否允许提交，是否与其它事务存在冲突。
2. Group Replication是由多个节点共同组成一个数据库集群，每个节点都可以单独执行事务，但是readwrite(rw)的操作只有在组内验证后才可以commit，Read-only (RO)事务是不需要验证，可以立即执行，当一个事务在一个节点上提交之前，会在组内自动进行原子性的广播，告知其他节点变更了什么内容，执行了什么事务，然后为该事务建立一个全局的排序，最终，这意味着所有的服务器都以相同的顺序接收相同的事务集。因此，所有服务器都按照相同的顺序应用相同的变更集，因此它们在组中保持一致。

4、复制原理

节点一个事务提交时，会将事务修改记录相关的信息和事务产生的BINLOG事件打包生成一个写集(WRITE SET)，将写集发送给所有节点，并通过至少N个节点投票通过才能事务提交成功。

5、故障检测

5.1、MGR成员相互监听

MGR的成员之间会互相发送检测消息，当 服务器A 在给定的时间内没有接收到 服务器B 的消息时，会发生超时并产生怀疑。认为 服务器B 可能挂了

5.2、投票

如果MGR的成员 同意怀疑可能是真的，这意味着组中其他成员采取协调一致的决定来驱逐 服务器B。

5.3、注意

在网络不稳定的情况下，成员之间可能会多次断开和重连，极端情况，一个组最终可能会将所有成员标记为驱逐，之后组不复存在，必须重建。

为了应对这种情况，从 MySQL 8.0.20 开始，组通信系统(GCS)跟踪已经被标记为驱逐的成员，然后决定是否有大多数成员将其标记为怀疑。这样可以确保至少有一个成员留在主中，当被剔除的成员实际上已经从组中删除时，GCS 将删除该成员被剔除的记录，以便该成员可以在恢复之后重新加入组。

6、流控

在多主模式中，速度较慢的成员还可能积累过多的事务以进行认证和应用，可能会导致冲突、认证失败或者读到过期数据等风险。为了解决这些问题，可以激活和调优 Group Replication 的流控制机制，以最小化快成员和慢成员之间的差异。

6.1、loose_group_replication_flow_control_mode = DISABLED

 
1. 关闭流控机制
2. 默认：QUOTA: 开启
3. DISABLE：关闭流控机制
4. 建议：由于判断机制不太准确，并且性能损耗严重，建议DISABLE  

6.2、触发流控的两种情况

6.2.1、证书队列中等待的事务数超过 下面设置的值

# 触发流控的待认证队列长度
group_replication_flow_control_certifier_threshold=25000

6.2.2、应用程序队列中等待的事务数超过 下面设置的值

# 触发流控的待执行队列长度 
group_replication_flow_control_applier_threshold=25000