MYSQL Group replication Crash 的快速恢復(fù)方法是怎樣的

這篇文章給大家介紹MYSQL Group replication Crash 的快速恢復(fù)方法是怎樣的，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

最近，在檢測開發(fā)的語句后，發(fā)現(xiàn)有些語句的問題，根本不在語句優(yōu)化，MYSQL的系統(tǒng)優(yōu)化，慢的根本原因是，客戶的要求太奇葩。

奇葩到什么程度，要求每次啟動頁面后，要顯示200多萬條數(shù)據(jù)，這是我在檢測語句和優(yōu)化語句后，發(fā)現(xiàn)的問題，并且詢問開發(fā)人員，開發(fā)人員告知，由于客戶不大懂IT 技術(shù)，按照自己的想法要求，并認(rèn)為這并不是什么難事。

個人觀點，這樣的客戶我們的引導(dǎo)，教化，雖然在21世紀(jì)，還是要允許有些人不懂IT的邏輯，終歸人家不是做這方面工作的，這就要求我們的工作的深度和廣度。

好了話歸正題，MGR 崩潰的后怎么來快速修復(fù)，這里的方法首先是快速的并且是穩(wěn)定的，能應(yīng)對任何環(huán)境中的。當(dāng)然方法既然這么好那么好，必然有他的限制。

系統(tǒng)是怎么壞的，這個系統(tǒng)本來是一個測試，但這個系統(tǒng)上的架設(shè)的測試時馬上就要上線的系統(tǒng)并且由于測試人員也在測試，所以這個測試系統(tǒng)就變得不那么“測試” 了，壞了會有很多人 challange 你。

具體過程時這樣的，由于壓力測試需求，這個機(jī)器上的內(nèi)存已經(jīng)開始使用SWAP了，其實這里和運維人員還有一段交流，就是他們認(rèn)為從虛擬機(jī)上看內(nèi)存交換不頻繁就說明內(nèi)存不缺少。我個人是不大同意這樣的觀點的，首先數(shù)據(jù)庫和其他基礎(chǔ)設(shè)施不一樣，內(nèi)存必須富裕，另一個問題是，數(shù)據(jù)庫都是原因自己HOLD 內(nèi)存的，就算是MYSQL 這樣把很多系統(tǒng)和內(nèi)存的管理都交給 LINUX 系統(tǒng)的東西還是愿意 H 住更多的內(nèi)存。

雖然是虛擬機(jī)，但添加內(nèi)存還是要關(guān)機(jī)，（我怎么記得，虛擬機(jī)添加內(nèi)存都應(yīng)該是在線的），當(dāng)然如果在線添加，也就不會有這段子和這篇文字了。

在關(guān)閉集群的機(jī)器后，添加內(nèi)存后，啟動MYSQL，重做了集群的初始化，并且將另一臺機(jī)器添加到集群中，在添加另一臺機(jī)器的過程中報錯。

嘗試，重新添加機(jī)器，到集群失敗。這里采用了最快速的方法，備份在恢復(fù)的手段，選中其中一臺機(jī)器進(jìn)行備份，備份后將數(shù)據(jù)恢復(fù)到已經(jīng)損壞的機(jī)器中，重新啟動機(jī)器，但還是報錯。

報錯信息如上，看了是GTID 重復(fù)執(zhí)行的問題， 直接在對應(yīng)的庫上停止復(fù)制，然后reset 主機(jī)信息， 然后重新設(shè)置  gtid_purged  (相關(guān)的信息從備份中找)。然后在

重新啟動集群加入節(jié)點

相關(guān)的機(jī)器已經(jīng)回到集群中并開始工作

修復(fù)的過程看似上面簡單，其實為了找尋其他的方法和其實過程時曲折和糟心的（這里就不說了）。好在早上開始工作前，這個事情結(jié)束了，要不又一天很難過。

關(guān)于MYSQL Group replication Crash 的快速恢復(fù)方法是怎樣的就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。