一個月後,我們又從 MySQL 雙主切換成了主-從!

語言: CN / TW / HK

這是悟空的第  157  篇原創文章

官網:www.passjava.cn

你好,我是悟空。

一、遇到的坑

一個月前,我們在測試環境部署了一套 MySQL 高可用架構,也就是 MySQL 雙主 + Keepalived 的模式。詳情看這篇:

實戰 MySQL 高可用架構

在這一個月遇到了很多坑:

  • 因為兩個 MySQL 節點都可以寫入,極其容易造成主鍵重複,進而導致主從同步失敗。

  • 同步失敗後,Slave_SQL_Thread 執行緒就停了,除非解決了同步的錯誤,才能繼續進行同步。

  • 同步失敗的錯誤,不會只有一條記錄有問題,往往是一大片的同步問題。

  • 兩個節點互相缺少對方的資料。

  • 主從的同步延遲,切換到新主庫後,資料不是最新。

  • 當出現不一致時,無法確定以哪個庫為準。

造成上面問題的主要原因就是因為兩個節點都支援寫入 + 雙主可以隨時切換。

解決這種問題的方案有 改進自增主鍵的步長(影響未評估),使用 GTID 方案(未驗證)。即使這樣,雙主同步的風險還是有,而且不同步後,如何處理是個大難題。

那麼回到我們最初的想法:為什麼會選擇雙主?

最開始的目的就是為了高可用。雙主就是說有一臺 MySQL 節點掛了,另外一臺能夠頂上,對於使用者來說是無感的,給運維人員一定的緩衝時間來排查 MySQL 故障。另外老的主節點恢復後,不用改配置就能立即成為從節點。

經過這一個月的 MySQL 雙主模式的試執行,最後我們還是決定切換到 MySQL 主-從模式。

雙主模式就是兩個節點即是主節點也是從節點,那我們現在切換到一主一從模式,就可以認為是降級。接下來我們聊聊雙主換成主從的思路和步驟。

二、雙主降為主從

雙主模式

雙主模式的原理圖如下:

兩個主節點,都安裝了 KeepAlived 高可用元件,對外提供了一個 VIP,只有一個節點接管 VIP,客戶端訪問的請求都是到這個 VIP,另外一個節點處於待機狀態。

主從模式

和雙主不一樣的地方如下,從節點是隻讀的。

一主一從是主從模式中的一種,具有以下特點:

  • 一個主節點,一個從節點,主節點提供給客戶端訪問,從節點只通過主節點的 binlog 進行資料同步。

  • 從節點是隻讀的。從節點可以作為只讀節點提供類似報表查詢等耗時讀操作。

  • 主節點宕機後,從節點成為主節點,也是高可用的一種方案。

相對於雙主的高可用方案,不同之處如下:

  • 主從切換需要用指令碼將從庫設定為可讀可寫。

  • 主從切換後,需要將從庫設定為不同步老主庫。

  • 主從切換後,老的主庫恢復後,需要人工設定為只讀,且開啟同步新主庫的功能。

這樣來看,主從模式在異常情況下,多了些人工操作。

在異常情況下,主從切換一般是這樣處理的:通過指令碼監測主節點是否宕機,如果主庫宕機了,則從庫自動切換為新的主庫,待老主庫恢復後,就作為從庫同步新主庫資料,新主庫上的 Keepalived 接管 VIP。

目前改為主從模式有兩種方式:

  • 簡單方式:人工切換模式,主節點故障後需要人工切換主從。

  • 複雜方式:高可用方式,主節點故障後,主從自動切換,讀寫分離自動切換。

本篇只涉及簡單方式,複雜方式的原理和配置步驟放到下篇專門講解。

三、改為主從的簡單方式

簡單方式的主從切換流程如下:

和雙主模式的主從切換的區別是,從節點是隻讀的,Keepalived 沒有啟動,需要人工操作主從切換和啟動 Keepalived。

修改配置的步驟如下:

① 為了避免從節點上的 Keepalived 自動接管 VIP 的情況出現,將從節點的 Keepalived 停止,如果遇到主節點故障,則需要人工干預來進行主從切換。從節點切換為主節點後,重新啟動從節點 Keepalived。

systemctl status keepalived

② 保留主節點的 Keepalived,保證 MySQL 的連線資訊都不需要變。

③ 主節點 node1 停用 MySQL 的同步執行緒。

STOP SLAVE

④ 從節點 node2 設定 MySQL 為只讀模式。

# 修改 my.cnf 檔案
read_only = 1

⑤ 移除主節點 node1 同步 node2 MySQL 的許可權。

⑥ 從節點 node1 的開機啟動項中移除 keepalived 服務自啟動。

# 修改啟動項配置
sudo vim /etc/rc.local
# 移除以下指令碼
systemctl start keepalived

四、總結

雙主高可用的坑確實比較多,沒有 MySQL 的硬核知識真的很難搞定。筆者在這一個月的實踐中,深刻體會到了雙主同步的難點所在,最後還是選擇了一主一從的模式。

另外因為最開始的配置都是雙主模式下的,所以要修改一些配置,來改為主從模式。 因專案時間比較緊,目前採取的是非高可用的主從模式

對於高可用的主從模式,因涉及的原理和步驟較多,我會在下篇中進行講解。各位卷王也請給我一點時間進行探索和實踐~

下一篇:實戰 MySQL 主從高可用。

推薦閱讀:

一次 Keepalived 高可用的事故,讓我重學了一遍它!

一次 MySQL 誤操作導致的事故,「高可用」都頂不住了!

實戰 MySQL 高可用架構

- END -

關於我

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

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

加入知識星球,一起來卷,門票價目前全網最低~星球內有打卡贈書活動,請及時參加~

悟空的多個技術專題:

33 篇 SpringCloud 實戰,回覆 PDF 獲取。

8 篇分散式演算法文章,回覆 分散式 獲取。

7 篇JVM 專項訓練,回覆 JVM 獲取。

Elasticsearch 筋斗雲版藍皮書1.0,回覆 ES 獲取

面試必備資料,關注即可獲取。↓↓

我是悟空,努力變強,變身超級賽亞人!