10款常見MySQL高可用方案選型解讀

標籤：技術分享   gic   二進位   運行   新特性   keepalive   啟用   adf   接收   

原文地址

作者介紹

王松磊，現任職於UCloud，從事MySQL資料庫核心研發工作。主要負責UCloud雲資料庫udb的核心故障排查工作以及資料庫新特性的研發工作。

 

一、概述

 

我們在考慮MySQL資料庫的高可用架構時，主要考慮如下幾方面：

 

1. 如果資料庫發生了宕機或者意外中斷等故障，能儘快恢複資料庫的可用性，儘可能的減少停機時間，保證業務不會因為資料庫的故障而中斷。

2. 用作備份、唯讀副本等功能的非主節點的資料應該和主節點的資料即時或者最終保持一致。

3. 當業務發生資料庫切換時，切換前後的資料庫內容應當一致，不會因為資料缺失或者資料不一致而影響業務。

 

關於對高可用的分級我們暫不做詳細的討論，這裡只討論常用高可用方案的優缺點以及選型。

 

二、高可用方案

 

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高可用方案選型解讀