MGR簡介
MySQL Group Replication，簡稱MGR，它是MySQL官方推出的基于paxos分布式一致性協議的狀態機復制，實現了分布式下數據的最終一致性。同時MGR提供了高可用、高擴展、高可靠的MySQL集群解決方案，它也是金融級分布式數據庫之一。
MGR適用場景
MGR天生就是為金融場景設計的，例如：支付，證券交易，保險，銀行等等。因為這些場景要求數據必須做到零丟失，數據庫可用性在4個9，甚至5個9（年度停機時間不超過5分鐘）。
MGR采用多副本，在2N+1個節點集群中，集群只要N +1個節點還存活著，數據庫就能穩定的對外提供服務。
MGR運行模式
MGR運行模式有2種
- 單主模式（single-primary mode）
- 多主模式（multi-primary mode）
單主模式：
在這種模式下，組具有設置為讀寫模式的單主服務器。該組中的所有其他成員都設置為只讀模式。這會自動發生。主服務器通常是引導該組的第一臺服務器，所有其他加入的服務器會自動了解主服務器，并設置為只讀。
多主模式：
在多主要模式下，沒有單個主要概念。無需參與選舉程序，因為沒有服務器扮演任何特殊角色，所有服務器均設置為讀寫模式。
MGR選舉原理
MGR單主模式選舉原理
單主模式下，如果主節點掛了，那么其他的成員會自動選舉出新的主成員，成員之間可以通過配置權重來確定下一個主成員是誰，如果沒有配置權重，則會對所有在線成員的UUID進行排序，然后選取UUID最小的成員作為主成員。
MGR多主模式選舉原理
多主模式，所有的組內成員對外提供讀寫服務，是真正意義上的并發，MGR對于高并發有很好的的處理能力。多主模式下，組內所有成員沒有主從之分，對用戶來說，就像在操作一個MySQL一樣。所以在多主模式下，不存在選舉主節點，因為所有節點都是主節點。
MGR復制原理
在2N+1個節點組成的單主模式組復制集群中，主庫上一個事務提交時，會將事務修改記錄相關的信息和事務產生的BINLOG事件打包生成一個寫集(WRITE SET)，將寫集發送給所有節點，并通過至少N個節點投票通過才能事務提交成功。
MGR要求
1.必須適用innodb存儲引擎
2.創建的業務表，必須要有主鍵
3.MGR必須適用IPv4網絡，不支持IPv6
4.MGR復制網絡必須和業務網絡隔離
5.binlog日志格式必須為row模式
6.關閉二進制日志校驗和，設置--binlog-checksum=NONE
7.小寫 table 格名稱. 在所有組成員上將--lower-case-table-names設置為相同的值
8.隔離級別設置為RC
MGR限制
1.MGR不支持SERIALIZABLE 隔離級別
2.MGR集群節點不能超過9
3.MGR不支持大事務，事務大小最好不超過143MB，當事務過大，無法在5 秒的時間內通過網絡在組成員之間復制消息，則可能會懷疑成員失敗了，然后將其驅逐出局。
4.并發 DDL 與 DML 操作. 當使用多主模式時，不支持針對同一對象但在不同服務器上執行的并發數據定義語句和數據操作語句。
5.對表的級聯約束的外鍵支持不好，不建議適用。
