今天分享主要包括三方面內容：一是常見的MySQL高可用架構;二是分布式數據庫高可用實踐;三是基于keepalive的MySQL高可用改造。第一部分會介紹業界一些經典的MySQL高可用解決方案，第二部分和第三部分分別介紹網易在分布式數據庫和單節點MySQL上的高可用運維實踐。

一、常見的MySQL高可用架構

MySQL高可用主要涉及兩個方面，一是客戶端如何切換，如何自動failover，二是多個MySQL節點之間如何做數據同步。業界MySQL高可用的解決方案有很多，總結起來有幾類：從客戶端自動切換的角度來看主要有兩類：一類是基于HA同步軟件的MySQL高可用，用戶通過VIP訪問數據庫，然后第三方組件監控MySQL的狀態，控制VIP的漂移。還有一類是基于API調用的MySQL高可用，把MySQL主從狀態維護在客戶端，應用程序可以通過API調用控制主從切換，進行數據同步。

MySQL多節點的數據同步方案也有多種，最常用的是基于binlog的數據同步，其次還有基于共享存儲的數據同步，以及第三方自己實現的數據同步協議(如Galera)。

1、基于HA同步軟件實現的高可用方案

如圖所示，基于HA同步軟件的MySQL高可用主要是通過VIP作為對外的訪問入口，正常情況下VIP綁定在Master上，當Master出現故障后，可以將VIP切換漂移到Slave上。從而實現了一個故障failover的過程。這種基于VIP的高可用方案，最常用的數據同步方式是使用MySQL原生的binlog復制方式，當然，在成本允許的情況下，也可以選擇利用SAN之類的共享存儲解決方案。我們這邊重點介紹的還是binlog復制或者其他軟件層次的數據同步方式。

基于HA同步軟件的高可用方式的主要特點包括：

結構簡單、容易管理;

不支持多寫、standby屬于備機;

不保證數據一致性;

入侵性小，對用戶透明。

2、MHA(Master High Availabitliy)

下面，我們來介紹幾種典型的MySQL HA同步軟件。在業界應用最為廣泛，技術最為成熟的HA同步軟件之一是MHA。MHA全稱是Master High Availability，是一種一主多從的數據庫高可用解決方案。他的特點是在保障高可用自切換的前提下，最大限度的保障主從數據的一致性。

我們先來看下MHA的架構圖： 

一次完整MHA故障切換流程如下：

保存故障的master節點的binlog日志;

Manager查找最新更新的slave節點;

應用差異的relay log日志到其他的slave;

在slave節點上應用從master保存的binlog日志;

提升一個slave為新的master;

使其他的slave連接新的master進行復制。

3、MMM(Master-Master Replication Manager for MySQL)

除了MHA以外，還有一個老牌的MySQL自動切換套件MMM。 

與MHA相比，MMM是基于主主復制的故障切換。也就是不支持從多個slave中選擇最新的一個，而是只能切換到特定的主主復制從節點。

4、基于API調用的MySQL高可用

剛才介紹的兩種MySQL高可用解決方案，主要都是基于VIP切換的，優點是對應用程序沒有入侵，但是缺點是不夠靈活，而且系統的可靠性取決于HA軟件本身的可靠性。如VIP通知產生問題，或者keepalive進程自己掛了，都可能導致切換出現問題。除了這種解決方案，還有一種是在客戶端實現的MySQL高可用 – 基于API調用的MySQL高可用。也就是JDBC或者其他數據庫驅動可以自主選擇MySQL節點。這種實現方案可能使用的不是特別廣泛，但是也有它自身的應用場景，它有如下特點：

架構較重，運維相對復雜

使用靈活，有一定開發成本

支持數據分片、分庫分表、讀寫分離等高級特性 

HA-JDBC 就是一種典型的基于API調用的MySQL高可用方案，它可以在應用程序中配置多個MySQL地址，由HA-JDBC實現選主/屏蔽故障節點以及多個應用程序之間的連接狀態通知。HA-JDBC可以實現如下功能：

基本的failover

讀寫分離

節點狀態通知

負載均衡

數據同步(先寫主，然后同時寫多個從節點，如果主寫失敗，則重新選主，如果從寫失敗，屏蔽從) 弱一致性。

剛才介紹的多是在客戶端角度看到的MySQL高可用切換技術，下面再介紹幾種MySQL數據同步的高可用解決方案，MySQL最經典的數據同步方案就是利用binlog進行數據同步，這種數據同步的優勢是架構簡單、易于管理，對主服務的性能影響相對較小。缺點是不能保障主從完全一致，而且只支持單寫。下面介紹幾種能保證主從完全一致，并且支持多節點寫的方案。

5、Galera MySQL的高可用及特點

Galera架構如圖所示： 

客戶端通過Galera Load Balancer訪問數據庫，提交的每個事務都會通過wsrep API 在所有服務器中執行，要不所有服務器都執行成功，要不就所有都回滾，保證所有服務的數據一致性，而且所有服務器同步實時更新。

wsrep API是一系列應用回調和復制調用庫，來實現事務數據庫同步寫集(writeset)復制以及應用。其主要思想是在不出現沖突的背景下事務正常執行并持續到commit為止;當客戶端發起commit命令時(此時仍然沒有發生真正的commit)，所有本事務內對數據庫的改動與改動數據行的主鍵都會被放入一個寫入集(writeset)中，該寫入集隨后會被復制到其他節點執行，在每個節點上使用主鍵進行沖突檢測判斷該寫入集是否可以被應用，如果出現主鍵沖突，則其中一個事務會被回滾。

缺點及限制：由于同一個事務需要在集群的多臺機器上執行，因此網絡傳輸及并發執行會導致性能上有一定的消耗。所有機器上都存儲著相同的數據，全冗余。若一臺機器既作為主服務器，又作為備份服務器，出現樂觀鎖導致rollback的概率會增大，編寫程序時要小心。不支持的SQL：LOCK / UNLOCK TABLES / GET_LOCK(), RELEASE_LOCK()…不支持XA Transaction。目前基于Galera Cluster的實現方案有三種：Galera Cluster for MySQL、Percona XtraDB Cluster、MariaDB Galera Cluster。

6、MySQL Group Replication

MySQL Group Replication是16年 MySQL 5.7官方推出的多節點數據同步解決方案，它也支持多節點寫和強一致性。在架構上它與Galera相似，但是多節點事務一致性提交是基于paxos來實現的，性能更高?？梢灶A見MySQL Group Replication，這類基于強一致性協議的MySQL數據同步方案，是MySQL高可用的下一個研究熱點，目前騰訊、阿里均有類似的方案推出。

MySQL Group Replication中的Replication-group就是一組節點，每個節點都可以獨立執行事務，讀寫事務會在group內的其它節點進行協調之后再commit。因此，當一個事務準備提交時，會自動在group內進行原子性的廣播，告知其他節點變更了什么內容/執行了什么事務。基于Paxos協議使得事務在每一個節點上都保持著同樣順序執行，這意味著每一個節點都以同樣的順序，接收到了同樣的事務日志，所以每一個節點以同樣的順序重演了這些事務日志，最終整個group保持了完全一致的狀態。

MySQL Group Replication僅支持InnoDB表，并且每張表一定要有一個主鍵，用于做沖突檢測;必須打開GTID特性，二進制日志格式必須設置為ROW。這是使用MGR的一些限制。

二、MySQL高可用在網易的實踐

1、分布式數據庫高可用實踐

首先是分布式數據庫方面的。由于OLTP的業務特性和業務量大的特點，分布式數據庫在網易有廣泛的應用，下面我們簡單介紹下網易的分布式數據庫架構以及重點介紹下其高可用解決方案。 

DDB的組織架構如上圖所示，DBN(MySQL)負責實際的數據存儲與讀寫提供。管理服務器負責數據庫表、用戶權限、數據分布路由的維護以及DBN狀態的監控與管理。除此之外DDB最核心的模塊是被稱之為DBI的數據庫驅動，它是一個類jdbc驅動，一方面可以與管理服務器交互，獲取分布式數據庫的表結構與分布路由;另一方面可以解析用戶發過來的SQL語句，轉換成適用于分布式場景的sql直接發送給DBN節點，并且將DBN返回的結果進行聚合或者排序并最終返回給應用程序。正是由于DBN這一系列的改寫與聚合動作，才能使得應用程序可以像訪問一個簡單的關系型數據庫那樣去訪問DDB這樣一個分布式數據庫。

管理服務器的高可用主要是基于分離持久化信息到sysdb中實現的，也就是管理服務器本身是一個無狀態的服務，可以部署多個，短暫的故障也不會影響DBI到DBN節點的正常數據讀取。而sysdb本身是個MySQL節點，它的高可用可以用經典的MySQL高可用方案解決。

DBN的高可用也可以使用MySQL原生的高可用方式，比如基于VIP的高可用。但是使用分布式數據庫做高可用的優勢就是有一個管理服務器的角色維護數據路由，因此只要可以根據當前的節點的狀態更新數據路由就可以做到一個自動的failover的過程。具體到DDB這個場景，我們引入了一個DDBSwitch高可用切換工具，這個工具可以監控DBN狀態，維護DBN主從關系。當主DBN存在異常時，DDBSwitch工具會檢測到節點異常，并且觸發管理服務器更新DBN列表，管理服務器會通知所有客戶端的DBI更新本地的DBN列表，切換緩存中的路由，從而完成了一次完整的切換。除了最基本的故障切換，DDBSwitch還可以通過逐步放開DBN連接池的方式控制新切入節點的流量，防止新上線的節點由于之前堆積的請求而瞬間被壓垮。

目前網易杭州這邊的項目，絕大多數的分布式數據庫都是使用的DDB，因此有比較多的線上實踐，事實也證明DDB這套高可用架構是穩定可靠的。目前像網易云的項目，比如視頻云、云信后端依賴的數據庫都是DDB，可以做到數據庫相關模塊故障異常在30s內自動恢復。在減少人工運維成本的前提下，提高系統整體可靠性。

除了分布式數據庫，網易也有少量的單節點MySQL。出于成本和易用性的考慮，我們沒有選擇MHA方案，而是配合keepalive使用自定義的腳步進行故障自切換與盡可能的保障可靠性。首先keepalive本身是一個多進程的程序，可靠性和成熟度很高，不止可以做無狀態的nginx的高可用代理，還能通過配合第三方的腳本來做類似MySQL這種有狀態服務的高可用。

2、基于keepalive的MySQL高可用改造

網易的這套keepalive的MySQL高可用方案采用的也是經典的MySQL主主復制的架構，然后配合自研的切換腳本進行自定義故障判定以及升主的一致性檢查功能。一次完整的故障切換包含如下幾個步驟：首先利用Master上的keepalive定時調用故障檢查check腳本，發現異常后進行3次重試，重試后MySQL依然無法正常服務則觸發切換。切換不是采用keepalive傳統的降低權值的方式進行的，而是直接stop keepalive來觸發slave搶占VIP，升級為主。升級為主后slave keepalive會調用升主檢查腳本，判定relay log應用完成后才放開寫，關閉read only正式提供服務。

這套keepalive高可用解決方案有如下幾個特點：

具備一致性檢驗功能(檢查relay log是否應用完)，配合杭研改進的semisync 功能，可以保障數據的強一致;

具備防網絡抖動功能，不會再網絡不穩定的情況下頻繁切換;

原主恢復后不自動升級為master功能(MySQL復制延遲);

自定義故障判定規則，貼近業務的高可用;

簡單易用，方便管理，可以人工介入。

• Keepalived 使用注意事項

現象：

keepalived主從切換后，網關/交換機上的arp表沒有立刻更新VIP對應備用 LVS 的mac，或者arp包被交換機drop掉，導致備機無法被訪問。

解決：

arping -I eth1 -c 5 -s VIP GATEWAY

garp_master_refresh 選項 (Release 1.2.10)

• Keepalived 不搶占的實現

Keepalived自帶nopreempt參數實現不搶占功能，但當新主服務再掛掉后由于原主帶nopreempt參數，即使原主優先級高仍無法完成切換。故現在通過自定義腳本實現類似功能(sudo /etc/init.d/keepalived stop)，備機節點腳本只有當自身 MySQL可用且主機MySQL不可用時才觸發切換。

Keepalive這套方案在網易內部主要用在一些負載比較小，但是對穩定性和可靠性要求比較高的數據庫，比如openresty等云計算服務的元數據庫，易信朋友圈數據庫，也已經在線上穩定運行了3，4年的時間，可以做到秒級別的切換。