從節(jié)點(diǎn)崩了,還怎么「主從讀寫(xiě)分離」?
你好,我是悟空。
本篇主要內(nèi)容如下:
目錄
背景
我們的項(xiàng)目采用了讀寫(xiě)分離的方案:查詢(xún)和更新的業(yè)務(wù)走主庫(kù),統(tǒng)計(jì)相關(guān)的功能走從庫(kù),從而減少主庫(kù)的壓力。原理如下圖所示:
讀寫(xiě)分離的方案
如果從庫(kù)崩了,實(shí)在無(wú)法訪(fǎng)問(wèn)了,就會(huì)把所有請(qǐng)求打到主庫(kù)上。原理如下圖所示:
從節(jié)點(diǎn)崩了,部分流量打到主節(jié)點(diǎn)
但是最近遇到一個(gè)問(wèn)題,MySQL 從節(jié)點(diǎn)上的服務(wù)無(wú)緣無(wú)故的崩了,查看日志也找不到什么端倪。
為了保證從節(jié)點(diǎn)的可用性,我們使用了 Keepalived 軟件來(lái)監(jiān)測(cè)從節(jié)點(diǎn)存活狀態(tài),如果從節(jié)點(diǎn)崩了,則自動(dòng)重啟 MySQL 容器。
本篇將會(huì)講解沒(méi)什么卵用的排查記錄,以及如何保證從節(jié)點(diǎn)可用性,注意,還不是完全的高可用。
一、排查記錄
雖說(shuō)沒(méi)有找到 MySQL 從節(jié)點(diǎn)容器真正崩了的原因,但是這排查記錄還是得記錄下。
1.1 查看 MySQL 的容器日志
2023-02-08 6:27:30 開(kāi)始 Shutdown 了,沒(méi)有提示為什么 shutdown。
2023-02-08 6:27:34 Shutdown 完成。
1.2 查看 MySQL 的錯(cuò)誤日志
可以看到 6:27:30 沒(méi)有異常日志。
這不就尷尬了,完全不知道為啥崩了。
(備注:另外也可以看下容器的信息,docker inspect <容器 id>,會(huì)顯示容器什么時(shí)候啟動(dòng)和停止的。)
二、怎么理解讀寫(xiě)分離
讀寫(xiě)分離有個(gè)限制條件就是主庫(kù)可以用來(lái)做讀寫(xiě),從庫(kù)實(shí)時(shí)同步主庫(kù)數(shù)據(jù),而且從庫(kù)是只讀的。
我們的項(xiàng)目中有統(tǒng)計(jì)功能就是連接從庫(kù)查詢(xún)數(shù)據(jù),從庫(kù)不會(huì)進(jìn)行數(shù)據(jù)更新的操作。
讀寫(xiě)分離我認(rèn)為可以分為兩種:
- 1、完全的讀寫(xiě)分離:主庫(kù)只用來(lái)更新數(shù)據(jù),從庫(kù)只用來(lái)查詢(xún)數(shù)據(jù)。
- 2、部分讀寫(xiě)分離:主庫(kù)既可以用來(lái)讀數(shù)據(jù),又可以進(jìn)行查數(shù)據(jù);從庫(kù)作為只讀的備庫(kù),分擔(dān)耗性能的查詢(xún)工作。
我們項(xiàng)目采用的是第二種方案,涉及到 I/O 密集型的查詢(xún)工作就交給 MySQL 從庫(kù)去處理。
部分讀寫(xiě)分離
三、從節(jié)點(diǎn)的高可用如何保證?
3.1 保證從節(jié)點(diǎn)的可用性
采用 keepalived 自動(dòng)檢測(cè) MySQL 服務(wù)是否正常,如果不正常,自動(dòng)重啟 MySQL 容器。
提高從節(jié)點(diǎn)的可用性
3.2 從節(jié)點(diǎn)數(shù)據(jù)庫(kù)無(wú)法重啟了怎么辦?
目前從節(jié)點(diǎn)只有一個(gè)節(jié)點(diǎn),如果從節(jié)點(diǎn)崩了,從哪執(zhí)行查詢(xún)?
有兩種方案:
- 方案一:讀操作切換到主庫(kù)去查詢(xún)。帶來(lái)的問(wèn)題:主庫(kù)的壓力會(huì)很大。
- 方案二:部署兩個(gè)從節(jié)點(diǎn),從節(jié)點(diǎn)之間相互同步數(shù)據(jù),只有一個(gè)從節(jié)點(diǎn)提供服務(wù),另外一個(gè)節(jié)點(diǎn)作為備用從庫(kù),前者崩了的話(huà),流量自動(dòng)切換到后者。(需要兩個(gè)節(jié)點(diǎn)開(kāi)啟 Keepalived 來(lái)提供流量切換的能力)帶來(lái)的問(wèn)題:部署的復(fù)雜性,主從同步延遲。
目前我們采用的是第一種方案,如果從節(jié)點(diǎn)崩了,讀操作會(huì)切換到主庫(kù)上去執(zhí)行。所以保證從節(jié)點(diǎn)不崩就很重要了。
四、實(shí)踐:保證從節(jié)點(diǎn)的可用性
這次我們要做的就是在在從節(jié)點(diǎn)開(kāi)啟 Keepalived,以及修改重啟 MySQL 的腳本。從節(jié)點(diǎn)的 Keepalived 的 VIP 地址和主節(jié)點(diǎn)的 Keepalived 的 VIP 不一樣。
原理如下所示:
從節(jié)點(diǎn)首先得安裝和配置 keepalived 在之前的文章中已經(jīng)詳細(xì)講解過(guò)了。
我在講解主主切換的文章中提到過(guò) keepalived 承擔(dān)的職責(zé)是就是監(jiān)測(cè) MySQL 服務(wù)是否正常,如果不正常,則重啟 MySQL,如果重啟失敗,則退出 keepalived,自動(dòng)將流量切換到另外一個(gè)節(jié)點(diǎn)。
這次的從節(jié)點(diǎn)只作為備庫(kù),沒(méi)有切換到主庫(kù)的要求,所以在主庫(kù)宕機(jī)后,不需要接管讀寫(xiě)的流量。
4.1 啟動(dòng) keeaplived 服務(wù)以及開(kāi)機(jī)自啟動(dòng)
安裝好 keepalived 之后,執(zhí)行以下命令啟動(dòng)。
啟動(dòng) keeaplived 服務(wù)
還需要設(shè)置 keepalived 開(kāi)機(jī)自啟動(dòng)。
具體內(nèi)容可以看這篇實(shí)戰(zhàn) MySQL 高可用架構(gòu)
實(shí)戰(zhàn) MySQL 高可用架構(gòu)目錄
4.2 如何監(jiān)測(cè) MySQL 服務(wù)的健康狀況
keepalived 配置文件中定時(shí)監(jiān)測(cè) MySQL 服務(wù)的健康狀況。
修改配置文件:
4.3 如何自動(dòng)重啟 MySQL 服務(wù)
自動(dòng)重啟 MySQL 的腳本之前也講解過(guò),這里再貼一下。當(dāng) keepalived 檢測(cè)到 MySQL 無(wú)法連接時(shí),就自動(dòng)重啟 MySQL 容器。
如何自動(dòng)重啟 MySQL 服務(wù)
4.3 如何不讓 Keepalived 切換流量到其他機(jī)器
因?yàn)橹鞴?jié)點(diǎn)也是開(kāi)啟了 Keepalived,如果主從的 Keepalived 的 VIP 都是同一個(gè)(之前配置的是 192.168.56.88),那么如果主節(jié)點(diǎn)崩了,就會(huì)將流量自動(dòng)切換到從節(jié)點(diǎn),因?yàn)槲覀冞@個(gè)從節(jié)點(diǎn)只作為備庫(kù),不需要它升級(jí)為主庫(kù),所以可以將主從節(jié)點(diǎn)的 Keepalived 的 VIP 設(shè)置為不一樣,這樣的話(huà),從節(jié)點(diǎn)就不會(huì)升級(jí)為主節(jié)點(diǎn)。
這里我們就把之前的 VIP 192.168.56.88? 改為 192.168.56.89。
修改配置文件:
如何自動(dòng)重啟 MySQL 服務(wù)
同時(shí)重啟腳本中,有一行命令是強(qiáng)制退出 keepalived(killall keepalived),這行命令可以讓 Keepalived 就有將流量切換到其他機(jī)器的能力。如果讓 keepalived 強(qiáng)制退出,則會(huì)將流量切換到另外一臺(tái) keepalived 還存活的機(jī)器上。
這里不需要切換,就可以注釋掉這行命令。
五、總結(jié)
我們項(xiàng)目采用了數(shù)據(jù)庫(kù)讀寫(xiě)分離的模式,但是沒(méi)有對(duì)從節(jié)點(diǎn)做高可用,所以也遇到從節(jié)點(diǎn)不能提供服務(wù)的問(wèn)題。
本篇通過(guò)一次 MySQL 從節(jié)點(diǎn)崩了的事件,引出了如何對(duì)從節(jié)點(diǎn)做高可用,然后從實(shí)踐的角度詳細(xì)講解了如何去配置 keepalived 來(lái)保證從節(jié)點(diǎn)的高可用。
后續(xù):如何讓項(xiàng)目實(shí)現(xiàn)讀寫(xiě)分離?
關(guān)于我
8 年互聯(lián)網(wǎng)開(kāi)發(fā)經(jīng)驗(yàn),擅長(zhǎng)微服務(wù)、分布式、架構(gòu)設(shè)計(jì)。目前在一家大型上市公司從事基礎(chǔ)架構(gòu)和性能優(yōu)化工作。
InfoQ 簽約作者、藍(lán)橋簽約作者、阿里云專(zhuān)家博主、51CTO 紅人。
本文轉(zhuǎn)載自微信公眾號(hào)「 悟空聊架構(gòu)」,可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系悟空聊架構(gòu)公眾號(hào)。