你好，我是悟空。

本篇主要內容如下：

目錄

背景

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

讀寫分離的方案

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

從節點崩了，部分流量打到主節點

但是最近遇到一個問題，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

啟動 keeaplived 服務

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

sudo vim /etc/rc.local
添加以下命令
systemctl start keepalived

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

實戰 MySQL 高可用架構目錄

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

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

修改配置文件：

sudo vim /etc/keepalived/keepalived.conf

4.3 如何自動重啟 MySQL 服務

自動重啟 MySQL  的腳本之前也講解過，這里再貼一下。當 keepalived 檢測到 MySQL 無法連接時，就自動重啟 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

如何自動重啟 MySQL 服務

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

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

五、總結

我們項目采用了數據庫讀寫分離的模式，但是沒有對從節點做高可用，所以也遇到從節點不能提供服務的問題。

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

后續：如何讓項目實現讀寫分離？

關于我

8 年互聯網開發經驗，擅長微服務、分布式、架構設計。目前在一家大型上市公司從事基礎架構和性能優化工作。

InfoQ 簽約作者、藍橋簽約作者、阿里云專家博主、51CTO 紅人。

本文轉載自微信公眾號「  悟空聊架構」，可以通過以下二維碼關注。轉載本文請聯系悟空聊架構公眾號。