MySQL 高可用之 MGR

Posted 2022-07-15 yujiaershao

 

 

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替代

　　如果为了性能 ： Single-master

　　使用方便： Multi-master （单点写入，多点读取）