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，再进行压缩（主要针对大事务传述优化）

建议继续学习：

1. Mysql监控指南    (阅读：19774)
2. 批量添加主机到cacti+nagios的监控报警系统中    (阅读：13253)
3. 我常用的主机监控shell脚本    (阅读：11486)
4. 7 天打造前端性能监控系统    (阅读：10083)
5. 如何监控HP服务器硬件状态    (阅读：9089)
6. Cacti 添加 Nginx 监控    (阅读：8894)
7. Linux下三种常用的流量监控软件对比    (阅读：8667)
8. Cacti 添加 Memcached 监控    (阅读：8095)
9. Cacti 添加 Apache 监控    (阅读：7552)
10. 你应该知道的16个Linux服务器监控命令    (阅读：6817)