Mysql中MGR监控及优化点的示例分析

这篇文章主要介绍MySQL中MGR监控及优化点的示例分析,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!

目前创新互联公司已为1000多家的企业提供了网站建设、域名、网络空间、网站托管运营、企业网站设计、大城网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。

监控点
可用性监控
本节点是不是online:
select member_state from replication_group_members where member_id=@@server_uuid;
当前节点是不是可以写:
select * from performance_schema.global_variables where variable_name in ('read_only', 'super_read_only');
节点是Online表示属于集群中,正常工作。 节点不可写,表示是Single-master中的非Master节点。

性能监控
复制是不是存在延迟:
对比获得到的GTID和本节点执行的GTID是不是一致:
获取的GTID:
SELECT Received_transaction_set FROM performance_schema.replication_connection_status WHERE Channel_name = 'group_replication_applier';
本节点执行的GTID:
select @@gtid_executed;
远程获取的GTID - 本节点执行的GTID = 延迟的GTID数
本节点执行队列是不是有堆积(大于0表示有延迟):
select count_transactions_in_queue from replication_group_member_stats where member_id=@@server_uuid;

流控(flow control)
在MGR中如果节点落后集群中其它成员太多,就会发起让其它节点等他完成在做的控制,这个叫流控。
当启用: group_replication_flow_control_mode=QUOTA 是表示启用流控。 流控默认通过两个参数控制:
group_replication_flow_control_applier_threshold (默认: 25000)
group_replication_flow_control_certifier_threshold (默认: 25000)
也就说默认延迟在25000个GTID时,会对整个集群Block住写操作。
当然,也可以允许,节点延迟,就如同我们主从结构,从节点延迟,不往上面发请求就可以。
关闭Flow control:
set global group_replication_flow_control_mode='DISABLED';
提示: 关闭流控制,注意查看是不是存在延迟,如果延迟,自已控制阀值不向上面发请求即可。 多IDC结构的MGR,建议关闭流控。

MGR调优参数
因为基本复制结构,所有的数据复制,还是逻辑的重放,所以优化也是复制优化点。
更改:
slave_parallel_type -> LOGICAL_CLOCK
增强sql_thread个数:
slave_parallel_workers -> 2-8
如果CPU瓶颈,网络没问题,减少CPU压缩:
group_replication_compression_threshold = 1000000 -> 2000000
由原来的1M变成2M,再进行压缩(主要针对大事务传述优化)

以上是“Mysql中MGR监控及优化点的示例分析”这篇文章的所有内容,感谢各位的阅读!希望分享的内容对大家有帮助,更多相关知识,欢迎关注创新互联行业资讯频道!


网页名称:Mysql中MGR监控及优化点的示例分析
文章来源:http://pwwzsj.com/article/pcejih.html