183      阿裏雲  技術社區[雲棲]

【MySQL 5.7.17】從主從複製到Group Replication

時值雙十二之際，MySQL官方獻上了大禮，Group Replication(後文簡稱GR)終於正式宣布GA，組合在MySQL 5.7.17版本內部發布出來。

MySQL 5.7.17有很多修正，但GR的發布，卻是最值得說的一個事情。

 在很久之前，MySQL隻是一個采用statement格式作為複製格式，純異步化複製MyISAM作為存儲引擎的，可以運行SQL語句的文件管理器。 

在InnoDB出現之前，MySQL在數據安全以及性能上是很難保證的：

MyISAM的讀寫表級鎖

宕機不安全

著名的永遠跑不完的repair table

這些問題都說明MySQL當時隻能作為數據庫的一個補充角色，而不能作為任何有持久化，安全要求的數據庫需求的用品。

 InnoDB為MySQL帶來了redo，undo，事務，行級鎖等關係數據庫DBA這些熟悉的概念，也是從InnoDB開始，MySQL正式作為生產業務數據庫進入人們的視線。 

MySQL若作為一個單機數據庫時候，需要解決的問題有兩個：

1、ACID問題

2、主從同步

很顯然，InnoDB已經解決了第一個問題，接下來是第二個問題。

Statement格式的複製，雖然保證主從運行的SQL語句一致，但這並不能保證主從數據一致，尤其是一些操作係統依賴的函數調用或者一些特殊環境依賴的使用，於是，在此之上，MySQL出現了基於InnoDB的row格式複製，ROW格式可以保證數據的變更記錄到日誌，為保證主從數據一致性給出了巨大的貢獻。

MySQL 5.1版本可以說是一個非常重要的版本，這個版本發布於2008年，適逢新時代互聯網大潮發展，MySQL開始被廣泛使用於互聯網，其讀寫分離，從庫基本上線性擴展讀能力的方式，很快普及到整個行業。

異步複製不能滿足業務連續性需求

但是， row格式複製提供的是異步複製。由於互聯網技術發展對業務連續性的要求，主庫宕機之後，及時實例可以恢複，大多數時候也會使用從庫重新構建主從後直接提供服務（典型的例子為MHA），這種操作的背後，由於MySQL的異步複製，即使是在最好情況下，仍然會有臨界點事務丟失的問題。

一些嚐試性改進

Google為了解決這個問題引入了半同步技術，作為自己的獨立發布版本在內部使用，之後，sun被Oracle收購，在隨後發布的MySQL 5.5版本中，半同步被吸收入官方，為MySQL主從複製的數據安全，畫上了一個不太完整的句號。

對於半同步技術，從MySQL 5.5到5.6，再到5.7，每個版本都會對此做做修正，半同步技術也一直在不斷完善和強大的過程中，在MySQL內部，也逐漸演變出並行複製的方案。一般我們會建議使用MySQL 5.7的最新版本，保障數據安全。

蓋技術的更新除了在數據安全上有了更大的保障之外， 也讓主從複製的另外一個問題-SQL線程得到了相當大的緩解。

其實主從複製-->半同步-->並行複製這條路本身，是可以一直走下去的，但是，也會有人問，主從複製是否是唯一的一條路?

 還有一個方案，聽說過的人應該不在少數，但是用過的人並不多：MySQL NDB Cluster。其工作原理是：

把MySQL作為SQL解析以及命令轉發的Proxy，後端用NDB CLuster提供的分布式數據庫提供服務

這個思路本身沒有問題，可惜生不逢時，NDB出現得太早，管理的思路和使用的思路，都大異於傳統的數據庫，相比較當代的各路NoSQL的牛鬼蛇神，NDB足稱可靠，但作為企業級產品上，運維以及開發的學習代價太大；而用於互聯網場景，又不足以與各路NoSQL拚比專項，到目前為止，仍然沒有被作為主要使用方案。

官方的道路一度到此為止，但MySQL作為開源產品，社區裏麵永遠不乏高手，在官方之外，走出了另外一條路，Galera Cluster。

Galera Cluster的思路，是在盡量不改變MySQL的運維思路的基礎上，保障數據庫的安全。最終出現的，是一個乍一看比較奇怪的東西：Galera是多節點可寫的，節點之間share nothing，每個節點都保存當前數據庫所有數據，commit發生在單個節點，節點間鎖衝突延後到commit階段處理的集群。

很多人，包括我在內，認為Galera這種方式才是一個“真正的集群”，節點之間通過分布式協議溝通，節點失敗自動踢出，節點加入自動同步，這些才是一個集群應該幹，並且應該幹到的事情。而傳統的主從複製方式，無論如何美化描述，也都需要諸多外圍腳本支持才能實現這些功能，並不是一個“真正的集群”。

從理論上看，雖然有一定的限製條件，但Galera所描繪的MySQL集群也已經足夠漂亮。但是，為了做到這些功能，Galera對MySQL數據庫本身做了不少修改，這點讓很多有“官方”潔癖的人，比較擔心Galera的引入對MySQL穩定性造成的影響，從如今的趨勢來看，Galera方案幾乎與NDB方案一樣的結局，最後淪落為漂亮的花瓶。

雖然前麵說Galera聽起來多麼美好，但MySQL官方由於種種緣由，沒有合並Galera的工作進入官方版本。

但第三方的開發版本則沒有這麼多忌諱，MySQL世界的兩個發行版-Percona以及MariaDB很快結合Galera方案

Percona給出了的是Percona Xtra Cluster（PXC）方案，MariaDB在新版本（現在已經是穩定版本）直接原生組合Galera進去，Galera的問題，由Percona與MariaDB分別按照自己的思路處理解決，為人們的使用創造方便。

Percona本身就是最大的開源數據庫服務商，MariaDB也有基金會與商業公司支持，這兩個公司的方案，在經曆了一段時間的試水期之後，很快被業界接受。

國外姑且不論，國內的情況，Percona方案從去哪兒網開始，被廣泛使用於互聯網類行業，對高可用以及數據丟失敏感的業務。而另外一個MariaDB的方案，則在傳統行業的“去IOE”運動中扮演著重要角色。

方案本身的可靠性比較是不必疑慮的，但使用場景的結果如此，MariaDB的用戶更多看重的，應該還是MariaDB背後完整的開源基因吧。

MySQL官方呢，在這個潮流中，就隻是看著嗎？

當然不是，既然沒有吸收Galera進入自身，那麼剩下的事情，就是自己開發了。

在前段時間發布的整個MySQL InnoDBCluster計劃中，MySQL官方的野心很大，包括多主集群，讀寫分離，讀橫行擴展，寫橫行擴展等諸多組件。對，裏麵提到的，多主集群，就是MySQL原生的，與Galera類似的，“真正的集群”方案。也是整個計劃裏麵，目前第一個可用的。

從規劃時間上看，在非常早的時間，GR就已經作為規劃方案開始編寫，初始於MySQL Lab，最終合並到官方分支宣布GA，曆經了多年時間開發，為用戶以及社區給出了MySQL自己的多主方案。

本質上，GR是一個與Galera方案類似的多主集群方案，原理上，都是分布式協議溝通，commit階段處理節點間鎖衝突等等。

在Galera方案已經大行其道的現在，GR還有什麼優勢或者意義呢？

• 最直觀的第一點，就是這個是MySQL的官方方案，也就是說，用戶可以不必忌諱Percona以及MariaDB的“非官方感”而直接使用到更好（根據特定的benchmark）的多主集群服務。可以直接享受到多主複製，多線程複製等官方業已提供的功能而不必等糾結第三方的可靠性以及學習成本。

• 第二點，Galera由於實現方式限製，隻能用於linux平台，但GR是可以用於win以及mac（BSD）平台的，這點無論是對於技術本身的學習，還是小企業環境的部署，都有足夠的好處。對運維技能的需求，也在一定程度上降低了不少。

• 第三點，Galera的實現畢竟是外加的組件。比如，由於引入的gcache作為事務的同步緩存，造成主機資源的耗費，而GR方案則直接使用row格式的binlog做這個工作，降低了主機壓力。而且，一旦待同步數據庫的延遲超過gcache的限製，就會導致數據庫重傳（SST），GR通過binlog的複用，直接采用傳統的數據庫備份恢複方式就可以構建節點開始同步，這點上比Galera的實現更適合生產環境。

因此從長期考慮上看，GR的實現會是更好的選擇！

然而，目前階段，GR還有些問題需要逐步解決或者讓人們排除顧慮。

第一點，生產環境的使用。無論是PXC還是MariaDB方案，都已經有在生產環境運行多年的案例，其穩定性，安全性，乃至運行中遇到的種種問題的解決方案手段，都有成熟，眾多的積累案例，GR則是剛剛GA，並且隻提供給MySQL5.7.17版本（估計後續版本都會集成），在MySQL 5.7開始進入生產環境部署的時候，如果一並納入GR的部署，帶來的運維以及使用問題相信不在少數，這些問題如何解決，最佳實踐是什麼，這是一個需要持續長時間維護的事情。

第二點，工具支持。到目前為止，MySQL主要使用的運維工具，相當多的程序來源是Percona公司，Percona公司對MySQL官方的態度一直是積極跟進，但是，在已經有PXC方案的現狀下，Percona公司有多大興趣以及人力維護GR相關的工具體係是一個目前存疑的問題。

第三點，使用培訓。GR方案作為一個更完美的高可用以及數據安全方案，其實際使用中，DBA以及開發，必須對GR的種種限製有足夠多的了解，才能在實際程序開發以及運維中，做到最合適的處理，這一點勢必需要社區與官方的大力推進推動才可以。

很幸運，我們可以生活在這個時代，可以看著MySQL從一個“可以跑SQL的文件工具”，逐漸走向為一個高可用高安全的關係數據庫係統。在這個過程中，我們未必有能力或者精力去構建棟梁，但添磚加瓦，雕梁畫壁的時間，卻是誰都有的。

本文出自數據和雲公眾號，原文鏈接

最後更新：2017-07-18 10:33:07

  上一篇：  【動手實踐】Oracle 12.2 新特性：隻讀分區的使用和維護

  下一篇：  【動手實踐】Oracle 12.2新特性：多列列表分區和外部表分區