my37_MGR流控对数据库性能的影响以及MGR与主从的性能对比

mysql> show variables like 'group_replication_flow_control_applier_threshold';
+--------------------------------------------------+----------+
| Variable_name                                    | Value    |
+--------------------------------------------------+----------+
| group_replication_flow_control_applier_threshold | 30000000 |
+--------------------------------------------------+----------+
1 row in set (0.00 sec)

mysql> show variables like 'group_replication_flow_control_certifier_threshold';
+----------------------------------------------------+----------+
| Variable_name                                      | Value    |
+----------------------------------------------------+----------+
| group_replication_flow_control_certifier_threshold | 30000000 |
+----------------------------------------------------+----------+
1 row in set (0.00 sec)

16：05至16:10这段时间，做了主从转MGR的操作，并开了流控，流控的具体设置为上面的显示，之前测试这个3千万，相当于没有流控，性能接近于主从

性能突然下降近一半，吓得我立即咨询业务是否受到了影响，还好是没有受到影响；

16:10是我禁用了流控，数据库处理能力立即上升，之后恢复到和之前主从同一水平上

set global group_replication_flow_control_mode='DISABLED';

由此看来，将流控设置到一个很大的值和完全关闭流控，在性能上还是有很大差别的。

下面是MGR禁用流控后，切主从的过程

批量脚本开始运行，

第1部分，是MGR结构，禁用了流控，开始后从kafka到mysql的正常业务数据就快速积压，节点延迟开始加大

第二部分是MGR结构切换到主从结构，kafka积压速度开始下降，节点延迟开始减小

第三部分是批量脚本停止后，写节点压力速度下降，从库还在追加数据，kafka积压数据速度消失

下面是kafka积压数据曲线图

MGR的性能的确不如主从，关闭流控后，性能有所提升，但还是无法与主从相比（mysql版本5.7.24）；

所以业务使用之前，一定要先做好测试。