從節點崩了，還怎麼「主從讀寫分離」？

本篇主要內容如下：

背景

我們的專案採用了讀寫分離的方案：查詢和更新的業務走主庫，統計相關的功能走從庫，從而減少主庫的壓力。原理如下圖所示：

如果從庫崩了，實在無法訪問了，就會把所有請求打到主庫上。原理如下圖所示：

但是最近遇到一個問題，MySQL 從節點上的服務無緣無故的崩了，檢視日誌也找不到什麼端倪。

為了保證從節點的可用性，我們使用了 Keepalived 軟體來監測從節點存活狀態，如果從節點崩了，則自動重啟 MySQL 容器。

本篇將會講解沒什麼卵用的排查記錄，以及如何保證從節點可用性，注意，還不是完全的高可用。

一、排查記錄

雖說沒有找到 MySQL 從節點容器真正崩了的原因，但是這排查記錄還是得記錄下。

1.1 檢視 MySQL 的容器日誌

docker logs 043 --tail 200

2023-02-08 6:27:30 開始 Shutdown 了，沒有提示為什麼 shutdown。

2023-02-08 6:27:34 Shutdown 完成。

1.2 檢視 MySQL 的錯誤日誌

cat /var/log/mysql/error.log
這個路徑在 my.cnf 配置。

可以看到 6:27:30 沒有異常日誌。

這不就尷尬了，完全不知道為啥崩了。

（備註：另外也可以看下容器的資訊，docker inspect <容器 id>，會顯示容器什麼時候啟動和停止的。）

二、怎麼理解讀寫分離

讀寫分離有個限制條件就是主庫可以用來做讀寫，從庫實時同步主庫資料，而且從庫是隻讀的。

我們的專案中有統計功能就是連線從庫查詢資料，從庫不會進行資料更新的操作。

讀寫分離我認為可以分為兩種：

• 1、完全的讀寫分離：主庫只用來更新資料，從庫只用來查詢資料。
• 2、部分讀寫分離：主庫既可以用來讀資料，又可以進行查資料；從庫作為只讀的備庫，分擔耗效能的查詢工作。

我們專案採用的是第二種方案，涉及到 I/O 密集型的查詢工作就交給 MySQL 從庫去處理。

三、從節點的高可用如何保證？

3.1 保證從節點的可用性

採用 keepalived 自動檢測 MySQL 服務是否正常，如果不正常，自動重啟 MySQL 容器。

3.2 從節點資料庫無法重啟了怎麼辦？

目前從節點只有一個節點，如果從節點崩了，從哪執行查詢？

有兩種方案：

• 方案一：讀操作切換到主庫去查詢。帶來的問題：主庫的壓力會很大。
• 方案二：部署兩個從節點，從節點之間相互同步資料，只有一個從節點提供服務，另外一個節點作為備用從庫，前者崩了的話，流量自動切換到後者。（需要兩個節點開啟 Keepalived 來提供流量切換的能力）帶來的問題：部署的複雜性，主從同步延遲。

目前我們採用的是第一種方案，如果從節點崩了，讀操作會切換到主庫上去執行。所以保證從節點不崩就很重要了。

四、實踐：保證從節點的可用性

這次我們要做的就是在在從節點開啟 Keepalived，以及修改重啟 MySQL 的指令碼。從節點的 Keepalived 的 VIP 地址和主節點的 Keepalived 的 VIP 不一樣。

原理如下所示：

從節點首先得安裝和配置 keepalived 在之前的文章中已經詳細講解過了。

我在講解主主切換的文章中提到過 keepalived 承擔的職責是就是監測 MySQL 服務是否正常，如果不正常，則重啟 MySQL，如果重啟失敗，則退出 keepalived，自動將流量切換到另外一個節點。

這次的從節點只作為備庫，沒有切換到主庫的要求，所以在主庫當機後，不需要接管讀寫的流量。

4.1 啟動 keeaplived 服務以及開機自啟動

安裝好 keepalived 之後，執行以下命令啟動。

systemctl start keepalived

還需要設定 keepalived 開機自啟動。

sudo vim /etc/rc.local
新增以下命令
systemctl start keepalived

具體內容可以看這篇實戰 MySQL 高可用架構

4.2 如何監測 MySQL 服務的健康狀況

keepalived 配置檔案中定時監測 MySQL 服務的健康狀況。

修改配置檔案：

sudo vim /etc/keepalived/keepalived.conf

4.3 如何自動重啟 MySQL 服務

自動重啟 MySQL  的指令碼之前也講解過，這裡再貼一下。當 keepalived 檢測到 MySQL 無法連線時，就自動重啟 MySQL 容器。

4.3 如何不讓 Keepalived 切換流量到其他機器

因為主節點也是開啟了 Keepalived，如果主從的 Keepalived 的 VIP 都是同一個（之前配置的是 192.168.56.88），那麼如果主節點崩了，就會將流量自動切換到從節點，因為我們這個從節點只作為備庫，不需要它升級為主庫，所以可以將主從節點的 Keepalived 的 VIP 設定為不一樣，這樣的話，從節點就不會升級為主節點。

這裡我們就把之前的 VIP 192.168.56.88 改為 192.168.56.89。

修改配置檔案：

sudo vim /etc/keepalived/keepalived.conf

同時重啟指令碼中，有一行命令是強制退出 keepalived（killall keepalived），這行命令可以讓 Keepalived 就有將流量切換到其他機器的能力。如果讓 keepalived 強制退出，則會將流量切換到另外一臺 keepalived 還存活的機器上。

這裡不需要切換，就可以註釋掉這行命令。

五、總結

我們專案採用了資料庫讀寫分離的模式，但是沒有對從節點做高可用，所以也遇到從節點不能提供服務的問題。

本篇透過一次 MySQL 從節點崩了的事件，引出瞭如何對從節點做高可用，然後從實踐的角度詳細講解了如何去配置 keepalived 來保證從節點的高可用。

後續：如何讓專案實現讀寫分離？