MySQL數據庫的幾種常見(jiàn)高可用方案介紹

本篇內容主要講解“數據庫的幾種常見(jiàn)高可用方案介紹”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強。下面就讓小編來(lái)帶大家學(xué)習“MySQL數據庫的幾種常見(jiàn)高可用方案介紹”吧!

一、概述

我們在考慮MySQL數據庫的高可用的架構時(shí)，主要要考慮如下幾方面：

• 如果數據庫發(fā)生了宕機或者意外中斷等故障，能盡快恢復數據庫的可用性，盡可能的減少停機時(shí)間，保證業(yè)務(wù)不會(huì )因為數據庫的故障而中斷。
  

• 用作備份、只讀副本等功能的非主節點(diǎn)的數據應該和主節點(diǎn)的數據實(shí)時(shí)或者最終保持一致。
  

• 當業(yè)務(wù)發(fā)生數據庫切換時(shí)，切換前后的數據庫內容應當一致，不會(huì )因為數據缺失或者數據不一致而影響業(yè)務(wù)。
  

關(guān)于對高可用的分級在這里我們不做詳細的討論，這里只討論常用高可用方案的優(yōu)缺點(diǎn)以及高可用方案的選型。

二、高可用方案

1. 主從或主主半同步復制

使用雙節點(diǎn)數據庫，搭建單向或者雙向的半同步復制。在5.7以后的版本中，由于lossless replication、logical多線(xiàn)程復制等一些列新特性的引入，使得MySQL原生半同步復制更加可靠。

常見(jiàn)架構如下：

通常會(huì )和proxy、keepalived等第三方軟件同時(shí)使用，即可以用來(lái)監控數據庫的健康，又可以執行一系列管理命令。如果主庫發(fā)生故障，切換到備庫后仍然可以繼續使用數據庫。

優(yōu)點(diǎn)：

• 架構比較簡(jiǎn)單，使用原生半同步復制作為數據同步的依據;
  

• 雙節點(diǎn)，沒(méi)有主機宕機后的選主問(wèn)題，直接切換即可;
  

• 雙節點(diǎn)，需求資源少，部署簡(jiǎn)單;
  

缺點(diǎn)：

• 完全依賴(lài)于半同步復制，如果半同步復制退化為異步復制，數據一致性無(wú)法得到保證;
  

• 需要額外考慮haproxy、keepalived的高可用機制。
  

2. 半同步復制優(yōu)化

半同步復制機制是可靠的。如果半同步復制一直是生效的，那么便可以認為數據是一致的。但是由于網(wǎng)絡(luò )波動(dòng)等一些客觀(guān)原因，導致半同步復制發(fā)生超時(shí)而切換為異步復制，那么這時(shí)便不能保證數據的一致性。所以盡可能的保證半同步復制，便可提高數據的一致性。

該方案同樣使用雙節點(diǎn)架構，但是在原有半同復制的基礎上做了功能上的優(yōu)化，使半同步復制的機制變得更加可靠。

可參考的優(yōu)化方案如下：

(1) 雙通道復制

半同步復制由于發(fā)生超時(shí)后，復制斷開(kāi)，當再次建立起復制時(shí)，同時(shí)建立兩條通道，其中一條半同步復制通道從當前位置開(kāi)始復制，保證從機知道當前主機執行的進(jìn)度。另外一條異步復制通道開(kāi)始追補從機落后的數據。當異步復制通道追趕到半同步復制的起始位置時(shí)，恢復半同步復制。

(2) binlog文件

搭建兩條半同步復制通道，其中連接文件服務(wù)器的半同步通道正常情況下不啟用，當主從的半同步復制發(fā)生網(wǎng)絡(luò )問(wèn)題退化后，啟動(dòng)與文件服務(wù)器的半同步復制通道。當主從半同步復制恢復后，關(guān)閉與文件服務(wù)器的半同步復制通道。

優(yōu)點(diǎn)：

• 雙節點(diǎn)，需求資源少，部署簡(jiǎn)單;
  

• 架構簡(jiǎn)單，沒(méi)有選主的問(wèn)題，直接切換即可;
  

• 相比于原生復制，優(yōu)化后的半同步復制更能保證數據的一致性。
  

缺點(diǎn)：

• 需要修改內核源碼或者使用mysql通信協(xié)議。需要對源碼有一定的了解，并能做一定程度的二次開(kāi)發(fā)。
  

• 依舊依賴(lài)于半同步復制，沒(méi)有從根本上解決數據一致性問(wèn)題。
  

3. 高可用架構優(yōu)化

將雙節點(diǎn)數據庫擴展到多節點(diǎn)數據庫，或者多節點(diǎn)數據庫集群?？梢愿鶕约旱男枰x擇一主兩從、一主多從或者多主多從的集群。

由于半同步復制，存在接收到一個(gè)從機的成功應答即認為半同步復制成功的特性，所以多從半同步復制的可靠性要優(yōu)于單從半同步復制的可靠性。并且多節點(diǎn)同時(shí)宕機的幾率也要小于單節點(diǎn)宕機的幾率，所以多節點(diǎn)架構在一定程度上可以認為高可用性是好于雙節點(diǎn)架構。

但是由于數據庫數量較多，所以需要數據庫管理軟件來(lái)保證數據庫的可維護性?？梢赃x擇MMM、MHA或者各個(gè)版本的proxy等等。

常見(jiàn)方案如下：

(1) MHA+多節點(diǎn)集群

MHA Manager會(huì )定時(shí)探測集群中的master節點(diǎn)，當master出現故障時(shí)，它可以自動(dòng)將最新數據的slave提升為新的master，然后將所有其他的slave重新指向新的master，整個(gè)故障轉移過(guò)程對應用程序完全透明。

MHA Node運行在每臺MySQL服務(wù)器上，主要作用是切換時(shí)處理二進(jìn)制日志，確保切換盡量少丟數據。

MHA也可以擴展到如下的多節點(diǎn)集群：

優(yōu)點(diǎn)：

• 可以進(jìn)行故障的自動(dòng)檢測和轉移;
  

• 可擴展性較好，可以根據需要擴展MySQL的節點(diǎn)數量和結構;
  

• 相比于雙節點(diǎn)的MySQL復制，三節點(diǎn)/多節點(diǎn)的MySQL發(fā)生不可用的概率更低
  

缺點(diǎn)：

• 至少需要三節點(diǎn)，相對于雙節點(diǎn)需要更多的資源;
  

• 邏輯較為復雜，發(fā)生故障后排查問(wèn)題，定位問(wèn)題更加困難;
  

• 數據一致性仍然靠原生半同步復制保證，仍然存在數據不一致的風(fēng)險;
  

• 可能因為網(wǎng)絡(luò )分區發(fā)生腦裂現象;
  

(2) zookeeper+proxy

Zookeeper使用分布式算法保證集群數據的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網(wǎng)絡(luò )分區現象的產(chǎn)生。

優(yōu)點(diǎn)：

• 較好的保證了整個(gè)系統的高可用性，包括proxy、MySQL;
  

• 擴展性較好，可以擴展為大規模集群;
  

缺點(diǎn)：

• 數據一致性仍然依賴(lài)于原生的mysql半同步復制;
  

• 引入zk，整個(gè)系統的邏輯變得更加復雜;
  

4. 共享存儲

共享存儲實(shí)現了數據庫服務(wù)器和存儲設備的解耦，不同數據庫之間的數據同步不再依賴(lài)于MySQL的原生復制功能，而是通過(guò)磁盤(pán)數據同步的手段，來(lái)保證數據的一致性。

(1) SAN共享儲存

SAN的概念是允許存儲設備和處理器(服務(wù)器)之間建立直接的高速網(wǎng)絡(luò )(與LAN相比)連接，通過(guò)這種連接實(shí)現數據的集中式存儲。

常用架構如下：

使用共享存儲時(shí)，MySQL服務(wù)器能夠正常掛載文件系統并操作，如果主庫發(fā)生宕機，備庫可以?huà)燧d相同的文件系統，保證主庫和備庫使用相同的數據。

優(yōu)點(diǎn)：

• 兩節點(diǎn)即可，部署簡(jiǎn)單，切換邏輯簡(jiǎn)單;
  

• 很好的保證數據的強一致性;
  

• 不會(huì )因為MySQL的邏輯錯誤發(fā)生數據不一致的情況;
  

缺點(diǎn)：

• 需要考慮共享存儲的高可用;
  

• 價(jià)格昂貴;
  

(2) DRBD磁盤(pán)復制

DRBD是一種基于軟件、基于網(wǎng)絡(luò )的塊復制存儲解決方案，主要用于對服務(wù)器之間的磁盤(pán)、分區、邏輯卷等進(jìn)行數據鏡像，當用戶(hù)將數據寫(xiě)入本地磁盤(pán)時(shí)，還會(huì )將數據發(fā)送到網(wǎng)絡(luò )中另一臺主機的磁盤(pán)上，這樣的本地主機(主節點(diǎn))與遠程主機(備節點(diǎn))的數據就可以保證實(shí)時(shí)同步。

常用架構如下：

當本地主機出現問(wèn)題，遠程主機上還保留著(zhù)一份相同的數據，可以繼續使用，保證了數據的安全。

DRBD是linux內核模塊實(shí)現的快級別的同步復制技術(shù)，可以與SAN達到相同的共享存儲效果。

優(yōu)點(diǎn)：

• 兩節點(diǎn)即可，部署簡(jiǎn)單，切換邏輯簡(jiǎn)單;
  

• 相比于SAN儲存網(wǎng)絡(luò )，價(jià)格低廉;
  

• 保證數據的強一致性;
  

缺點(diǎn)：

• 對io性能影響較大;
  

• 從庫不提供讀操作;
  

5. 分布式協(xié)議

分布式協(xié)議可以很好解決數據一致性問(wèn)題。比較常見(jiàn)的方案如下：

(1) MySQL cluster

MySQL cluster是官方集群的部署方案，通過(guò)使用NDB存儲引擎實(shí)時(shí)備份冗余數據，實(shí)現數據庫的高可用性和數據一致性。

常見(jiàn)架構如下：

優(yōu)點(diǎn)：

• 全部使用官方組件，不依賴(lài)于第三方軟件;
  

• 可以實(shí)現數據的強一致性;
  

缺點(diǎn)：

• 國內使用的較少;
  

• 配置較復雜，需要使用NDB儲存引擎，與MySQL常規引擎存在一定差異;
  

• 至少三節點(diǎn);
  

(2) Galera

基于Galera的MySQL高可用集群， 是多主數據同步的MySQL集群解決方案，使用簡(jiǎn)單，沒(méi)有單點(diǎn)故障，可用性高。

常見(jiàn)架構如下：

優(yōu)點(diǎn)：

• 多主寫(xiě)入，無(wú)延遲復制，能保證數據強一致性;
  

• 有成熟的社區，有互聯(lián)網(wǎng)公司在大規模的使用;
  

• 自動(dòng)故障轉移，自動(dòng)添加、剔除節點(diǎn);
  

缺點(diǎn)：

• 需要為原生MySQL節點(diǎn)打wsrep補丁
  

• 只支持innodb儲存引擎
  

• 至少三節點(diǎn);
  

(3) POAXS

Paxos 算法解決的問(wèn)題是一個(gè)分布式系統如何就某個(gè)值(決議)達成一致。這個(gè)算法被認為是同類(lèi)算法中最有效的。Paxos與MySQL相結合可以實(shí)現在分布式的MySQL數據的強一致性。

常見(jiàn)架構如下：

優(yōu)點(diǎn)：

• 多主寫(xiě)入，無(wú)延遲復制，能保證數據強一致性;
  

• 有成熟理論基礎;
  

• 自動(dòng)故障轉移，自動(dòng)添加、剔除節點(diǎn);
  

缺點(diǎn)：

• 只支持innodb儲存引擎
  

• 至少三節點(diǎn);