MGR MYSQL集群崩潰的修復方法

本篇內容主要講解“MGR MYSQL集群崩潰的修復方法”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MGR MYSQL集群崩潰的修復方法”吧!

生產即將部署MYSQL  MGR 的環境，進行對接銀行的項目，在測試系統上進行測試了的兩個月的MGR 沒有任何問題，出過一次問題，還是開發人員不大熟悉MYSQL 的原理，使用了大事務，將MYSQL MGR 卡死，經過幾分鐘的處理，一切正常，基本上幾百萬的數據的查詢都在秒級。完全不遜色其他數據庫產品的響應。

最近出了事情，所以必須要對任何系統的上線進行嚴控，這邊MYSQL MGR 上線需要進行嚴格的上線測試，得到目前MYSQL 集群能HOLD 住的數據量，這樣才能給運維和開發一個參數和數據承受范圍，避免一些不好的事情出現。

將SYSBENCH 搭建在 PROXYSQL 中間件上，開始壓測，初始沒有任何問題，后面加大壓測的數據量，30個表每個表500MB，30個線程，持續5分鐘，在PERPARE的時候，發現到第10個表系統已經沒有反應了，查詢了內存已經開始使用了 SWAP了，應該是內存已經爆了，停止系統的線程，發現無法停止。SHOW PROCESSLIST; 

發現大量 insert into 的語句開卡在線程池里面，手動清理，無效。

無意之間查看了磁盤空間，OMG，UNDO LOG 和 RELAY LOG 的空間已經爆了，100%的使用率。

此時查詢集群的狀態，集群已經處于失敗的狀態，（圖沒有留，下面的圖中的 MEMBER_STATE,應該是OFFILINE 的狀態了）

此時集群已經散掉了，查看日志，其實日志已經在昨天就已經報警了（因為壓力測試是前天做的，但是由于突發情況就沒有再管壓力測試，幾天在測，發現已經出了問題）

沒有良好的系統測試，無論是硬件方面的還是軟件方面的，都為未來的“重擊”買下了伏筆。

所幸，本次做了，所以在系統上線前發現了問題。

下面就是修復，在通知運維的同學后，添加了磁盤空間，然后系統重新集群的搭建和啟動。（MYSQL MGR 還是很健壯的，只是重啟了集群，將失敗的節點添加）

但此時第二個問題出來了，由于RELAY LOG的磁盤空間問題，已經有很多日志擠壓了.

最省事的方法就是BACKUP 主庫，然后在 RESTORE   到從庫，從起MGR 就可以了。如此也就放棄了，更深層次修復的MGR的技巧。首先我們先強制從節點啟動，馬上一堆擠壓的LOG 開始執行，由于在當時為了磁盤空間的問題，已經在主庫和從庫都刪除了測試數據庫。（僅僅為了試驗，上線的絕對禁止）

洪水一般的日志向STANDBY節點襲來，都是報日志與當前操作的環境不一致之造成的報錯，當下還是一直的執行，但后面突然停下來，原來是DROP DATABASE 這樣的操作又被卡主了，（這和MYSQL當時的可以容忍的復制ERROR有關，DDL操作是不能容忍的錯誤）這下數據庫從節點徹底鎖死。

好吧那就開始修復集群。

 （不熟悉MGR 和 GTID 原理的估計看下面就開始費勁了）

1 我們查看主節點的GTID 號

2620d5df-07e7-11e9-8fa8-005056ad4145:1-2740,

81f38f19-09d2-4144-8925-484ad1cb5c6f:1-1002,

bf79695c-0e78-11e9-9c14-005056ad1469:1

主庫的日志已經到了這個GTID 并且 是 MYSQL-BIN.000012

2 我們在看從庫的狀態

果然是不一樣，當然應該不一樣，要不集群就不會是失敗的狀態。

3 開始修復

我們先停止從節點

stop group_replicatiton;

清空當前GTID EXECUTED

reset master；

設置和主節點一樣的 EXECUTED_GTID_SET

啟動復制

start group_replication;

再次查看修復的那個從節點的狀態，已經上線了

查看對應的日志，OK 已經和主同步了，（如果你熟悉GTID的原理你就知道為什么了）

使用此種手段，修復第二個節點

修復成功，集群恢復工作。

再次驗證是否還有擠壓的 TRANSACTION LOG

沒有了，當然沒有了。

此種方法使用是有條件的，要根據當前的狀態，如果是復雜的狀態，還是建議用傳統的方法來進行恢復，不過如果你對你的MYSQL MGR 集群和相關系統的運作了解，你可以在緊急的狀況或測試環境做一遍，對了解MGR的原理和緊急狀態的修復會受益匪淺。

到此，相信大家對“MGR MYSQL集群崩潰的修復方法”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！