mysql 的mgr集群

mysql 的mgr集群

 

 

http://wubx.net/mgr%E7%9B%91%E6%8E%A7%E5%8F%8A%E4%BC%98%E5%8C%96%E7%82%B9/

 

MGR调优参数
由于基本复制结构，全部的数据复制，仍是逻辑的重放，因此优化也是复制优化点。
更改：

slave_parallel_type -> LOGICAL_CLOCK

加强sql_thread个数：

slave_parallel_workers -> 2-8

若是CPU瓶颈，网络没问题，减小CPU压缩：

group_replication_compression_threshold = 1000000 -> 2000000

由原来的1M变成2M，再进行压缩（主要针对大事务传述优化）

group_replication_bootstrap_group ->  off

 

---

流控(flow control)
在MGR中若是节点落后集群中其它成员太多，就会发起让其它节点等他完成在作的控制，这个叫流控。
当启用： group_replication_flow_control_mode=QUOTA 是表示启用流控。 流控默认经过两个参数控制：

group_replication_flow_control_applier_threshold (默认: 25000)
group_replication_flow_control_certifier_threshold (默认: 25000)

也就说默认延迟在25000个GTID时，会对整个集群Block住写操做。
固然，也能够容许，节点延迟，就如同咱们主从结构，从节点延迟，不往上面发请求就能够。
关闭Flow control：

set global group_replication_flow_control_mode='DISABLED';

提示： 关闭流控制，注意查看是否是存在延迟，若是延迟，自已控制阀值不向上面发请求便可。 多IDC结构的MGR，建议关闭流控。

 

 

---

性能监控
复制是否是存在延迟：
对比得到到的GTID和本节点执行的GTID是否是一致：
获取的GTID：

SELECT Received_transaction_set FROM performance_schema.replication_connection_status WHERE Channel_name = 'group_replication_applier';

本节点执行的GTID：

select @@gtid_executed;

远程获取的GTID - 本节点执行的GTID = 延迟的GTID数
本节点执行队列是否是有堆积(大于0表示有延迟）：

select count_transactions_in_queue from replication_group_member_stats where member_id=@@server_uuid;

---

监控点
可用性监控
本节点是否是online:

select member_state from replication_group_members where member_id=@@server_uuid;

当前节点是否是能够写：

select * from performance_schema.global_variables where variable_name in ('read_only', 'super_read_only');

节点是Online表示属于集群中，正常工做。 节点不可写，表示是Single-master中的非Master节点。

 

 

 

 

 

 

 

 

f