如何分析MySQL Group Replication

如何分析MySQL Group Replication，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

最近看了下MySQL Group Replication的內容，因為發布的時間不是很長，可以算是一個新鮮玩意，而且因為它特有的意義，這個特性顯得更加意味深長。
我接觸Oracle的時間要長一些，所以很多時候都喜歡帶著對比的眼光來看，單著自己嘗試著用了下這個特性，感覺一下子讓我找到了當年學習Oracle 10g RAC時的感覺，里面還是有一些小問題，而且還不少，眼巴巴的看著報錯，但是日志又很有限，查閱資料，竟然不是bug就是找不到一些相關的信息，所以有時候有種信息孤島的感覺。
官網的資料自己也看了好幾遍，在自己在電腦環境中也模擬了不下十次，每次感覺都是差一點，有一些讓人感覺不大滿意的地方，我覺得在這方面的付出可真不比Oracle少，而且我也知道這個新特性要達到成熟到普及，還需要時日。這個過程總是讓人難忘而且艱辛。
首先這個特性，使得MySQL和Oracle體量更加接近，看看下載的二進制包就讓人手里一抖，壓塑包600多M,但是解壓后竟然有差不多2.6G.
  # du -sh ./*
2.6G    ./mysql-5.7.17-linux-glibc2.5-x86_64
625M    ./mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz
   如果仔細往下看，就會發現里面group replication的部分占用的空間確實不少。
   我想下面的這個圖，如果要看group replication都要說上一段，各類博客中都有自然引用到，原來來自于官網的解讀。
  
   從原生的Replication過渡到插件式的半同步，再到Group Replication，真是一個很大的進步，高可用方案隨著這個技術的成熟相比也會逐漸成為一種趨勢，從Galera到后面Percona包裝的PXC,從Group replication的角度再回頭來看，竟然發現是如此相似。Galera的作者都是一批20多年實戰經驗的老鳥，在技術成熟度方面肯定完全不遜于官方。所以選擇哪一個或者哪一個更成熟，到時候會是擺在MySQL DBA面前的一個艱難的選擇。
   然后再來一張圖。MySQL 插件的結構圖。
  
MySQL的這個高可用方案是一個share nothing的架構，這樣也就使得整個架構是一個強一致性的設計方式，自然會用到組播的方式。
Oracle中搭建RAC需要一個集群軟件，早期是可選第三方，后來統一為Oracle專供，也就是后來所說的Grid Infrastrue,不光整合力集群軟件，ASM的部分也整合進去了，有點強拆的感覺。MGR的模式目前是推薦單主的形式，即讀寫分離的方式，也可以做到多主。
   MySQL Group Replication中的這個部分是由Corosync來實現的，corosync的由來是源于一個Openais的項目，可以實現HA心跳信息傳輸的功能，是眾多實現HA集群軟件中之一，在MGR早起的實驗室版本還需要特意關注這部分的信息，特意的設定和配置使得集群環境能夠穩步運行，MGR也是包含了綁定corosync的接口，這個接口實際上是corosync到client API的一個隱式映射。
   由此我也看到了幾個不錯的解決方案，

corosync+pacemaker+mysql+drbd 實現mysql的高可用，還有搭建Group Replication很有想法的一個實踐，就是先配置gtid,然后切換到group replication，使得這個過程更加平滑。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。