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

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

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

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

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

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

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

4.1日志分析

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

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

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

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

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

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

2）同時(shí)也記錄了master01數(shù)據(jù)庫(kù)上，該表的數(shù)據(jù)量為：462733條。與master02對(duì)比發(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ò)程中，需要關(guān)閉binlog的記錄setsql_log_bin=0，避免導(dǎo)入數(shù)據(jù)表時(shí)報(bào)ID主鍵列沖突數(shù)據(jù)刷新到日志中，這樣master01的表數(shù)據(jù)就會(huì)被master02的表數(shù)據(jù)全部置換，在主主同時(shí)寫同時(shí)復(fù)制的情況下，之前一樣的數(shù)據(jù)就沒(méi)有了，最后剩下的是7條不一致的數(shù)據(jù)。雖然把主主復(fù)制功能恢復(fù)了，但是這個(gè)cer_work_order_temp表數(shù)據(jù)被新的二進(jìn)制文件數(shù)據(jù)置換掉了，最終導(dǎo)致這表數(shù)據(jù)丟失。

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

通過(guò)全備+增量備份在測(cè)試環(huán)境對(duì)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í)間會(huì)很慢，所以第二個(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ù)庫(kù)即可

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

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

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

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