10款常見MySQL高可用方案選型解讀
原文地址
作者介紹
王松磊，現任職於UCloud，從事MySQL數據庫內核研發工作。主要負責UCloud雲數據庫udb的內核故障排查工作以及數據庫新特性的研發工作。
一、概述
我們在考慮MySQL數據庫的高可用架構時，主要考慮如下幾方面：
-
如果數據庫發生了宕機或者意外中斷等故障，能盡快恢復數據庫的可用性，盡可能的減少停機時間，保證業務不會因為數據庫的故障而中斷。
-
用作備份、只讀副本等功能的非主節點的數據應該和主節點的數據實時或者最終保持一致。
-
當業務發生數據庫切換時，切換前後的數據庫內容應當一致，不會因為數據缺失或者數據不一致而影響業務。
關於對高可用的分級我們暫不做詳細的討論，這裏只討論常用高可用方案的優缺點以及選型。
二、高可用方案
1、主從或主主半同步復制
使用雙節點數據庫，搭建單向或者雙向的半同步復制。在5.7以後的版本中，由於lossless replication、logical多線程復制等一些列新特性的引入，使得MySQL原生半同步復制更加可靠。
常見架構如下：
通常會和Proxy、Keepalived等第三方軟件同時使用，即可以用來監控數據庫的健康，又可以執行一系列管理命令。如果主庫發生故障，切換到備庫後仍然可以繼續使用數據庫。
優點：
-
架構比較簡單，使用原生半同步復制作為數據同步的依據
-
雙節點，沒有主機宕機後的選主問題，直接切換即可
-
雙節點，需求資源少，部署簡單
缺點：
-
完全依賴於半同步復制，如果半同步復制退化為異步復制，數據一致性無法得到保證
-
需要額外考慮HAProxy、Keepalived的高可用機制
2、半同步復制優化
半同步復制機制是可靠的。如果半同步復制一直是生效的，那麽可以認為數據是一致的。但是由於網絡波動等一些客觀原因，導致半同步復制發生超時而切換為異步復制，這時便不能保證數據的一致性。所以盡可能的保證半同步復制，就可以提高數據的一致性。
該方案同樣使用雙節點架構，但是在原有半同復制的基礎上做了功能上的優化，使半同步復制的機制變得更加可靠。
可參考的優化方案如下：
雙通道復制
半同步復制由於發生超時後，復制斷開，當再次建立起復制時，同時建立兩條通道，其中一條半同步復制通道從當前位置開始復制，保證從機知道當前主機執行的進度。另外一條異步復制通道開始追補從機落後的數據。當異步復制通道追趕到半同步復制的起始位置時，恢復半同步復制。
binlog文件服務器
搭建兩條半同步復制通道，其中連接文件服務器的半同步通道正常情況下不啟用，當主從的半同步復制發生網絡問題退化後，啟動與文件服務器的半同步復制通道。當主從半同步復制恢復後，關閉與文件服務器的半同步復制通道。
優點：
-
雙節點，需求資源少，部署簡單
-
架構簡單，沒有選主的問題，直接切換即可
-
相比於原生復制，優化後的半同步復制更能保證數據的一致性
缺點：
-
需要修改內核源碼或者使用MySQL通信協議。需要對源碼有一定的了解，並能做一定程度的二次開發
-
依舊依賴於半同步復制，沒有從根本上解決數據一致性問題
3、高可用架構優化
將雙節點數據庫擴展到多節點數據庫，或者多節點數據庫集群。可以根據自己的需要選擇一主兩從、一主多從或者多主多從的集群。
由於半同步復制，存在接收到一個從機的成功應答即認為半同步復制成功的特性，所以多從半同步復制的可靠性要優於單從半同步復制的可靠性。並且多節點同時宕機的幾率也要小於單節點宕機的幾率，所以多節點架構在一定程度上可以認為高可用性是好於雙節點架構。
但由於數據庫數量較多，所以需要數據庫管理軟件來保證數據庫的可維護性。可以選擇MMM、MHA或者各個版本的Proxy等等。常見方案如下：
MHA+多節點集群
MHA Manager會定時探測集群中的master節點，當master出現故障時，它可以自動將最新數據的slave提升為新的master，然後將所有其他的slave重新指向新的master，整個故障轉移過程對應用程序完全透明。
MHA Node運行在每臺MySQL服務器上，主要作用是切換時處理二進制日誌，確保切換盡量少丟數據。
MHA也可以擴展到如下的多節點集群：
原文地址
10款常見MySQL高可用方案選型解讀