这篇文章主要介绍Mysql中MGR监控及优化点的示例分析,文中介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们一定要看完!监控点
可用性监控
本节点是不是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中Buffered and Unbuffered queries及pdo非缓存查询的示例分析
这篇文章主要为大家展示了“MySQL中Buffered and Unbuffered queries及pdo非缓存查询的示例分析”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让小编带领大家一起研究并学习一下“MySQL中Buffered and U…