這是悟空的第 157 篇原創文章
官網:www.passjava.cn
你好,我是悟空。
一、遇到的坑
一個月前,我們在測試環境部署了一套 MySQL 高可用架構,也就是 MySQL 雙主 + Keepalived 的模式。詳情看這篇:
在這一個月遇到了很多坑:
- 因爲兩個 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 高可用的事故,讓我重學了一遍它!
- END -
關於我
8 年互聯網開發經驗,擅長微服務、分佈式、架構設計。目前在一家大型上市公司從事基礎架構和性能優化工作。
InfoQ 簽約作者、藍橋簽約作者、阿里雲專家博主、51CTO 紅人。