SQL Group Replication 的 flow control 与成员权重配置模板

应选quota模式，disabled会关闭流控导致从库延迟雪崩；权重建议设50–100避免被优先牺牲；flow_control_mode为只读变量，需重启或重载组复制生效。

flow_control_mode 选 QUOTA 还是 DISABLED？

默认的 flow_control_mode=QUOTA 是唯一真正起作用的模式；设成 DISABLED 就等于关掉流控，主库写入压力大时，从库延迟会雪崩式增长，不是“更自由”，而是放弃保护。

实操建议：

• QUOTA 模式下，flow_control_period（默认 1 秒）和 flow_control_applier_threshold（默认 25000）共同决定节流频率和触发阈值，别只调一个
• 若集群长期处于高延迟状态，先查 performance_schema.replication_group_member_stats 里的 COUNT_TRANSACTIONS_IN_QUEUE 和 COUNT_TRANSACTIONS_CHECKED，再调参，别盲目加大 flow_control_applier_threshold
• DISABLED 只应在压测或临时故障隔离时手动设置，且必须配合监控告警，否则延迟破万都可能没人发现

group_replication_member_weight 怎么设才不被踢出？

这个权重不参与选举 leader，只影响流控时的“配额分配”：权重越高的节点，在流控开启时被允许保留更多事务积压，从而降低被强制限速的概率。

常见错误现象：group_replication_member_weight=0 的节点在流控启动后最先堆积事务，接着触发 member state: UNREACHABLE 或直接被驱逐——不是网络问题，是它被流控“优先牺牲”了。

实操建议：

• 所有节点权重建议设为 50–100 之间的整数，避免出现 0 或远高于其他节点（比如 500），权重差超过 5 倍就容易导致配额倾斜
• 不要用权重“模拟主从角色”，Group Replication 没有固定主库，member_weight 对 group_replication_bootstrap_group 或 group_replication_start_on_boot 都无影响
• 修改后需执行 SET GLOBAL group_replication_member_weight = N 并确认 performance_schema.replication_group_members 中已更新，仅改配置文件不生效

flow_control_mode 动态切换为什么没反应？

因为 flow_control_mode 是只读变量，不能用 SET GLOBAL 修改。试图执行 SET GLOBAL flow_control_mode='DISABLED' 会直接报错 Error 1238 (HY000): Variable 'flow_control_mode' is a read only variable。

正确做法只有两个：

• 停节点 → 修改配置文件中的 group_replication_flow_control_mode → 重启实例
• 或用 STOP GROUP_REPLICATION; START GROUP_REPLICATION; 触发重载（前提是配置已写入 my.cnf 并被 mysqld 读取）

注意：MySQL 8.0.27+ 支持在线禁用流控（通过 group_replication_disable_flow_control=ON 动态变量），但该变量仅控制开关，不改变 flow_control_mode 的只读属性。

权重和流控参数上线前必须验证什么？

最常被跳过的一步：没在同构环境里跑过真实负载下的 INSERT ... select 或批量 UPDATE，就直接上生产。

验证重点不是“能不能启”，而是“压到什么程度开始限速、哪个节点先卡住、卡住后恢复是否平滑”：

• 用 SYSBENCH 或自建脚本模拟持续写入，观察 performance_schema.replication_group_member_stats 中 APPLYING_TRANSACTION_LOW_WATER_MARK 和 COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE 的变化斜率
• 人工触发一次流控（比如临时调低 flow_control_applier_threshold 到 1000），看权重低的节点是否在 2–3 秒内事务队列激增，同时检查 error log 有没有 Flow control: throttling member 日志
• 确认备份节点的 group_replication_recovery_complete_at 时间戳是否持续推进，避免因权重配置不当导致 recovery 卡在某个 GTID 位置不动

权重和流控不是设完就稳的配置，它们在节点 IO 能力不均、网络抖动、大事务混杂小事务时会暴露隐性冲突——这些情况，只看文档参数说明根本发现不了。