零 總攬
1 寫集合 2 沖突驗證機制 3 監控 4 大事務影響 5 流控設置 6 網絡抖動影響 7 新節點的初始化加入機制
一 新主選擇機制
1 當主節點宕掉，自動會根據服務器的server_uuid變量和group_replication_member_weight變量值，選擇下一個slave誰作為主節點，group_replication_member_weight的值最高的成員被選為新的主節點，
2 在group_replication_member_weight值相同的情況下，group根據數據字典中 server_uuid排序，排序在最前的被選擇為主節點
3 如果原主需要下線進行維護,那么可以直接stop復制,如果有目標新主,預先調整好權重即可.新主會進行識別
二 集群節點數量
1 一旦集群故障的節點超過閾值,整個集群變會被掛起,成為只讀的狀態,比如 3個節點,一旦掛掉2個 就會導致集群只讀
計算方式 2n+1=total, n為故障節點的閾值
三 集群節點狀態
ONLINE 表示該節點可正常提供服務
RECOVERING 表示當前節點正在從其他節點恢復數據(也有可能處於錯誤狀態)
OFFLINE 表示GR插件已經加載，但是該節點不屬於任何一個GR組
ERROR 表示節點在recovery階段或者從其他節點同步狀態中出現錯誤
UNREACHABLE 表示節點處於不可達狀態，無法與之發生網絡通訊
只有ONLINE和RECOVERING兩種狀態會在集群中得到同步
四 集群節點延時
組復制的延遲對集群是有影響的，一旦出現延遲（默認延遲25000個事務），則啟動流量控制（Flow Control），每個周期性能衰減當前的10%,直到集群不可用（但集群節點狀態為online），單個節點慢整個集群全慢。
五 寫集合
關於wriset你需要知道的幾個事情
1 writeset本身是由vector和set集合基本單位(c++)的集合,內部都是hash成員
2 事務語句生成所有writeset內部成員,然后由這些成員構成writeset集合
3 事務整體的wrieset大概包含以下,然后內部進行hash
1 主鍵的信息和值 2 庫表的信息 3 輔助索引的信息和值
4 writeset的生成是在binlog刷到os disk之前,writeset+binlog cache+server_uuid+gtid_executed等其他信息, 發送到各個節點進行沖突驗證
5 對於 5.7來說,每個唯一鍵都會生成一個Writeset
6 但是如果是大事物上千萬的表在一個事物里面做修改那么內存可能消耗會上百兆,這也是為什么MGR需要避免大事務的原因之一,哪怕生成大量的writeset也是占用內存的,更不用說發送驗證和應用了
六 整體過程
0 MGR 在主節點執行事務,形成集合(包含寫集合,binlog event和其他一些信息)並且按照順序廣播發送到各個成員
1 從節點進行沖突驗證,驗證通過后
2 主節點進行binlog寫入提交,反饋給客戶端
3 從節點寫入relay-log,然后進入應用隊列
4 由注冊的復制通道group_replication_applier channel完成事務並行回放。
七 大事務對MGR本身的影響
1 在生成階段,大事務本身在主節點執行就很久,影響的行數非常多,就會生成大量的writeset和binlog,writeset和binlog都會占用服務器的本身資源
2 在傳輸階段,這樣很明顯會影響節點之前的網絡傳輸性,比如造成網絡抖動,可能造成節點脫離的風險
3 在事務沖突驗證階段: 也同樣會消耗節點的大量資源
4 在事務應用階段,1 消耗節點的資源 2 可能造成后續的事務無法應用,造成延時,拖慢整個集群的性能
參數限制:MGR能對生成binlog大於多少的事務進行限制,直接拒掉,建議采用設置
最后建議: 請不要使用大事務
八 MGR事務檢測機制-沖突檢測數據庫
1 沖突檢測數據庫=>hash_map
key:是數據庫名+表名+主鍵id經過哈希后的字符串
value:Gtid_set_ref對象（是gtid_set的超集），包含了主鍵版本信息（表示為更新了該主鍵id的最后一個事務執行完后的系統gtid_executed）
4 當啟用檢測模式時,只有事務的snapshot_version不是沖突檢測數據庫中對應主鍵版本的子集時，事務才能夠判定為認證通過（多寫/主從切換)
九 沖突檢測數據庫的問題
0 沖突檢測數據庫=>hash_map,沖突檢測數據庫的作用有2個 1是驗證是否沖突,決定事務提交還是回滾 2 為認證通過的事務分配gtid,決定事務的並行回放行為,含有seq_number,只有通過沖突檢測和並行回放過的事務才能被清理
1 如果一個事務在各個節點都已經執行或回放了，那么該事務的writeset信息就不需要繼續緩存在沖突檢測數據庫中。MGR會對其進行周期性清理(1分鍾一次)。先廣播各自節點的gtid_executed信息，然后收集其他節點的gtid_executed信息取交集stable_gtid_set，再基於這個交集來清理無用的信息
2 在某些較極端的情況下，比如流控參數設置較大，或每個事務writeset較多，或gtid_set較大時。writeset清理不及時也容易導致沖突檢測數據庫占據過多內存空間，導致mysqld OOM
3 不僅僅多主模式，在單主模式的新主切換過程中，也需要進行事務認證,應用沖突檢測數據庫
4 每個事務進行認證的時候都會攜帶執行該事務時節點的gtid_executed，也就是事務的版本snapshot_version，以及事務所修改的記錄信息writeset。通過這兩部分信息跟沖突檢測數據庫里的信息進行比對，就能確定該事務應該提交還是回滾
十 關於集群的補充
1 當 group_replication_bootstrap_group被顯式設為ON時 start group_replication執行的操作是創建一個新的集群,而當group_replication_bootstrap_group被顯式設為OFF時,group_replication是加入已有的集群,所以我們在新創建的集群時初始化主必須顯示設置新集群,而在從節點加入時,直接執行即可.所有節點在配置文件中group_replication_bootstrap_group被設置為OFF
2 監控項重點
1 全局性視圖 replication_group_members
2 replication_connection_status
1 CHANNEL_NAME: group_replication_applier 獲取應用進程,重點是接收到的所有事務GTID
2 CHANNEL_NAME: group_replication_recovery 此通道監控恢復進程
3 監控要點
1 集群角色是否正常 ( status是否為online role是否為read_only)
2 延時監控(已經執行過的gtid集合對比收到的gtid集合相差則為延時)
3 一個健康的集群所有的GTID集合應該是一致的,在0延時的情況
十一 新節點什么情況下會發生加入失敗情況
1 新節點本身已有自身事務,日志會有相應提示
This member has more executed transactions than those present in the group.而同步的時候會攜帶已執行的GTID_EXECUTED集合,通過本地新節點的GTID_EXECUTED對比發現並不在集合里,故而報錯
2 新節點網段並不在iplist規定的網段內
3 新節點需要的全量日志在主庫已被刪除,recovery通道會報錯 日志會有相應提示 GET ERROR 12306
4 當原主切換后,重新加入集群的操作
1 分別設置 read_only super_read_only 為ON 2 重新加入集群 3 觀察狀態和數據同步
十二 高可用集群
1 軟件 https://github.com/gaopengcarl/HAIPMGR
2 運行環境: 每個節點都需要進行啟動該腳本,因為該軟件只會檢測本地IP
3 相關原理: 1 檢測VIP 2 檢測mysql進程 3 檢測 online 和 read_only
4 經測試能正常切換,推薦使用這個代替proxysql,proxysql本身是有性能損耗的