应选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 能力不均、网络抖动、大事务混杂小事务时会暴露隐性冲突——这些情况，只看文档参数说明根本发现不了。
