作者 王志朋|美團點評DBA

曾在京東金融擔(dān)任DBA，目前就職于美團點評，主要負責(zé)金融業(yè)務(wù)線數(shù)據(jù)庫及基礎(chǔ)組件數(shù)據(jù)庫的運維。

MySQL Group Replication(以下簡稱MGR)，于5.7.17版本正式GA，由Oracle官方出品，為MySQL的高可用方案注入了新血液。其一致性，以及不依賴外部組件實現(xiàn)的自動切換、多點寫入，給DBA帶來了不少期待。

一、背景

以MHA作為切換工具，CMDB管理元數(shù)據(jù)，結(jié)合中間件的高可用方案在MySQL生態(tài)中是比較常見的架構(gòu)。在這個體系中，CMDB作為基礎(chǔ)組件之一，不能再依賴這個架構(gòu)實現(xiàn)自身的高可用，而需要一套自成體系的高可用架構(gòu)保障。

2017年下半年開始，美團點評數(shù)據(jù)庫計劃全面升級上線5.7版本，也正是這個契機，基于MGR的CMDB高可用想法應(yīng)運而生。

二、關(guān)于MGR

MGR是以Plugin的形式嵌入在MySQL實例中，插件內(nèi)部實現(xiàn)了沖突檢測、Paxos協(xié)議通信等。

可能有同學(xué)了解它與PXC很像，社區(qū)中關(guān)于二者的口水戰(zhàn)也非常的熱鬧，具體二者的優(yōu)劣與爭端此處不表，但有一點值得說明，MGR集群當(dāng)中，仍然是通過binlog實現(xiàn)節(jié)點同步的。這一點對DBA很友好，意味著我們可以很輕易的找回熟悉的主從的感覺(Still A MySQL)。

三、解決方案

MGR包括多主與單主兩個模式，出于多主模式的一些已知問題以及實際業(yè)務(wù)場景的考慮，我們決定選擇單主模式作為主要方案，即當(dāng)主節(jié)點故障后，集群自動選舉新的主節(jié)點，應(yīng)用將寫訪問指向新的主節(jié)點。

那么具體的解決方案還有哪些需要考慮呢？

MGR的限制；

相關(guān)測試；

合理的參數(shù)。

1.MGR的限制

只支持InnoDB存儲引擎；

必須有主鍵；

binlog_format只支持ROW格式；

不支持save point(后修復(fù))；

……

官方給出了一些明確的要求及限制。針對這些限制我們要對線上要接入的數(shù)據(jù)庫進行排查，調(diào)研可行性，規(guī)范其滿足MGR的要求。包括收斂MyISAM存儲引擎的表、無主鍵的表，應(yīng)用邏輯中去除save point(新版本去掉此限制)等。

此外我們生產(chǎn)關(guān)心的問題，如網(wǎng)絡(luò)抖動對MGR的影響、備份恢復(fù)工具可用性、Online-DDL可用性等，同樣需要考慮在內(nèi)。對此我們做了系統(tǒng)性的功能測試：

同時在測試中也對MGR的行為有了一些新的認識，比如MyISAM引擎、無主鍵的表等MGR明確不支持的場景，都是以一種“樂觀”的方式處理，即允許你創(chuàng)建、Alter，但不允許寫入數(shù)據(jù)。

2.MGR的參數(shù)

同時在上面提到的測試中，我們也遇到了幾個重要參數(shù)不同值的不同行為。比如group_replication_unreachable_majority_timeout這個參數(shù)，它真正的含義是MGR節(jié)點由ONLINE狀態(tài)進入UNREACHABLE狀態(tài)后(一般是由于網(wǎng)絡(luò)抖動、節(jié)點異常等引起)，等待相應(yīng)的時間，如果仍保持UNREACHABLE，則將節(jié)點置為ERROR狀態(tài)，即這個參數(shù)是UNREACHABLE狀態(tài)的一個timeout，單位秒。

(MGR節(jié)點的幾個狀態(tài))

該參數(shù)默認值為0，含義是無timeout，即無限等待，這在實際的生產(chǎn)環(huán)境中，如發(fā)生網(wǎng)絡(luò)的異常，是個不可接受結(jié)果。

以下是我們根據(jù)官方的文檔，以及實踐過程中的一些問題，總結(jié)的參數(shù)，可作為一個參考：

3.最終架構(gòu)

最后我落實了三機房三節(jié)點MGR集群，作為高可用方案主體，同時向下擴展了一套主從集群，作為不可挽回問題的災(zāi)備。畢竟MGR作為新生兒，可靠性還有待驗證，相信不遠的將來我們也有足夠的信心放棄回滾到主從的方案。

四、上線歷程

美團點評從2018年以來，總共將三個系統(tǒng)遷移上線了MGR，包括流程系統(tǒng)、報表系統(tǒng)以及CMDB。

五、典型問題

在幾個集群上線的過程中，我們也積累了一些問題，其中典型的幾個在這里簡單回顧一下：

1.大事務(wù)

在報表系統(tǒng)上線后，集群出現(xiàn)了一點詭異的狀況：在某些時間點，節(jié)點不定時會出現(xiàn)UNREACHABLE的狀態(tài)，嚴(yán)重時直接導(dǎo)致集群選主切換，而在此期間，機房機器網(wǎng)絡(luò)并沒有什么異常。

這個問題最初困擾了我們一段時間，通過對之前流程系統(tǒng)的對比，我們發(fā)現(xiàn)兩個集群網(wǎng)卡的流量大小有些區(qū)別，且報表系統(tǒng)有比較明顯的尖刺：

從這個分析角度出發(fā)，我們查閱文檔，發(fā)現(xiàn)有參數(shù)可以做相關(guān)的優(yōu)化，即group_replication_compression_threshold，含義是事務(wù)超過相應(yīng)大小則在傳輸前進行壓縮處理。下圖為參數(shù)調(diào)整后的對比，由1.5M減少到15K。實際場景中異常狀態(tài)發(fā)生次數(shù)確實減少了，但沒有根除。

順著這個思路我們做了一些測試，定位到了根本問題：大事務(wù)。

需要說明的是MGR的大事務(wù)有自己的“定義”，它的大事務(wù)與網(wǎng)絡(luò)的傳輸時間有關(guān)，這就解釋了為什么我們開啟壓縮后，節(jié)點異常狀態(tài)次數(shù)減少的問題。最后我們通過限制事務(wù)的大小的方式，徹底解決了這個問題，同時也在業(yè)務(wù)邏輯上優(yōu)化了大事務(wù)。以下是兩個相關(guān)的參數(shù)：

2. 應(yīng)用HANG死

第二個問題發(fā)生在一次節(jié)點下線演練的過程中，DBA開始演練操作后，開發(fā)同學(xué)突然反饋說后臺Nginx由于請求積壓，機器掛掉了。如下圖Nginx可用率：

此時我們在DBA的慢查詢監(jiān)控中發(fā)現(xiàn)一個峰值，時間點基本吻合。下圖為慢查詢監(jiān)控：

由此我們分析了這段時間的慢查詢，發(fā)現(xiàn)這個SQL我們非常眼熟——MGR查詢主節(jié)點的語句。正常這個SQL執(zhí)行時間在毫秒級，故障當(dāng)時執(zhí)行了10s，而這個10s與stop group_replication這個操作的耗時基本吻合。

據(jù)此我們做了相應(yīng)的測試驗證了猜測：在MGR節(jié)點START和STOP過程中，當(dāng)前節(jié)點的replication_group_member視圖的查詢?nèi)縣ang住。這也就是解釋了Nginx后臺請求堆積造成的宕機。在此之后，我們在程序中查詢這個視圖時加入了超時的邏輯，解決了這個問題。

3. 機房故障

第三個問題發(fā)生在一次實際的機房故障中：CMDB主節(jié)點所在機房網(wǎng)絡(luò)帶寬減半，導(dǎo)致CMDB的MGR集群和一套業(yè)務(wù)主從集群幾乎同時發(fā)生了切換，MGR的切換時間大概在3s左右，業(yè)務(wù)基本無感知，只發(fā)生部分報錯，但業(yè)務(wù)集群切換發(fā)現(xiàn)回填CMDB失敗。

究其原因主要是由于切換的邏輯仍然沿用DNS的連接方式，導(dǎo)致切換發(fā)生，DNS同步重新指向，而切換的應(yīng)用程序?qū)NS新地址的解析遲遲未效。

通過這次故障，也促使我們將所有核心CMDB訪問全部遷移到內(nèi)部開發(fā)的Smart Client端上。

六、Smart Client

關(guān)于Smart Client，它是我們內(nèi)部開發(fā)的一套Python連接API，是基于MySQLdb實現(xiàn)的一套MGR切換自動選主、讀寫分離的功能。對于熟悉Python訪問MySQL的同學(xué)上手非常簡單。

七、日常運維

關(guān)于MGR的日常運維，實際情況比較省心。

初始化除部分參數(shù)區(qū)別外，基本與主從集群差異不大。監(jiān)控方面，我們除了加入系統(tǒng)和MySQL的基礎(chǔ)監(jiān)控外(對MGR兼容良好)，還加入了MGR節(jié)點狀態(tài)的監(jiān)控，即非ONLINE狀態(tài)的節(jié)點全為異常。同時會有同學(xué)問，延遲怎么監(jiān)控？理論上MGR是個最終一致的集群，它內(nèi)部沒有延遲的概念，但我們可以通過監(jiān)控待執(zhí)行事務(wù)隊列中數(shù)值，近似看做是一種延遲。

下圖為線上一個集群的“延遲”情況，縱坐標(biāo)為事務(wù)個數(shù)：

同時還有主節(jié)點與其他節(jié)點的GTID_SET差值也可以作為一定參考。

八、寫在最后

通過我們一系列的線上演練，甚至包括部分高峰期的演練，以及一段時間的運行狀態(tài)觀察，MGR確實是一個穩(wěn)定、可靠的高可用架構(gòu)。雖然對于寫入密集型場景不是非常友好，但相信還是可以為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

參數(shù)配置：

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

轉(zhuǎn)自 美團點評基于MGR的CMDB高可用架構(gòu)搭建之路 https://www.toutiao.com/i6602060886867706376/

總結(jié)

以上是生活随笔為你收集整理的mysql+美团点评_美团点评Mysql高可用架构：MGR的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。