一 簡介:今天咱們來聊聊mgr的細節原理相關
二 選擇新主機制
1 當主節點宕掉，自動會根據服務器的server_uuid變量和group_replication_member_weight變量值，選擇下一個slave誰作為主節點，group_replication_member_weight的值最高的成員被選為新的主節點，
2 在group_replication_member_weight值相同的情況下，group根據數據字典中 server_uuid排序，排序在最前的被選擇為主節點
3 調整權重后不能像mongo一樣自動識別進行切換.只能主動觸發故障。
三 新主成員構成
1 一旦集群故障的節點超過閾值,整個集群變會被掛起,成為只讀的狀態,比如 3個節點,一旦掛掉2個 就會導致集群只讀
計算方式 2n+1=total, n為故障節點的閾值
2 單個節點的狀態只有到ERROR時才會被認為是不可用,踢出集群,視圖發生變更
四 視圖成員狀態說明
ONLINE 表示該節點可正常提供服務
RECOVERING 表示當前節點正在從其他節點恢復數據
OFFLINE 表示GR插件已經加載，但是該節點不屬於任何一個GR組
ERROR 表示節點在recovery階段或者從其他節點同步狀態中出現錯誤
UNREACHABLE表示節點處於不可達狀態，無法與之發生網絡通訊
五 寫集合
1 主鍵在MGR中主鍵是有着極其重要的地位，是判斷是否沖突的重要依據,所以規定表必須有主鍵
2 寫集合信息會封裝進Transaction_context_log_event，同其他binlog event信息一起發送給其他節點
六 本身限制
1 僅支持InnoDB表，並且每張表一定要有一個主鍵，用於做write set的沖突檢測；
2 目前一個MGR集群最多支持9個節點
3 不支持外鍵於save point特性，無法做全局間的約束檢測與部分部分回滾
4 二進制日志不支持binlog event checksum
5 對大事務的限制
七 總結
本文章只代表個人觀點,有問題及時聯系我,此文章會持續進行補充