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）；
所以业务使用之前，一定要先做好测试。