王志朋

美團點評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/