一、遇到的坑
一個月前，我們在測試環境部署了一套 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。
② 保留主節點的 Keepalived，保證 MySQL 的連接信息都不需要變。
③ 主節點 node1 停用 MySQL 的同步線程。
④ 從節點 node2 設置 MySQL 為只讀模式。
⑤ 移除主節點 node1 同步 node2 MySQL 的權限。
⑥ 從節點 node1 的開機啟動項中移除 keepalived 服務自啟動。
四、總結
雙主高可用的坑確實比較多，沒有 MySQL 的硬核知識真的很難搞定。筆者在這一個月的實踐中，深刻體會到了雙主同步的難點所在，最后還是選擇了一主一從的模式。
另外因為最開始的配置都是雙主模式下的，所以要修改一些配置，來改為主從模式。因項目時間比較緊，目前采取的是非高可用的主從模式。
對于高可用的主從模式，因涉及的原理和步驟較多，我會在下篇中進行講解。各位卷王也請給我一點時間進行探索和實踐~
