MGR知識點：
0、
MySQL的並行複製多線程複製MTS(Multi-Threaded Slaves)
1、mysql組複製提供了一種server間協調機制的分佈式state machine複製，組中的server成員自動地進行協調。
2、SMR
state machine replication(狀態機複製)是一種容錯服務的一種常規方法，主要通過複製服務器，並協調客戶端和服務器鏡像間的交互達到目標。這個方法也同事提供了理解和設計複製管理協議的一套基本框架。
Sate machine replication(SMR)狀態機複製用於分佈式系統的容錯處理。通過增加數據副本的數量提高系統的可靠性和可用性。狀態機複製是由一系列的進程組成，進程包括無限多個客戶端進程C={c1,c2…}和有限個服務器進程S={s1,s2…sn}。任何時候，服務器進程的處於正常狀態，即系統不存在拜占庭將軍問題。
四個特性：
1、共識(agreemnet):如果某臺正確的服務器提交了了一個請求R，則所有正確的服務器最終也會提交R
2、有效(validity):如果某臺正確的服務器提出了一個請求R，則所有正確的服務器將最終提交R
3、完整(integrity):任何給定的請求R最多隻被每臺正確的服務器提交一次，並且僅當R在之前被提出。
4、完全有序(total order):如果兩臺正確的服務器S1和S2都提交了請求R1和R2,則S1在R2之前提交R1，當且僅當S2在R2之前提交R1
SMR的架構分爲：
- 執行層(執行請求)
- 共識層(Paxos，實現共識)
- 消息層(負責接收來自客戶端的請求)
SMR實現方式：
1、串行SMR
2、pipelined SMR
3、SDPE是Sequential Delivery-Parallel Execution SMR即串行提交，並行執行SMR
參考地址:https://zhuanlan.zhihu.com/p/30043911
3、通信協議
組通信協議：該協議通過Paxos算法實現組複製中保證數據一致性複製的關鍵組通信系統引擎，該協議保障了故障檢查機制，組成員服務的安全和消息的完全有序傳遞
4、共識算法、Paxos
https://zhuanlan.zhihu.com/p/31780743
5、加入節點操作流程
流程：
一個節點請求加入group ----> 根據配置的seeds參數與group的seeds其中一個成員建立TCP連接 ----> 該種子節點根據自己的group_replication_ip_whitelist的的白名單是否允許新節點加入(MGR默認不限制新節點的ip) ----> 連接建立成功 ----> 新節點發送加入請求 ----> 該種子節點廣播視圖變化的消息給所有節點(包括自己) ----> 各個節點收到消息視圖修改切換 ----> 每個節點都會廣播一個狀態交換消息，每個小環消息包含節點的當前狀態和信息 ----> 各個節點開始接受其他節點廣播消息並更新本地成員列表。---->完成視圖切換 ----> 新節點加入group，只是該成員可以接收到group中通過Paxos協議達成共識的消息,並不意味着可以成爲ONLINE,原因是新成員還需要進行數據同步，建立正確的數據版本(recovery_module->start_start_recovery) ----> 執行Paxos協議消息，向用戶提供訪問服務。
狀態交換：狀態交換與事務數據包採用Paxos協議發送，當收到所有成員的狀態消息時，通信模塊將完整的新視圖封裝爲數據包group中的每個節點基於MGR的通信模塊將其返回給全局事務認證模塊的消息隊列。
視圖數據包：視圖數據包通過Paxos放入消息隊列，那麼各節點依次處理消息隊列中的數據包時就能夠發現視圖數據包，將視圖數據包封裝爲view_change_log_event(vcle)後寫入relay log文件中，group_replication_applier通道的並行複製線程讀取relay log 中的vcle，並將其寫入到Binlog文件中。而binlog文件中的事務就被vcle劃分爲多個區間，每個區間都代表一個視圖。vcle中包含viewid和用於進行全局事務認證模塊進行事務認證的衝突檢測數據庫。基於vcle，我們可以把節點上線前的過程劃分2個階段，分別爲：前一個視圖數據恢復和本視圖緩存事務執行。第一階段又分爲本地恢復和全局恢復。
6、故障恢復實現
MGR正常運行時，節點間通過Paxos歇息傳輸數據，異地事務經過認證後寫入relay log中，由group_replication_applier通道的複製線程複製回放，當有節點加入Group時，需要用到另一個複製通道group_replication_recovery,它是一個傳統的Master-Slave異步複製通道。
MGR故障恢復由節點的故障恢復單獨的恢復線程執行。
注：5、6 來源：https://zhuanlan.zhihu.com/p/40627399
7、單主模式、雙主模式
單主模式：
loose-group_replication_single_primary_mode=true
loose-group_replication_enforce_update_everywhere_checks=false
雙主模式：
loose-group_replication_single_primary_mode=false
loose-group_replication_enforce_update_everywhere_checks=true
8、round-Robin 算法
Round-Robin即輪詢算法。
輪詢調度算法的原理是:每次把來自用戶的請求輪流分配給內部中的服務器。如：從s1…sn(n是內部服務器的個數)。
輪詢調度算法無需記錄當前所有連接的狀態，所以它是一種無狀態調度。
輪詢調度算法假設所有服務器處理能力均衡，不考慮服務器的當前連接數和響應速度，很容易造成服務器間的負載不均衡，因此出現了權重輪詢算法。
權重輪詢算法：是基於輪詢算法改進而來的。根據服務器的不同處理能力，給每個服務器分配不同的權值，使其能夠承受相應權值數的服務請求，即權重輪詢算法(weighted round-robin)。
8、MGR數據提交流程
MGR模式下，事務完成在引擎層perpare，寫Binlog之前會被mysql的預埋鉤子HOOK before_commit()攔截，進入到MGR層，將事務封裝成消息通過Paxos一致協議(consensus)進行全局排序後發送給MGR各個節點，在各節點上獨自進行認證(certifiy)。認證通過後，本地節點寫binlog完成提交。其他節點寫relay-log，由註冊的複製通道group_replication_applier channel完成事務並行回放。
MGR衝突檢查機制：基於記錄版本的事務認證機制，在內存中維護衝突檢查數據庫，每個節點獨立進行衝突檢查，規則相同，結果一樣。
https://zhuanlan.zhihu.com/p/67496623
https://zhuanlan.zhihu.com/p/67490476
9、Paxos的事務消息封裝了哪些信息？
a、Transaction_context_log_event
- 事務節點server_uuid
- 事務執行時的節點gtid_executed信息snapshot_version
- 執行事務的線程thread_id
- 事務gtid是否已存在gtid_specified
- 事務所修改的記錄集的主鍵列表write_set
b、Gtid_log_event
- 事務節點server_id
- 事務是否爲DML
- 事務組提交信息last_commited
- 事務組提交信息sequence_number
- 事務是否包含非row格式日誌may_have_sbr_stmts
c、log_event_group 事務數據
- query_log_event:"Begin"
- Row_log_event:write/update/delete
- .....
- Xid_log_event
注意：a僅用於認證不寫入Binlog(此信息是在內存中的衝突檢查數據庫中,用於衝突檢查)，而b、c、會寫入日誌。
10、MGR事務全局排序(Paxos全局排序)
事務在MGR中進行認證前，會先進入全局排序，即consensus階段。這個階段是把事務認證所需要的信息收集並封裝起來通過Paxos協議進行廣播。
11、mencius 算法
mencius是paxos算法的變種。
Mencius的目的是減少Paxos主節點負載，提高吞吐量
https://zhuanlan.zhihu.com/p/26013382
https://www.usenix.org/legacy/event/osdi08/tech/full_papers/mao/mao.pdf
http://muratbuffalo.blogspot.com/2010/10/mencius-building-efficient-replicated.html
12、pipeline機制
13、事務認證
事務認證模塊建立一個基本的認識：事務認證模塊由衝突檢測數據庫、事務gtid分配器和事務組提交信息分配器等三部分組成
sequence_number即爲事務的last_commited
group commit:last_commited和 sequence_number
參考源碼地址：
https://github.com/mysql/mysql-server/blob/8.0/plugin/group_replication/src/certifier.cc
https://github.com/mysql/mysql-server/blob/8.0/plugin/group_replication/include/certifier.h
https://zhuanlan.zhihu.com/p/38456119
https://zhuanlan.zhihu.com/p/41175310
https://mysqlhighavailability.com/the-king-is-dead-long-live-the-king-our-homegrown-paxos-based-consensus/
14、MGR實踐的注意
衝突檢查數據庫是運行在內存裏的，記錄越少，佔用內存越少，節點延遲越小，所以合理設置MGR的節點間流控制參數。
- 在集羣中有節點重建，其gtid_excuted會落後其他節點，導致其他節點的衝突數據庫無法清理而不斷增大。
- 儘可能使用小事務，大事務可能導致一個gtid聚集大量的主鍵信息，雖不導致節點延遲過大，但是數據庫中存在大量的主鍵無法通過每分鐘一次的gtid_executed更新來清理，同時也無法通過以事務爲計數單位的流控制機制進行事務提交速度限制。
- 在大表alter等DDL操作時可能會引發衝突檢查數據庫暴漲問題。(以單主模式爲例)原因是secondary接地那在單線程回放DDL操作期間，Primary接地那位於DDL之後的DML操作主鍵會一直在數據庫中無法被清理，如果DML過多，可能會壓爆內存。
15、數據安全性保障
單主模式
scondary節點：
super_read_only = on
多主模式：
super_read_only = off
當節點掛掉：
super_read_only = on 來保護數據安全
16、保證MGR節點不受異步複製通道影響？(數據安全性保障)
a、需要防止單主模式Secondary節點寫入異步複製通道數據。也就是說一個節點不能同時是MGR集羣的Secondary接地那和Mater-slave複製的Slave節點。
b、單主模式的primary節點以及多主模式下，節點可以作爲異步複製的slave節點。注意：在節點寫入異步複製通道數據前，需要檢查MGR約束，包括innodb表、需要顯示主鍵、沒有cascade外鍵等。
c、當節點退出MGR，使用super_read_only自動設置爲off，但無法阻塞relay-log中的事務回放。
b、若配置mysqld重啓後自動啓動MGR和異步複製通道，需要確保順序協調一致。原則是確保MGR先於異步複製通道啓動，MGR接地那變爲ONLINE轉檯後再啓動異步複製通道
17、監控表
replication_group_member_stats ：提供事務認證過程相關的信息。包括查看衝突數，檢查事務數，提交事務數等。可以利用分析延遲
replication_group_members ：集羣轉態信息
18、組通信線程
調整：
group_replication_poll_spin_loops= 10000;
19、消息碎片
mysql8.0.16及以上 增加參數：group_replication_communication_max_message_size變量指定允許的最大大小，默認10MiB，將每個塊廣播到組，即將每個塊單獨轉發到Xcom。
20、xcom緩存管理
mysql8.0.16及以上，增加group_replication_message_cache_size參數設置緩存大小限制，默認值爲1G。如果達到緩存大小的限制，Xcom將刪除已決定和交付的最大條目。之前版本沒有相關參數系統默認1G。
如果嘗試重新連接無法訪問的成員需要恢復消息，但該消息高速緩存中刪除，測該成員無法重新連接。因此需要使用group_replication_member_expel_timeout參數增加延遲時間。
附一、常見問題總結
1、
已成功跑起來的MGR
當把所有的節點都重啓，再啓動第一個節點是需要開啓引導，逐個啓動其他節點的group_replication。
如果在加入其他節點時，一直處於一下報錯
2019-08-08T09:51:02.184851Z 180 [ERROR] [MY-010584] [Repl] Slave I/O for channel 'group_replication_recovery': error connecting to master 'rep@tidb1:3306' - retry-time: 60 retries: 1, Error_code: MY-002061
2019-08-08T09:51:02.283013Z 28 [ERROR] [MY-011582] [Repl] Plugin group_replication reported: 'There was an error when connecting to the donor server. Please check that group_replication_recovery channel credentials and all MEMBER_HOST column values of performance_schema.replication_group_members table are correct and DNS resolvable.'
2019-08-08T09:51:02.283107Z 28 [ERROR] [MY-011583] [Repl] Plugin group_replication reported: 'For details please check performance_schema.replication_connection_status table and error log messages of Slave I/O for channel group_replication_recovery.'
需要執行：mysql -h第一個masterip -uroot -proot123 進入在退出。
2、非innodb存儲引擎和沒有主鍵或非null唯一鍵
插入數據報錯：
ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.
MGR要求：
1.InnoDB存儲引擎：數據必須存儲在InnoDB事務存儲引擎中。
2.主鍵：組要複製的每個表都必須定義顯式主鍵。
3、官方文檔提供的常見問題
https://dev.mysql.com/doc/refman/8.0/en/group-replication-frequently-asked-questions.html
附二、mysql8的新特性
1、redo log 重構日誌系統，採用無鎖化，併發寫入
MTR被併發寫入 redo log buffer，
使用link_buf數據結構，並以環形結構對一個連續的MTR分配內存空間區間，新寫入的MTR複用舊的MTR的空間位置
redo log有兩個獨立的線程：log_writer和 log_flusher
log_writer:負責將redo log buffer中的數據寫入到os cache中。
log_flusher: 負責不停地執行fsync操作將os cache 中的數據真正寫入磁盤中。
類似生產者/消費者持久隊列
2、事務認證 、複製併發
衝突檢查數據庫，進行事務認證
3、writeSet組提交
即事務DML操作更改的記錄信息
WriteSet是基於MTS實現的，利用衝突檢查數據庫來決定並行回放還是回滾。
可以修改certification_info的清理規則，不再基於gtid_executed，而僅需確保一個提交組內儘可能多的事務即可.
paxos協議數據包裏包含gtid_executed信息，即事務快照版本。在進行事務認證時，會對比事務攜帶的gtid_executed和certification_info裏面對應的gtid_set。
primary和unique索引會產生writeset，還進一步解釋了每個writeset包含了哪幾部分：索引名稱+db名+db名長度+表名+表名長度+構成索引唯一性的每個列的值+值長度。二級索引不會產生writeset。
https://dev.mysql.com/worklog/task/?id=9556
http://mysql.taobao.org/monthly/2018/06/04/
https://zhuanlan.zhihu.com/p/55323854
4、mysqlbinlog支持協議壓縮
mysqlbinlog [--compress|-C] --read-from-remote-server
5、 XCOM
named eXtended COMmunications, or simply XCOM
6、
binlog-checksum=NONE
group_replication_member_expel_timeout=60
7、索引跳躍掃描
index skip scan （ISS）
ISS 可以在查詢過濾組合索引不包括最左列的情況下，走索引掃描，而不必要單獨建立額外的索引。
8、字符集默認utf8mb4
MySQL支持了Unicode 9.0
utf8指向的utfmb4
9、實現了DDL的原子性
10、參數持久化
set persist XXXX;
restart;
mysqld-auto.cnf 持久化文件
11、row_number() rank()等
12、可以自動調整內存大小
13、jion的優化
14、數據克隆插件(clone plugin)
15、鬆散索引掃描主要用於GROUP BY / DISTINCT優化
16、快速加字段（不能快速加索引、drop 字段）