王志朋
美團點評DBA
曾在京東金融擔任DBA，目前就職于美團點評，主要負責金融業務線數據庫及基礎組件數據庫的運維。
MySQL Group Replication（以下簡稱MGR），于5.7.17版本正式GA，由Oracle官方出品，為MySQL的高可用方案注入了新血液。其一致性，以及不依賴外部組件實現的自動切換、多點寫入，給DBA帶來了不少期待。
一、背景
以MHA作為切換工具，CMDB管理元數據，結合中間件的高可用方案在MySQL生態中是比較常見的架構。在這個體系中，CMDB作為基礎組件之一，不能再依賴這個架構實現自身的高可用，而需要一套自成體系的高可用架構保障。
2017年下半年開始，美團點評數據庫計劃全面升級上線5.7版本，也正是這個契機，基于MGR的CMDB高可用想法應運而生。
二、關于MGR
MGR是以Plugin的形式嵌入在MySQL實例中，插件內部實現了沖突檢測、Paxos協議通信等。
可能有同學了解它與PXC很像，社區中關于二者的口水戰也非常的熱鬧，具體二者的優劣與爭端此處不表，但有一點值得說明，MGR集群當中，仍然是通過binlog實現節點同步的。這一點對DBA很友好，意味著我們可以很輕易的找回熟悉的主從的感覺（Still A MySQL）。
三、解決方案
MGR包括多主與單主兩個模式，出于多主模式的一些已知問題以及實際業務場景的考慮，我們決定選擇單主模式作為主要方案，即當主節點故障后，集群自動選舉新的主節點，應用將寫訪問指向新的主節點。
那么具體的解決方案還有哪些需要考慮呢？
-
MGR的限制；
-
相關測試；
-
合理的參數。
1.MGR的限制
-
只支持InnoDB存儲引擎；
-
必須有主鍵；
-
binlog_format只支持ROW格式；
-
不支持save point（后修復）；
-
……
官方給出了一些明確的要求及限制。針對這些限制我們要對線上要接入的數據庫進行排查，調研可行性，規范其滿足MGR的要求。包括收斂MyISAM存儲引擎的表、無主鍵的表，應用邏輯中去除save point（新版本去掉此限制）等。
此外我們生產關心的問題，如網絡抖動對MGR的影響、備份恢復工具可用性、Online-DDL可用性等，同樣需要考慮在內。對此我們做了系統性的功能測試：
同時在測試中也對MGR的行為有了一些新的認識，比如MyISAM引擎、無主鍵的表等MGR明確不支持的場景，都是以一種“樂觀”的方式處理，即允許你創建、Alter，但不允許寫入數據。
2.MGR的參數
同時在上面提到的測試中，我們也遇到了幾個重要參數不同值的不同行為。比如group_replication_unreachable_majority_timeout這個參數，它真正的含義是MGR節點由ONLINE狀態進入UNREACHABLE狀態后（一般是由于網絡抖動、節點異常等引起），等待相應的時間，如果仍保持UNREACHABLE，則將節點置為ERROR狀態，即這個參數是UNREACHABLE狀態的一個timeout，單位秒。
（MGR節點的幾個狀態）
該參數默認值為0，含義是無timeout，即無限等待，這在實際的生產環境中，如發生網絡的異常，是個不可接受結果。
以下是我們根據官方的文檔，以及實踐過程中的一些問題，總結的參數，可作為一個參考：
3.最終架構
最后我落實了三機房三節點MGR集群，作為高可用方案主體，同時向下擴展了一套主從集群，作為不可挽回問題的災備。畢竟MGR作為新生兒，可靠性還有待驗證，相信不遠的將來我們也有足夠的信心放棄回滾到主從的方案。
四、上線歷程
美團點評從2018年以來，總共將三個系統遷移上線了MGR，包括流程系統、報表系統以及CMDB。
五、典型問題
在幾個集群上線的過程中，我們也積累了一些問題，其中典型的幾個在這里簡單回顧一下：
1.大事務
在報表系統上線后，集群出現了一點詭異的狀況：在某些時間點，節點不定時會出現UNREACHABLE的狀態，嚴重時直接導致集群選主切換，而在此期間，機房機器網絡并沒有什么異常。
這個問題最初困擾了我們一段時間，通過對之前流程系統的對比，我們發現兩個集群網卡的流量大小有些區別，且報表系統有比較明顯的尖刺：
從這個分析角度出發，我們查閱文檔，發現有參數可以做相關的優化，即group_replication_compression_threshold，含義是事務超過相應大小則在傳輸前進行壓縮處理。下圖為參數調整后的對比，由1.5M減少到15K。實際場景中異常狀態發生次數確實減少了，但沒有根除。
順著這個思路我們做了一些測試，定位到了根本問題：大事務。
需要說明的是MGR的大事務有自己的“定義”，它的大事務與網絡的傳輸時間有關，這就解釋了為什么我們開啟壓縮后，節點異常狀態次數減少的問題。最后我們通過限制事務的大小的方式，徹底解決了這個問題，同時也在業務邏輯上優化了大事務。以下是兩個相關的參數：
2. 應用HANG死
第二個問題發生在一次節點下線演練的過程中，DBA開始演練操作后，開發同學突然反饋說后臺Nginx由于請求積壓，機器掛掉了。如下圖Nginx可用率：
此時我們在DBA的慢查詢監控中發現一個峰值，時間點基本吻合。下圖為慢查詢監控：
由此我們分析了這段時間的慢查詢，發現這個SQL我們非常眼熟——MGR查詢主節點的語句。正常這個SQL執行時間在毫秒級，故障當時執行了10s，而這個10s與stop group_replication這個操作的耗時基本吻合。
據此我們做了相應的測試驗證了猜測：在MGR節點START和STOP過程中，當前節點的replication_group_member視圖的查詢全部hang住。這也就是解釋了Nginx后臺請求堆積造成的宕機。在此之后，我們在程序中查詢這個視圖時加入了超時的邏輯，解決了這個問題。
3. 機房故障
第三個問題發生在一次實際的機房故障中：CMDB主節點所在機房網絡帶寬減半，導致CMDB的MGR集群和一套業務主從集群幾乎同時發生了切換，MGR的切換時間大概在3s左右，業務基本無感知，只發生部分報錯，但業務集群切換發現回填CMDB失敗。
究其原因主要是由于切換的邏輯仍然沿用DNS的連接方式，導致切換發生，DNS同步重新指向，而切換的應用程序對DNS新地址的解析遲遲未效。
通過這次故障，也促使我們將所有核心CMDB訪問全部遷移到內部開發的Smart Client端上。
六、Smart Client
關于Smart Client，它是我們內部開發的一套Python連接API，是基于MySQLdb實現的一套MGR切換自動選主、讀寫分離的功能。對于熟悉Python訪問MySQL的同學上手非常簡單。
七、日常運維
關于MGR的日常運維，實際情況比較省心。
初始化除部分參數區別外，基本與主從集群差異不大。監控方面，我們除了加入系統和MySQL的基礎監控外（對MGR兼容良好），還加入了MGR節點狀態的監控，即非ONLINE狀態的節點全為異常。同時會有同學問，延遲怎么監控？理論上MGR是個最終一致的集群，它內部沒有延遲的概念，但我們可以通過監控待執行事務隊列中數值，近似看做是一種延遲。
下圖為線上一個集群的“延遲”情況，縱坐標為事務個數：
同時還有主節點與其他節點的GTID_SET差值也可以作為一定參考。
八、寫在最后
通過我們一系列的線上演練，甚至包括部分高峰期的演練，以及一段時間的運行狀態觀察，MGR確實是一個穩定、可靠的高可用架構。雖然對于寫入密集型場景不是非常友好，但相信還是可以為DBA的高可用方案提供新的思路。
參考
-
MGR的要求：
https://dev.mysql.com/doc/refman/5.7/en/group-replication-requirements.html
-
MGR的限制：
https://dev.mysql.com/doc/refman/5.7/en/group-replication-limitations.html
-
參數配置：
https://dev.mysql.com/doc/refman/5.7/en/group-replication-configuring-instances.html
-
python工具包：Python MySQL Group Replication 使用
參考鏈接：https://km.sankuai.com/page/52289606
- 轉自 美團點評基于MGR的CMDB高可用架構搭建之路 https://www.toutiao.com/i6602060886867706376/
?
