Mysql中MGR监控及优化点的示例分析
发布时间：2021-12-31 09:32:02 所属栏目：MySql教程 来源：互联网
导读：这篇文章主要介绍Mysql中MGR监控及优化点的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！ 监控点 可用性监控 本节点是不是online: select member_state from replication_group_members where member_id=@@server_uuid;
|
这篇文章主要介绍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监控及优化点的示例分析”这篇文章的所有内容，感谢各位的阅读！ （编辑：航空爱好网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐