Mysql group replication複製原理
前言：
Mysql版本5.7.17推出Mysql group replication（組複製），相對以前傳統的複製模式（非同步複製模式async replication 及半同步複製模式semi-sync replication），一個主，對應一個或多個從，在主資料庫上執行的事務通過binlog複製的方式傳送給slave，slave通過 IO thread執行緒接收將事務先寫入relay log，然後重放事務，即在slave上重新執行一次事務，從而達到主從事務一致的效果，如下圖為兩種複製模式：
一、傳統複製
MySQL Asynchronous Replication（非同步複製）：master執行事務，寫入二進位制日誌，然後提交，slave接收binlog日誌事務並將事務先寫入relay，然後重做事務
MySQL Semisynchronous Replication （半同步複製）：master執行事務，寫入二進位制日誌，將binlog事務日誌傳送到slave，slave接收到binlog事務日誌後，將其寫到relay log，然後向master返回傳送成功ACK；master收到ACK後，再在儲存引擎中提交事務
二、Group Replication
MySQL Group Replication有兩種模式，單主模式single-primary mode和多主模式multi-primary mode，在同一個group內，不允許兩種模式同時存在，並且若要切換到不同模式，必須修改配置後重新啟動叢集
1、單主模式
在單主模式下，只有一個節點可以可以讀寫，其他節點只能提供讀，在單主模式下，該引數 group_replication_enforce_update_everywhere_checks 必須被設定為 FALSE ，當主節點宕掉，自動會根據伺服器的server_uuid變數和group_replication_member_weight變數值，選擇下一個slave誰作為主節點，group_replication_member_weight的值最高的成員被選為新的主節點，在group_replication_member_weight值相同的情況下，group根據資料字典中 server_uuid排序，排序在最前的被選擇為主節點
下面的示例展示瞭如何在單主模式中發現當前的主伺服器，該值VARIABLE_VALUE為例項節點的server_uuid
mysql> SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member';
+--------------------------------------+
| VARIABLE_VALUE |
+--------------------------------------+
| 69e1a3b8-8397-11e6-8e67-bf68cbc061a4 |
+--------------------------------------+
2、多主模式
在多主模式下，在加入該群組的所有成員，所有伺服器都設定為讀寫模式，在多主模式下，不支援SERIALIZABLE事務隔離級別，在多主模式下，不能完全支援級聯外來鍵約束
3、組複製
在mysql多主模式下,在組複製中通過Group Replication Protocol協議及Paxos協議，形成的整體高可用解決方案 同時增加了certify的概念，負責檢查事務是否允許提交，是否與其它事務存在衝突,Group Replication是由多個節點共同組成一個數據庫叢集，每個節點都可以單獨執行事務，但是read-write（rw）的操作只有在組內驗證後才可以commit，Read-only (RO)事務是不需要驗證可以立即執行，當一個事務在一個節點上提交之前，會在組內自動進行原子性的廣播，告知其他節點變更了什麼內容/執行了什麼事務，然後為該事物建立一個全域性的排序，最終，這意味著所有的伺服器都以相同的順序接收相同的事務集。因此，所有伺服器都按照相同的順序應用相同的變更集，因此它們在組中保持一致