MySQL MGR+ Consul之數據庫高可用方案最佳實踐 背景說明： 基于目前存在很多MySQL數據庫單點故障,傳統的MHA，PXC等方案用VIP或者DNS切換的方式可以實現、基于數據庫的數據強一致性考慮，采用MGR集群，采用consul服務注冊發現實現應用端通過動態DNS 訪問MGR集群，實現數據庫高可用，自動化切換的方案 MGR簡介 MySQL Group Replication（MGR）是MySQL官方在5.7.17版本引進的一個數據庫高可用與高擴展的解決方案，以插件形式提供，實現了分布式下數據的最終一致性，總結MGR特點如下： 高一致性：基于分布式paxos協議實現組復制，保證數據一致性； 高容錯性：自動檢測機制，只要不是大多數節點都宕機就可以繼續工作，內置防腦裂保護機制； 高擴展性：節點的增加與移除會自動更新組成員信息，新節點加入后，自動從其他節點同步增量數據，直到與其他節點數據一致； 高靈活性：提供單主模式和多主模式，單主模式在主庫宕機后能夠自動選主，所有寫入都在主節點進行，多主模式支持多節點寫入。 MGR原理說明： 組復制是一種可用于實現容錯系統的技術。 復制組是一個通過消息傳遞相互交互的 server 集群。通信層提供了原子消息(atomic message)和完全有序信息交互等保障機制 實現了基于復制協議的多主更新 復制組由多個 server成員構成,并且組中的每個 server 成員可以獨立地執行事務。但所有讀寫(RW)事務只有在沖突檢測成功后才會提交。只讀(RO)事務不需要在沖突檢測,可以立即提交。句話說,對于任何 RW 事務,提交操作并不是由始發 server 單向決定的,而是由組來決定是否提交。準確地說,在始發 server 上,當事務準備好提交時,該 server 會廣播寫入值(已改變的行)和對應的寫入集(已更新的行的唯一標識符)。然后會為該事務建立一個全局的順序。最終,這意味著所有 server 成員以相同的順序接收同一組事務。因此,所有 server 成員以相同的順序應用相同的更改,以確保組內一致。組復制是一種 share-nothing 復制方案,其中每個 server 成員都有自己的完整數據副本。 MGR的局限性： 僅支持InnodDB存儲引擎的表，并且每個表必須有主鍵ID, 用做wirte set的沖突檢測 必須啟用GTID特性，binlog日志格式必須為row模式 目前一個MGR集群最多支持9個節點 不支持外健的save point特性，無法做全局間的約束檢測和部分回滾 二進制日志不支持binlog event checksum
