MGR监控及优化点

mysql group replication官方在监控及优化方面文档较少,为了在教学中方便使用,总结如下:

监控点

可用性监控

本节点是不是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,再进行压缩(主要针对大事务传述优化)

备注: 需要MGR安装文档及更多交流 入QQ群: 579036588 联系群主。

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.