MGR管理

一、选主算法

所有节点参与，版本号>权重>uuid

1) 版本号：版本小的优先成为primary，因为大的版本可以兼容版本小的

    -- 小于8.0.16，按照版本号排序

    -- 大于8.0.17 ，按照补丁版本号排序

2）节点权重，默认50,越⾼越靠前，最容易成为主

show variables like '%group_replication_member_weight%';

3）server_uuid:越⼩越在前

 

二、版本混⽤

⽀持5.7和8.0混⽤

- 8.0可以加⼊5.7

- 5.7⽆法加⼊8.0

⽀持在线修改协议版本

 

三、滚动升级

- 先升级从节点

- 增加新节点,替换⽼节点

- 最后仅剩下PRI节点

- 停掉主节点,⾃动切换新节点/⼿动切换新节点

- 原主节点升到⾼版本

 

四、数据同步

4.1 MGR 架构原理

 

 

在2N+1个节点组成的单主模式组复制集群中，主库上一个事务提交时，会将事务修改记录相关的信息和 事务产生的BINLOG事件打包生成一个写集(WRITE SET)，将写集发送给所有节点，并通过至少N个节 点投票通过才能事务提交成功。

1.事务操作生成的map event/query event/dml event等写入BINLOG CACHE中(内存)，将Write Set写入到Rpl_transaction_write_set_ctx中(内存)

2. 在事务提交时，具体在MYSQL_BIN_LOG::prepare之后，但是在 MYSQL_BIN_LOG::ordered_commit之前，即事务相关的BINLOG Event还在BINLOG CACHE没有 写入到BINLOG FILE前，将BINLOG CACHE中和Rpl_transaction_write_set_ctx中的数据进行 处理并写入到transaction_msg中

3. 由gcs_module负责发送transaction_msg到各个节点，等待 各节点进行事务认证。
4. 由于transaction_msg中包含BINLOG信息，并在事务认证期间发送给MGR各节点，因此无需等待主节 点的BINLOG落盘后再发送给备用节点。

每个MGR群集中的节点上，都存在IO线程和SQL线程，IO线程会解析transaction_msg获取到BINLOG EVENT并保存到RELAY LOG中，再由SQL线程执行重放到辅助节点上。

 

- 事务写⼊binlog前写进MGR层

- 事务消息通过Paxos全局排序后,给MGR节点

- 在各个节点认证(远程与本地事务是否冲突,对⽐事务版本号新旧)

- 认证通过后本地节点写binlog完成提交

- 远程节点写relay-log后并⾏回访

 

 

 

 

4.2 新成员加⼊

 

1.新成员加⼊,view change

2.⾃动选择donor节点,分布式恢复

3.从donor节点 clone数据进⾏恢复

4.追加恢复clone发起到结束期间新增事务

5.追加完成,事务达成⼀致后,为online状态

 

数据恢复

本地恢复

- 故障恢复初始化,包括线程初始化,group成员初始化

- 启动复制通道,先回放d本地relay log.接⼊MGR层新的Paxos消息⼊队到 Xcomcache（参数group_replication_ message_cache_size,默认⼀个G）
MySQL Cluster(MGR) 
全局恢复

- 选择donor节点,获取缺失事务

- 处理缓存事务

- 所有事务apply,默认完成

-（参数group_replication_recovery_complete_at）

- TRANSACTIONS_APPLIED 代表本地所有缓存事务回放完毕才能加⼊组进⾏服务

- DISABLE:⽆需本地缓存事务回放完毕加⼊组提供服务

- 通知其他节点,本节点上线 #如果TPS很⼤,cache_size超过则失败. 整体

- 节点加⼊或者重新加⼊集群,补差异数据 - ⾃动选择donor接受事务数据

- ⾃动计算事务差距（参数group_replication_clone_threshold）

- 差异少 binlog

- 差异⼤ clone

- ⾃动尝试 retyr_count次

- 完成标记 group_replication_recovery_complete_at #阈值定义group_replication_clone_threshold

- 事务差异未超过,binlog

- 需要事务不存在,使⽤clone

- 两端都要启动clone,且具有backup权限