一 简介:MGR集群架构的调优
二 过程:本文将从各个角度来具体阐述下
三 硬件
1 硬件选择相同配置的服务器,磁盘,内存,cpu性能越高越好
四 网络
1 0丢包和最好万兆网卡
五 MGR本身
MGR本身需要非常好的网络情况,主要有以下几点需要
1 内部集群的心跳检测
2 写集合的广播和发送验证
3 binlog的内部传输
六 相关优化参数
1 report_host 直接绑定真实IP,而非机器域名,减少DNS解析问题,还可以避免因为解析错误导致的集群本身问题
2 group_replication_compression_threshold 事务压缩参数,我们这里设置了131072(128K)
参数解析: 1 此参数针对的binlog的内事务的压缩,采用的是LZ4压缩算法.(LZ4能很好的支持多线程环境，获得更高的压缩和解压速度)
2 大于阈值的有效负载的事务被压缩,经过压缩的binlog_event事务在传输到节点后会进行解压缩
3 此参数能有效减少网络带宽的压力,带来整体性能的提升
4 此参数默认为1M,启用压缩模式,而且是read_only.所以需要预选配置好
3 group_replication_transaction_size_limit 限制事务大小参数,我们这里设置了20971520(20M)
参数解析:1 此参数是针对事务整体生成的binlog_event量大于阈值的情况,限制事务执行
2 大事务无论在PXC还是在MGR环境下都可能对整个集群造成非常严重的影响。
3 一旦事务本身超过阈值就会程序端报错,error日志也会有体现
4 此参数默认2G,建议结合线上环境和研发进行讨论自定义,尽量不要太大
4 group_replication_unreachable_majority_timeout 节点检测参数 我们这里设置了5S
参数解析: 1 当节点存在不可达状态时等待5S就不再等待,防止影响集群服务,如果仍保持UNREACHABLE，则将节点置为ERROR状态.默认无限等待
2 不要让有问题的节点一直呆在集群,及时提出,防止因为网络和其他问题导致整个集群性能问题
3 节点一旦被踢出就不会在集群的视图里
5 并行复制相关参数
参数解析: 1 5.7的并行复制极大的加快了队列应用的速度,强烈建议开启
6 group_replication_flow_control_mode 是否开启流控控制
group_replication_flow_control_certifier_threshold 开启流控控制应用队列参数 默认25000个
group_replication_flow_control_applier_threshold 开启流控控制应用队列参数 默认25000个
参数解析:1 一旦出现延迟（默认延迟25000个事务），则启动流量控制（Flow Control），每个周期性能衰减当前的10%,直到集群不可用（但集群节点状态为online），单个节点慢整个集群全慢。
2 默认是开启流控控制的,值为QUOTA/DISABLE是关闭流控
3 对于单主模式下,其实主要调节下应用流控相关参数即可,因为不会发生检测冲突.此参数建议根据环境进行相应调节(无调节经验)
六 整体过程
我们再来看下单主模式下整体的过程
1 写节点接收事务,应用事务,生成binlog,缓存在cache中,然后根据主键,binlog_cache等相关信息生成WS集合
2 写节点通过协议广播并顺序推送WS到其他成员进行验证
3 其他成员验证成功后,写节点binlog进行刷新binlog日志,返回客户端commit ok,事务提交成功
4 其他成员验证成功后,写入relaylog中
5 其他成员读取relaylog,加入应用队列.应用完成,然后写入本地binlog中 整个集群达到一致
七 总结
通过整个过程我们发现,网络对于MGR整体集群非常重要,然后就是读节点的应用队列消费的速度.最后就是大事务导致的集群阻塞
八 后序
本人仅代表个人观点,如有问题,可以留言.我会第一时间进行修改