在企業(yè)中，數(shù)據(jù)庫高可用一直是企業(yè)的重中之重，中小企業(yè)很多都是使用mysql主從方案，一主多從，讀寫分離等，但是單主存在單點(diǎn)故障，從庫切換成主庫需要作改動(dòng)。因此，如果是雙主或者多主，就會增加mysql入口，增加高可用。不過多主需要考慮自增長ID問題，這個(gè)需要特別設(shè)置配置文件，比如雙主，可以使用奇偶，總之，主之間設(shè)置自增長ID相互不沖突就能完美解決自增長ID沖突問題。

Linux系統(tǒng)環(huán)境：SUSE12.4

MySQL數(shù)據(jù)庫版本：5.7.29

Mysql數(shù)據(jù)庫架構(gòu)：雙主

由于業(yè)務(wù)側(cè)在做雙主架構(gòu)選擇的時(shí)候，沒有做VIP高可用冗余，所以只能實(shí)現(xiàn)普通的雙主基本復(fù)制功能，分別基于maser01和master02之間的讀寫同步復(fù)制。

生產(chǎn)中經(jīng)監(jiān)控平臺發(fā)現(xiàn)MySQL數(shù)據(jù)庫雙主復(fù)制中SQL復(fù)制線程斷開，經(jīng)排查發(fā)現(xiàn)雙主復(fù)制出現(xiàn)了異常，具體報(bào)錯(cuò)信息如下圖所示：在master02數(shù)據(jù)庫服務(wù)器上發(fā)現(xiàn)，同步master01數(shù)據(jù)庫服務(wù)器的SQL線程斷開了，截圖如下：

此時(shí)，檢查master01數(shù)據(jù)庫服務(wù)器的同步情況，發(fā)現(xiàn)master01同步master02的復(fù)制目前是正常顯示的。

4.1日志分析

通過查看日志文件發(fā)現(xiàn)如下報(bào)錯(cuò)信息：

通過上面日志分析，發(fā)現(xiàn)雙主同步復(fù)制異常存在兩種情況：

A：master01的表數(shù)據(jù)可能被truncate導(dǎo)致master02同步異常中斷；

B：或者是master01和master02之間數(shù)據(jù)復(fù)制過程中主鍵沖突導(dǎo)致同步異常中斷。最后我們來清查一下對應(yīng)報(bào)錯(cuò)的表數(shù)據(jù)在master01和master02兩個(gè)庫中的數(shù)據(jù)是否一致，如果不一致，那就說明其中一個(gè)庫中的數(shù)據(jù)被清理了，或者另一個(gè)庫中的表數(shù)據(jù)同步一直不一致導(dǎo)致同步異常。

4.2表數(shù)據(jù)核對

1）經(jīng)報(bào)錯(cuò)信息查詢該表數(shù)據(jù)統(tǒng)計(jì)記錄master02的表數(shù)據(jù)量為：462740條。

2）同時(shí)也記錄了master01數(shù)據(jù)庫上，該表的數(shù)據(jù)量為：462733條。與master02對比發(fā)現(xiàn)數(shù)據(jù)量少了7條。

4.3主鍵沖突

將master02上的這個(gè)表全表導(dǎo)出備份后，再將該表數(shù)據(jù)導(dǎo)入到master01中，最后還是報(bào)該表存在數(shù)據(jù)主鍵沖突，報(bào)錯(cuò)如下：

5.1表數(shù)據(jù)恢復(fù)

在導(dǎo)入過程中，需要關(guān)閉binlog的記錄setsql_log_bin=0，避免導(dǎo)入數(shù)據(jù)表時(shí)報(bào)ID主鍵列沖突數(shù)據(jù)刷新到日志中，這樣master01的表數(shù)據(jù)就會被master02的表數(shù)據(jù)全部置換，在主主同時(shí)寫同時(shí)復(fù)制的情況下，之前一樣的數(shù)據(jù)就沒有了，最后剩下的是7條不一致的數(shù)據(jù)。雖然把主主復(fù)制功能恢復(fù)了，但是這個(gè)cer_work_order_temp表數(shù)據(jù)被新的二進(jìn)制文件數(shù)據(jù)置換掉了，最終導(dǎo)致這表數(shù)據(jù)丟失。

5.2全量和增量恢復(fù)

通過全備+增量備份在測試環(huán)境對cer_work_order_temp表進(jìn)行數(shù)據(jù)恢復(fù)，先找到增量起始點(diǎn)position812016541結(jié)合二進(jìn)制日志進(jìn)行恢復(fù)該表在master02服務(wù)器上的數(shù)據(jù)。

第一個(gè)binlog日志恢復(fù)命令如下：

第二個(gè)binlog日志恢復(fù)命令如下：

因第二個(gè)日志mysql-bin.000026事務(wù)量比較大，如果像第一個(gè)binlog那樣恢復(fù)的話，時(shí)間會很慢，所以第二個(gè)日志binlog我們采用sql文件導(dǎo)入方式：

根據(jù)發(fā)生的故障時(shí)間點(diǎn)，進(jìn)行二進(jìn)制日志數(shù)據(jù)的提取，提取方式如下所示：

5.3主鍵修復(fù)

刪除原表主鍵，再重建新表及1條索引，目的為了導(dǎo)入數(shù)據(jù)不沖突，并且導(dǎo)入速度快。

5.4導(dǎo)入修復(fù)好的表數(shù)據(jù)

再把new_026.sql數(shù)據(jù)導(dǎo)入數(shù)據(jù)庫即可

5.5校驗(yàn)數(shù)據(jù)

最終數(shù)據(jù)查詢，如下查詢已經(jīng)恢復(fù)到原始數(shù)據(jù)量。

最后把這個(gè)表數(shù)據(jù)mysqldump到master01/master02數(shù)據(jù)庫，再把雙主復(fù)制功能恢復(fù)就可以了。

此次故障恢復(fù)還是算流暢的，沒有遇到較大的難點(diǎn)，數(shù)據(jù)庫服務(wù)器恢復(fù)正常后，也通知業(yè)務(wù)側(cè)那邊進(jìn)行數(shù)據(jù)校驗(yàn)，同時(shí)得到他們的認(rèn)可數(shù)據(jù)恢復(fù)一致，沒有問題再現(xiàn)。