Mysql MGR監控及最佳化點

監控點
可用性監控
本節點是不是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節點。

效能監控
複製是不是存在延遲：
對比獲得到的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;

流控(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，建議關閉流控。

MGR調優引數
因為基本複製結構，所有的資料複製，還是邏輯的重放，所以最佳化也是複製最佳化點。
更改：
slave_parallel_type -> LOGICAL_CLOCK
增強sql_thread個數：
slave_parallel_workers -> 2-8
如果CPU瓶頸，網路沒問題，減少CPU壓縮：
group_replication_compression_threshold = 1000000 -> 2000000
由原來的1M變成2M，再進行壓縮（主要針對大事務傳述最佳化）