作者 王志朋|美團(tuán)點(diǎn)評(píng)DBA

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

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

一、背景

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

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

二、關(guān)于MGR

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

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

三、解決方案

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

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

MGR的限制；

相關(guān)測(cè)試；

合理的參數(shù)。

1.MGR的限制

只支持InnoDB存儲(chǔ)引擎；

必須有主鍵；

binlog_format只支持ROW格式；

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

……

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

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

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

2.MGR的參數(shù)

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

(MGR節(jié)點(diǎn)的幾個(gè)狀態(tài))

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

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

3.最終架構(gòu)

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

四、上線歷程

美團(tuán)點(diǎn)評(píng)從2018年以來，總共將三個(gè)系統(tǒng)遷移上線了MGR，包括流程系統(tǒng)、報(bào)表系統(tǒng)以及CMDB。

五、典型問題

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

1.大事務(wù)

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

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

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

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

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

2. 應(yīng)用HANG死

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

此時(shí)我們?cè)贒BA的慢查詢監(jiān)控中發(fā)現(xiàn)一個(gè)峰值，時(shí)間點(diǎn)基本吻合。下圖為慢查詢監(jiān)控：

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

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

3. 機(jī)房故障

第三個(gè)問題發(fā)生在一次實(shí)際的機(jī)房故障中：CMDB主節(jié)點(diǎn)所在機(jī)房網(wǎng)絡(luò)帶寬減半，導(dǎo)致CMDB的MGR集群和一套業(yè)務(wù)主從集群幾乎同時(shí)發(fā)生了切換，MGR的切換時(shí)間大概在3s左右，業(yè)務(wù)基本無感知，只發(fā)生部分報(bào)錯(cuò)，但業(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實(shí)現(xiàn)的一套MGR切換自動(dòng)選主、讀寫分離的功能。對(duì)于熟悉Python訪問MySQL的同學(xué)上手非常簡(jiǎn)單。

七、日常運(yùn)維

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

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

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

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

八、寫在最后

通過我們一系列的線上演練，甚至包括部分高峰期的演練，以及一段時(shí)間的運(yùn)行狀態(tài)觀察，MGR確實(shí)是一個(gè)穩(wěn)定、可靠的高可用架構(gòu)。雖然對(duì)于寫入密集型場(chǎng)景不是非常友好，但相信還是可以為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)自 美團(tuán)點(diǎn)評(píng)基于MGR的CMDB高可用架構(gòu)搭建之路 https://www.toutiao.com/i6602060886867706376/

總結(jié)

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

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