你好，我是悟空。

本篇主要內容如下：

目錄

背景

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

讀寫分離的方案

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

從節(jié)點崩了，部分流量打到主節(jié)點

但是最近遇到一個問題，MySQL 從節(jié)點上的服務無緣無故的崩了，查看日志也找不到什么端倪。

為了保證從節(jié)點的可用性，我們使用了 Keepalived 軟件來監(jiān)測從節(jié)點存活狀態(tài)，如果從節(jié)點崩了，則自動重啟 MySQL 容器。

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

一、排查記錄

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

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>，會顯示容器什么時候啟動和停止的。）

二、怎么理解讀寫分離

讀寫分離有個限制條件就是主庫可以用來做讀寫，從庫實時同步主庫數(shù)據(jù)，而且從庫是只讀的。

我們的項目中有統(tǒng)計功能就是連接從庫查詢數(shù)據(jù)，從庫不會進行數(shù)據(jù)更新的操作。

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

• 1、完全的讀寫分離：主庫只用來更新數(shù)據(jù)，從庫只用來查詢數(shù)據(jù)。
• 2、部分讀寫分離：主庫既可以用來讀數(shù)據(jù)，又可以進行查數(shù)據(jù)；從庫作為只讀的備庫，分擔耗性能的查詢工作。

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

部分讀寫分離

三、從節(jié)點的高可用如何保證？

3.1 保證從節(jié)點的可用性

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

提高從節(jié)點的可用性

3.2 從節(jié)點數(shù)據(jù)庫無法重啟了怎么辦？

目前從節(jié)點只有一個節(jié)點，如果從節(jié)點崩了，從哪執(zhí)行查詢？

有兩種方案：

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

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

四、實踐：保證從節(jié)點的可用性

這次我們要做的就是在在從節(jié)點開啟 Keepalived，以及修改重啟 MySQL 的腳本。從節(jié)點的 Keepalived 的 VIP 地址和主節(jié)點的 Keepalived 的 VIP 不一樣。

原理如下所示：

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

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

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

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

安裝好 keepalived 之后，執(zhí)行以下命令啟動。

systemctl start keepalived

啟動 keeaplived 服務

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

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

具體內容可以看這篇實戰(zhàn) MySQL 高可用架構

實戰(zhàn) MySQL 高可用架構目錄

4.2 如何監(jiān)測 MySQL 服務的健康狀況

keepalived 配置文件中定時監(jiān)測 MySQL 服務的健康狀況。

修改配置文件：

sudo vim /etc/keepalived/keepalived.conf

4.3 如何自動重啟 MySQL 服務

自動重啟 MySQL  的腳本之前也講解過，這里再貼一下。當 keepalived 檢測到 MySQL 無法連接時，就自動重啟 MySQL 容器。

如何自動重啟 MySQL 服務

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

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

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

修改配置文件：

sudo vim /etc/keepalived/keepalived.conf

如何自動重啟 MySQL 服務

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

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

五、總結

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

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

后續(xù)：如何讓項目實現(xiàn)讀寫分離？

關于我

8 年互聯(lián)網(wǎng)開發(fā)經(jīng)驗，擅長微服務、分布式、架構設計。目前在一家大型上市公司從事基礎架構和性能優(yōu)化工作。

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

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