上次我們項(xiàng)目不是把 MySQL 高可用部署好了么，MySQL 雙主模式 + Keepalived，來(lái)保證高可用。簡(jiǎn)單來(lái)說(shuō)就是有兩個(gè) MySQL 主節(jié)點(diǎn)，分別有兩個(gè) Keepalived 安裝在宿主機(jī)上監(jiān)控 MySQL 的狀態(tài)，一旦發(fā)現(xiàn)有問(wèn)題，就重啟 MySQL，而客戶(hù)端也會(huì)自動(dòng)連接到另外一臺(tái) MySQL。

詳情可以看悟空寫(xiě)的這篇：??實(shí)戰(zhàn) MySQL 高可用架構(gòu)??

這次是我們?cè)陧?xiàng)目中遇到的一次事故，來(lái)一起復(fù)盤(pán)下吧。

本文目錄如下：

?事故現(xiàn)場(chǎng)

• 環(huán)境：測(cè)試環(huán)境
• 時(shí)間：上午10:30
• 反饋人員：測(cè)試群，炸鍋了，研發(fā)同事初步排查后，發(fā)現(xiàn)可能是數(shù)據(jù)庫(kù)問(wèn)題。

然后就開(kāi)始找原因吧。因?yàn)檫@套集群環(huán)境是我部署的，所以我來(lái)排查的話(huà)輕車(chē)熟路。

系統(tǒng)部署圖

先說(shuō)下系統(tǒng)的部署圖，方便大家理解。

兩個(gè)數(shù)據(jù)庫(kù)部署在 node55 和 node56 節(jié)點(diǎn)上，他們互為主從關(guān)系，所以叫做雙主。

還有兩個(gè) Keepalived 部署在 node55 和 node56 上面，分別監(jiān)控 MySQL 容器的狀態(tài)。

?報(bào)錯(cuò)原因和解決方案

① 我第一個(gè)想法就是，不是有 Keepalived 來(lái)保證高可用么，即使 MySQL 掛了，也可以通過(guò) Keepalived 來(lái)自動(dòng)重啟才對(duì)。即使一臺(tái)重啟不起來(lái)，還有另外一臺(tái)可以用的吧？

② 那就到服務(wù)器上看下 MySQL 容器的狀態(tài)吧。到 MySQL 的兩臺(tái)服務(wù)器上，先看下 MySQL 容器的狀態(tài)，docker ps  命令，發(fā)現(xiàn)兩臺(tái) MySQL 容器都不在列表中，這代表容器沒(méi)正常運(yùn)行。

③ 這不可能，我可是安裝了 Keepalived 高可用組件的，難道 Keepalived 也掛了？

④ 趕緊檢查一波 Keepalived，發(fā)現(xiàn)兩臺(tái) Keepalived 是正常運(yùn)行的。通過(guò)執(zhí)行命令查看：systemctl status keepalived

⑤ 納尼，Keepalived 也是正常的， Keepalived 每隔幾秒會(huì)重啟 MySQL，可能我在那一小段空閑時(shí)間沒(méi)看到 MySQL 容器啟動(dòng)？換個(gè)命令執(zhí)行下，docker ps -a，列出所有容器的狀態(tài)?？梢钥吹?MySQL 啟動(dòng)后又退出了，說(shuō)明 MySQL 確實(shí)是在重啟。

⑥ 那說(shuō)明 Keepalived 雖然重啟了 MySQL 容器，但是 MySQL 自身有問(wèn)題，那 Keepalived 的高可用也沒(méi)辦法了。

⑦ 那怎么整？只能看下 MySQL 報(bào)什么錯(cuò)了。執(zhí)行查看容器日志的命令。docker logs <容器 id>。找到最近發(fā)生的日志：

⑧ 提示 mysql-bin.index 文件不存在，這個(gè)文件是配置在主從同步那里的，在 my.cnf 配置里面。

這個(gè)配置好后，然后執(zhí)行主從同步的時(shí)候，就會(huì)在 var/lib/mysql/log 目錄下生成多個(gè) mysql-bin.xxx? 的文件。還有一個(gè) mysql-bin.index? 索引文件，它會(huì)標(biāo)記現(xiàn)在 binlog 日志文件記錄到哪里了。

mysql-bin.index 文件里面的內(nèi)容如下：

/var/lib/mysql/log/mysql-bin.000001

這個(gè) mysql-bin.000001 文件還是帶序號(hào)的，這里還有坑，后面我再說(shuō)。

⑨ 報(bào)錯(cuò)信息是提示缺少 mysql-bin.index，那我們就去檢查下唄，確實(shí)沒(méi)有??！先不管這個(gè)文件怎么消失的吧，趕緊把這個(gè) log 文件夾先創(chuàng)建出來(lái)，然后 mysql 會(huì)自動(dòng)給我們生成這個(gè)文件的。

解決方案：執(zhí)行以下命令創(chuàng)建文件夾和添加權(quán)限。

mkdir log
chmod 777 log -R

⑩ 兩臺(tái)服務(wù)器上都有這個(gè) log 目錄后，Keepalived 也幫我們自動(dòng)重啟好了 MySQL 容器，再來(lái)訪(fǎng)問(wèn)下其中一個(gè)節(jié)點(diǎn) node56 的 MySQL 的狀態(tài)，咦，居然報(bào)錯(cuò)了。

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

可以看到幾個(gè)關(guān)鍵信息：

• Slave_IO_Running: NO，當(dāng)前同步的 I/O 線(xiàn)程沒(méi)有運(yùn)行，這個(gè) I/O 線(xiàn)程是從庫(kù)的，它會(huì)去請(qǐng)求主庫(kù)的 binlog，并將得到的 binlog 寫(xiě)到本地的 relay-log (中繼日志)文件中。沒(méi)有運(yùn)行，則代表從庫(kù)同步是沒(méi)有正常運(yùn)行。
• Master_Log_File: mysql-bin.000014，說(shuō)明當(dāng)前同步的日志文件為??000014??，之前我們看到節(jié)點(diǎn) node56 上 mysql.index 里面寫(xiě)的是 000001，這個(gè) 000014 根本就不在 index 文件里面，所以就會(huì)報(bào)錯(cuò)了。

這里涉及到主從同步的原理，上一張圖：

• 從庫(kù)會(huì)生成兩個(gè)線(xiàn)程,一個(gè) I/O 線(xiàn)程,一個(gè) SQL 線(xiàn)程;
• I/O線(xiàn)程會(huì)去請(qǐng)求主庫(kù)的 binlog 日志文件,并將得到的 binlog 日志文件 寫(xiě)到本地的 relay-log (中繼日志)文件中;
• 主庫(kù)會(huì)生成一個(gè) dump 線(xiàn)程,用來(lái)給從庫(kù) I/O 線(xiàn)程傳 binlog;
• SQL線(xiàn)程，會(huì)讀取 relay log 文件中的日志,并解析成 SQL 語(yǔ)句逐一執(zhí)行。

那好辦啊，我們重新指定下同步哪個(gè)日志文件，以及同步的位置就好了。

?解決方案：

看下主庫(kù) node55 上日志文件狀態(tài)。

記下這兩個(gè)信息：File=mysql-bin.00001，Position=117748。（這里也有個(gè)坑：先要鎖表，再看這兩個(gè)值，從庫(kù)開(kāi)始同步后，再解鎖表）。

具體執(zhí)行的命令如下：

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS
UNLOCK TABLES

然后在從庫(kù) node56 上重新指定同步的日志文件和位置：

# 停止從庫(kù)同步
STOP SLAVE;

# 設(shè)置同步文件和位置
CHANGE MASTER TO MASTER_HOST='10.2.1.55',
MASTER_PORT=3306,
MASTER_USER='vagrant',
MASTER_PASSWORD='vagrant',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=117748;

# 開(kāi)啟同步
START SLAVE;

再次查看就不報(bào)錯(cuò)了，I/O 線(xiàn)程也跑起來(lái)了，

在這里插入圖片描述

然后將 node55 當(dāng)做從庫(kù)，node56 當(dāng)做主庫(kù)，同樣執(zhí)行上面的幾步，狀態(tài)顯示正常了，然后用 navicat 工具連下數(shù)據(jù)庫(kù)，都是正常的，在測(cè)試群反饋下結(jié)果，搞定收工。

?好像忘了一個(gè)問(wèn)題，為啥 log 文件夾被干掉了？？

為什么會(huì)出現(xiàn)問(wèn)題？

然后問(wèn)了一波當(dāng)時(shí)有沒(méi)有人刪除這個(gè) /var/lib/mysql/log 目錄，也沒(méi)有人會(huì)隨便刪除這個(gè)目錄的吧。

但是發(fā)現(xiàn) log 的上級(jí)目錄 /var/lib/mysql 有很多其他文件夾，比如 xxcloud, xxcenter 等。這不就是我們項(xiàng)目中幾個(gè)數(shù)據(jù)庫(kù)的名字么，只要在這個(gè)目錄的文件夾，都會(huì)顯示在 navicat 上，是一一對(duì)應(yīng)的，如下圖所示。其中也顯示了 log 數(shù)據(jù)庫(kù)。

那會(huì)不會(huì)有人從 navicat 上干掉了 log 數(shù)據(jù)庫(kù)？極有可能??！

果然，有位同事之前在遷移升級(jí)的過(guò)程中，發(fā)現(xiàn)這個(gè) log 數(shù)據(jù)庫(kù)在老的系統(tǒng)是沒(méi)有的，所以就清理了，這就相當(dāng)于把 log 數(shù)據(jù)庫(kù)干掉了，同時(shí)也會(huì)把 log 文件夾干掉了。好了，終于水落石出了！這個(gè)其實(shí)也是我前期沒(méi)有考慮到 log 目錄的一個(gè)問(wèn)題。沒(méi)錯(cuò)，這是我的鍋~

改進(jìn)

其實(shí)操作同步數(shù)據(jù)庫(kù)的時(shí)候，不應(yīng)該用這種覆蓋同步的方式，可以采取單庫(kù)同步的方式，也就不會(huì)干掉 log 數(shù)據(jù)庫(kù)了。但是，這個(gè) log 數(shù)據(jù)庫(kù)放在這里有點(diǎn)奇怪啊，能不能不要出現(xiàn)在這里呢？

我們只要指定這個(gè) log 目錄不在  /var/lib/mysql 目錄下就好了。

東哥建議：log 文件和數(shù)據(jù)庫(kù) data 文件進(jìn)行隔離：

• datadir = /var/lib/mysql/data
• log_bin = /var/lib/mysql/log

?另外一個(gè)問(wèn)題，我們的高可用真的高可用了嗎？

至少?zèng)]有做到及時(shí)報(bào)警，MySQL 數(shù)據(jù)庫(kù)掛了，我是不知道的，都是通過(guò)測(cè)試同學(xué)反饋的。

能不能及時(shí)感知到 MySQL 異常呢？

這里可以利用 Keepalived 發(fā)送郵件的功能，或者通過(guò)日志報(bào)警系統(tǒng)。這個(gè)是后面需要改進(jìn)的地方。