MGR Flow Control
流控的目的
保证集群延迟可控(对于只读事务不在流控范围内)
出现流控原因
各节点性能不一致
木桶短板效应
参数
group_replication_flow_control_mode 默认为: quota开启流控
group_replication_flow_control_period 多久进行一次流控统计,单位:秒
group_replication_flow_control_applier_threshold&group_replication_flow_control_certifier_threshold
事务认证队列中积累超过多少个待认证的事务才触发节点流控
MGR监控点
当前节点是不是在线
select member_state from performance_schema.replication_group_members where MEMBER_HOST=@@hostname;
是不是存在延迟:
获取到的 SELECT Received_transaction_set FROM performance_schema.replication_connection_status
已经执行的: select @@gtid_executed;
当前队列是不是有积压
select count_transactions_in_queue from
performance_schema.replication_group_member_stats where member_id=@@server_uuid;
当前节点是不是可写
select * from performance_schema.global_variables where variable_name in (read_only , " super_read_only");
MGR优化方向
运维上:
因为基本复制结构,所有的数据复制,还是逻辑的重放,所以优化也是复制优化点。
更改:
slave_ parallel type -> LOGICAL_CLOCK
增强sql thread个数:
slave_ parallel_workers -> 2-8
如果CPU瓶颈,网络没问题,减少CPU压缩:
group_replication_compression_threshold = 000000 -> 2000000
由原来的1M变成2M,再进行压缩(主要针对大事务传述优化)
对于写量比较大环境
使用single-master
表结构设计上:减少索引数量,多使用联合索引
内核上:
可以偿试
static const int BROADCAST_ GTID_ EXECUTED_ PERIOD =60->30; //seconds
重要参数
group_ replication_member_ expel_timeout (8.0.13+)
(5+X)秒后,节点从group中移除失联成员
网络异常> 5秒->失联猜测-> X秒/ UNREACHABLE ->移除
X秒内,group无法增加节点,删除节点,选举Primary
group replication unreachable majority timeout
发生网络分区后,minority成员X秒内未能恢复连接到majority, 进入ERROA
group_ replication exit _state action (8.0.12+, 5.7.24+)
ABORT_ SERVER/ READ ONLY
Applier执行错误1与majority失联1网络波动被移除group
group replication recovery. complete at
TRANSACTIONS_ CERTIFIED / TRANSACTIONS_ APPLIED
MGR架构特点
MGR一致性读增强
group_replication_consistency (8.0.14引入)
EVENTUAL: 默认
BEFORE:等待队列中的事务全部执行完
BEFORE_ON_ PRIMARY_FAILOVER:等待新primary执行完队列中事务
AFTER:等待数据变更在其他所有节点全部被应用
BEFORE AND AFTER 性能最差
网友评论