時值雙十二之際，mysql官方獻上了大禮，group replication(後文簡稱gr)終于正式宣布ga，組合在mysql 5.7.17版本内部釋出出來。
mysql 5.7.17有很多修正，但gr的釋出，卻是最值得說的一個事情。
看mysql一路改進
在很久之前，mysql隻是一個采用statement格式作為複制格式，純異步化複制myisam作為存儲引擎的，可以運作sql語句的檔案管理器。
innodb的改進
在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拼比專項，到目前為止，仍然沒有被作為主要使用方案。
官方之外，galera cluster另辟蹊徑
官方的道路一度到此為止，但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的檔案工具”，逐漸走向為一個高可用高安全的關系資料庫系統。在這個過程中，我們未必有能力或者精力去建構棟梁，但添磚加瓦，雕梁畫壁的時間，卻是誰都有的。