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 [email protected]@server_uuid;
監控點
可用性監控
本節點是不是online:
select member_state from replication_group_members where [email protected]@server_uuid;
目前節點是不是可以寫：
select * from performance_schema.global_variables where variable_name in ('read_only', 'super_read_only');
節點是Online表示屬于叢集中，正常工作。 節點不可寫，表示是Single-master中的非Master節點。
f