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