MGR整体架构及特点
single-master
只有一个节点写入，都可以读取
multi-master
每个节点都可以写入和读取
涉及到的概念：
group communication system (GCS)
writeset
membership
cerification info
flow control stats
paxos
MGR一致性读增强
group_replication_consistency (8.0.14引入）
EVENTUAL: 默认
BEFORE： 等待队列中的事务全部执行完
BEFORE_ON_PRIMARY_FAILOVER: 等待新primary执行完队列中事务
AFTER： 等待数据变更在其他所有节点全部被应用
BEFORE_AND_AFTER:
MGR限制
仅支持InnoDB，必须有主健
Binlog 格式: Row，关闭binlog checksum
必须开启GTID
事务隔离级别： READ COMMITTED （没有 gap lock）
大事务限制： group_replication_transaction_size_limit
Multi master模式：避免相同表上不同节点并发执行DDL/DML
集群最大节点； 9 (奇数个数）
MGR数据如何实现数据同步
MGR的数据复制 -> 事务认证
事务认证
冲突检测
certification_info key: xxhash64(索引名称+db名+db名长度+表名+表名长度+构成索引唯一性的每个列的值+值长度) Value 是事务的 gtid_executed
事务分配 gtid
group_replication_gtid_assignment_block_size
事务组提交 （group commit）
MGR数据复制冲突解决
问题：
对于告诉写入的系统 centification_info 会越来愈大，性能会越来越差？
处理办法：
centification_info 引入清理机制
MGR数据复制流控
Flow Control
流控目的
保证集群延迟可控 (对于只读事务不在流控范围之内)
出现流控原因
各节点性能不一致
木桶短板效应
参数
group_replication_flow_control_mode 默认为： quota 开启流控
group_replication_flow_control_period 多久进行一次流控统计，单位：秒
group_replication_flow_control_applier_threshold & group_replication_flow_control_certifier_threshold 事务认证队列中积累超过多少个待认证的事务才触发节点流控
MGR监控点
当前节点是不是在线
select member_state from performance_schema.replication_group_members;
是不是存在延迟
获取到的： select received_transaction_set from performance_schema.replication_connection_status;
已经执行的： select @@gtid_executed
当前队列是不是有积压
select count_transaction_in_queue from performanct_schema.replication_group_member_stats where member_id=@@server_uuid;
当前节点是不是可写
select * from performance_shcema.global_variables where variable_name in ('read_only','super_read_only');
MGR优化方向
运维上
运维基本复制结构，所有的数据复制，还是逻辑的重放，所以优化也是复制优化点。
更改：
slave_parallel_type -> LOGICAL_CLOCK
增强 SQL_THREAD 个数：
slave_parallel_workers -> 2-8
如果CPU瓶颈，网络没问题，减少CPU压缩：
group_replication_compression_threshold = 1000000 -> 2000000
由原来的1M变成2M，再进行压缩（主要针对大事务传输优化）
对于写量毕竟大环境
使用single-master
表结构设计上：减少索引数量，多使用联合索引
内核上
已经尝试： static const int BROADCASE_GTID_EXECUTED_PERIOD = 60>30; //seconds
重要参数：
group_replication_member_expel_timeout (8.0.13+)
(5+X) 秒后，节点从group中移除失恋成员
网络异常 -> 5秒 -> 失联猜测 -> X秒 / UNREACHABLE -> 移除
X 秒内，group无法增加节点，删除节点，选举Primary
group_replication_unreachable_majority_timeout
发生网络分区后，minorty成员X秒内未能恢复连接到majority，进入ERROR
group_replication_exit_state_action (8.0.12+, 5.7.24+)
ABORT_SERVER / READ_ONLY
aplier执行错误 / 与 majority失联 / 网络波动被移除group
group_replication_recovery_complete_at
TRANSACTIONS_CERTIFIED / TRANSACTIONS_APPLIED
group_replication_member_weight
single primary 下， 节点角色不对等情况下有用
相同group_replication_member_weight, 取决于 server_uuid
group_replication_transaction_size_limit (5.7.19+)
限制单个事务最大字节数，可控制网络开销，内存分配，冲突概率
group_replication_compression_threshold
超过X字节后，开启LZ4压缩事务传输，默认1MB
MGR部署架构建议
MySQLrouter + MGR
router： 两个接口 （read, insert）
需要关注一下MySQL的X协议，js相关的相关操作
建议使用ProxySQL替代