今天分享主要包括三方面內(nèi)容：一是常見(jiàn)的MySQL高可用架構(gòu);二是分布式數(shù)據(jù)庫(kù)高可用實(shí)踐;三是基于keepalive的MySQL高可用改造。第一部分會(huì)介紹業(yè)界一些經(jīng)典的MySQL高可用解決方案，第二部分和第三部分分別介紹網(wǎng)易在分布式數(shù)據(jù)庫(kù)和單節(jié)點(diǎn)MySQL上的高可用運(yùn)維實(shí)踐。

一、常見(jiàn)的MySQL高可用架構(gòu)

MySQL高可用主要涉及兩個(gè)方面，一是客戶端如何切換，如何自動(dòng)failover，二是多個(gè)MySQL節(jié)點(diǎn)之間如何做數(shù)據(jù)同步。業(yè)界MySQL高可用的解決方案有很多，總結(jié)起來(lái)有幾類：從客戶端自動(dòng)切換的角度來(lái)看主要有兩類：一類是基于HA同步軟件的MySQL高可用，用戶通過(guò)VIP訪問(wèn)數(shù)據(jù)庫(kù)，然后第三方組件監(jiān)控MySQL的狀態(tài)，控制VIP的漂移。還有一類是基于API調(diào)用的MySQL高可用，把MySQL主從狀態(tài)維護(hù)在客戶端，應(yīng)用程序可以通過(guò)API調(diào)用控制主從切換，進(jìn)行數(shù)據(jù)同步。

MySQL多節(jié)點(diǎn)的數(shù)據(jù)同步方案也有多種，最常用的是基于binlog的數(shù)據(jù)同步，其次還有基于共享存儲(chǔ)的數(shù)據(jù)同步，以及第三方自己實(shí)現(xiàn)的數(shù)據(jù)同步協(xié)議(如Galera)。

1、基于HA同步軟件實(shí)現(xiàn)的高可用方案

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

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

結(jié)構(gòu)簡(jiǎn)單、容易管理;

不支持多寫(xiě)、standby屬于備機(jī);

不保證數(shù)據(jù)一致性;

入侵性小，對(duì)用戶透明。

2、MHA(Master High Availabitliy)

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

我們先來(lái)看下MHA的架構(gòu)圖： 

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

保存故障的master節(jié)點(diǎn)的binlog日志;

Manager查找最新更新的slave節(jié)點(diǎn);

應(yīng)用差異的relay log日志到其他的slave;

在slave節(jié)點(diǎn)上應(yīng)用從master保存的binlog日志;

提升一個(gè)slave為新的master;

使其他的slave連接新的master進(jìn)行復(fù)制。

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

除了MHA以外，還有一個(gè)老牌的MySQL自動(dòng)切換套件MMM。 

與MHA相比，MMM是基于主主復(fù)制的故障切換。也就是不支持從多個(gè)slave中選擇最新的一個(gè)，而是只能切換到特定的主主復(fù)制從節(jié)點(diǎn)。

4、基于API調(diào)用的MySQL高可用

剛才介紹的兩種MySQL高可用解決方案，主要都是基于VIP切換的，優(yōu)點(diǎn)是對(duì)應(yīng)用程序沒(méi)有入侵，但是缺點(diǎn)是不夠靈活，而且系統(tǒng)的可靠性取決于HA軟件本身的可靠性。如VIP通知產(chǎn)生問(wèn)題，或者keepalive進(jìn)程自己掛了，都可能導(dǎo)致切換出現(xiàn)問(wèn)題。除了這種解決方案，還有一種是在客戶端實(shí)現(xiàn)的MySQL高可用 – 基于API調(diào)用的MySQL高可用。也就是JDBC或者其他數(shù)據(jù)庫(kù)驅(qū)動(dòng)可以自主選擇MySQL節(jié)點(diǎn)。這種實(shí)現(xiàn)方案可能使用的不是特別廣泛，但是也有它自身的應(yīng)用場(chǎng)景，它有如下特點(diǎn)：

架構(gòu)較重，運(yùn)維相對(duì)復(fù)雜

使用靈活，有一定開(kāi)發(fā)成本

支持?jǐn)?shù)據(jù)分片、分庫(kù)分表、讀寫(xiě)分離等高級(jí)特性 

HA-JDBC 就是一種典型的基于API調(diào)用的MySQL高可用方案，它可以在應(yīng)用程序中配置多個(gè)MySQL地址，由HA-JDBC實(shí)現(xiàn)選主/屏蔽故障節(jié)點(diǎn)以及多個(gè)應(yīng)用程序之間的連接狀態(tài)通知。HA-JDBC可以實(shí)現(xiàn)如下功能：

基本的failover

讀寫(xiě)分離

節(jié)點(diǎn)狀態(tài)通知

負(fù)載均衡

數(shù)據(jù)同步(先寫(xiě)主，然后同時(shí)寫(xiě)多個(gè)從節(jié)點(diǎn)，如果主寫(xiě)失敗，則重新選主，如果從寫(xiě)失敗，屏蔽從) 弱一致性。

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

5、Galera MySQL的高可用及特點(diǎn)

Galera架構(gòu)如圖所示： 

客戶端通過(guò)Galera Load Balancer訪問(wèn)數(shù)據(jù)庫(kù)，提交的每個(gè)事務(wù)都會(huì)通過(guò)wsrep API 在所有服務(wù)器中執(zhí)行，要不所有服務(wù)器都執(zhí)行成功，要不就所有都回滾，保證所有服務(wù)的數(shù)據(jù)一致性，而且所有服務(wù)器同步實(shí)時(shí)更新。

wsrep API是一系列應(yīng)用回調(diào)和復(fù)制調(diào)用庫(kù)，來(lái)實(shí)現(xiàn)事務(wù)數(shù)據(jù)庫(kù)同步寫(xiě)集(writeset)復(fù)制以及應(yīng)用。其主要思想是在不出現(xiàn)沖突的背景下事務(wù)正常執(zhí)行并持續(xù)到commit為止;當(dāng)客戶端發(fā)起commit命令時(shí)(此時(shí)仍然沒(méi)有發(fā)生真正的commit)，所有本事務(wù)內(nèi)對(duì)數(shù)據(jù)庫(kù)的改動(dòng)與改動(dòng)數(shù)據(jù)行的主鍵都會(huì)被放入一個(gè)寫(xiě)入集(writeset)中，該寫(xiě)入集隨后會(huì)被復(fù)制到其他節(jié)點(diǎn)執(zhí)行，在每個(gè)節(jié)點(diǎn)上使用主鍵進(jìn)行沖突檢測(cè)判斷該寫(xiě)入集是否可以被應(yīng)用，如果出現(xiàn)主鍵沖突，則其中一個(gè)事務(wù)會(huì)被回滾。

缺點(diǎn)及限制：由于同一個(gè)事務(wù)需要在集群的多臺(tái)機(jī)器上執(zhí)行，因此網(wǎng)絡(luò)傳輸及并發(fā)執(zhí)行會(huì)導(dǎo)致性能上有一定的消耗。所有機(jī)器上都存儲(chǔ)著相同的數(shù)據(jù)，全冗余。若一臺(tái)機(jī)器既作為主服務(wù)器，又作為備份服務(wù)器，出現(xiàn)樂(lè)觀鎖導(dǎo)致rollback的概率會(huì)增大，編寫(xiě)程序時(shí)要小心。不支持的SQL：LOCK / UNLOCK TABLES / GET_LOCK(), RELEASE_LOCK()…不支持XA Transaction。目前基于Galera Cluster的實(shí)現(xiàn)方案有三種：Galera Cluster for MySQL、Percona XtraDB Cluster、MariaDB Galera Cluster。

6、MySQL Group Replication

MySQL Group Replication是16年 MySQL 5.7官方推出的多節(jié)點(diǎn)數(shù)據(jù)同步解決方案，它也支持多節(jié)點(diǎn)寫(xiě)和強(qiáng)一致性。在架構(gòu)上它與Galera相似，但是多節(jié)點(diǎn)事務(wù)一致性提交是基于paxos來(lái)實(shí)現(xiàn)的，性能更高?？梢灶A(yù)見(jiàn)MySQL Group Replication，這類基于強(qiáng)一致性協(xié)議的MySQL數(shù)據(jù)同步方案，是MySQL高可用的下一個(gè)研究熱點(diǎn)，目前騰訊、阿里均有類似的方案推出。

MySQL Group Replication中的Replication-group就是一組節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都可以獨(dú)立執(zhí)行事務(wù)，讀寫(xiě)事務(wù)會(huì)在group內(nèi)的其它節(jié)點(diǎn)進(jìn)行協(xié)調(diào)之后再commit。因此，當(dāng)一個(gè)事務(wù)準(zhǔn)備提交時(shí)，會(huì)自動(dòng)在group內(nèi)進(jìn)行原子性的廣播，告知其他節(jié)點(diǎn)變更了什么內(nèi)容/執(zhí)行了什么事務(wù)?；赑axos協(xié)議使得事務(wù)在每一個(gè)節(jié)點(diǎn)上都保持著同樣順序執(zhí)行，這意味著每一個(gè)節(jié)點(diǎn)都以同樣的順序，接收到了同樣的事務(wù)日志，所以每一個(gè)節(jié)點(diǎn)以同樣的順序重演了這些事務(wù)日志，最終整個(gè)group保持了完全一致的狀態(tài)。

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

二、MySQL高可用在網(wǎng)易的實(shí)踐

1、分布式數(shù)據(jù)庫(kù)高可用實(shí)踐

首先是分布式數(shù)據(jù)庫(kù)方面的。由于OLTP的業(yè)務(wù)特性和業(yè)務(wù)量大的特點(diǎn)，分布式數(shù)據(jù)庫(kù)在網(wǎng)易有廣泛的應(yīng)用，下面我們簡(jiǎn)單介紹下網(wǎng)易的分布式數(shù)據(jù)庫(kù)架構(gòu)以及重點(diǎn)介紹下其高可用解決方案。 

DDB的組織架構(gòu)如上圖所示，DBN(MySQL)負(fù)責(zé)實(shí)際的數(shù)據(jù)存儲(chǔ)與讀寫(xiě)提供。管理服務(wù)器負(fù)責(zé)數(shù)據(jù)庫(kù)表、用戶權(quán)限、數(shù)據(jù)分布路由的維護(hù)以及DBN狀態(tài)的監(jiān)控與管理。除此之外DDB最核心的模塊是被稱之為DBI的數(shù)據(jù)庫(kù)驅(qū)動(dòng)，它是一個(gè)類jdbc驅(qū)動(dòng)，一方面可以與管理服務(wù)器交互，獲取分布式數(shù)據(jù)庫(kù)的表結(jié)構(gòu)與分布路由;另一方面可以解析用戶發(fā)過(guò)來(lái)的SQL語(yǔ)句，轉(zhuǎn)換成適用于分布式場(chǎng)景的sql直接發(fā)送給DBN節(jié)點(diǎn)，并且將DBN返回的結(jié)果進(jìn)行聚合或者排序并最終返回給應(yīng)用程序。正是由于DBN這一系列的改寫(xiě)與聚合動(dòng)作，才能使得應(yīng)用程序可以像訪問(wèn)一個(gè)簡(jiǎn)單的關(guān)系型數(shù)據(jù)庫(kù)那樣去訪問(wèn)DDB這樣一個(gè)分布式數(shù)據(jù)庫(kù)。

管理服務(wù)器的高可用主要是基于分離持久化信息到sysdb中實(shí)現(xiàn)的，也就是管理服務(wù)器本身是一個(gè)無(wú)狀態(tài)的服務(wù)，可以部署多個(gè)，短暫的故障也不會(huì)影響DBI到DBN節(jié)點(diǎn)的正常數(shù)據(jù)讀取。而sysdb本身是個(gè)MySQL節(jié)點(diǎn)，它的高可用可以用經(jīng)典的MySQL高可用方案解決。

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

目前網(wǎng)易杭州這邊的項(xiàng)目，絕大多數(shù)的分布式數(shù)據(jù)庫(kù)都是使用的DDB，因此有比較多的線上實(shí)踐，事實(shí)也證明DDB這套高可用架構(gòu)是穩(wěn)定可靠的。目前像網(wǎng)易云的項(xiàng)目，比如視頻云、云信后端依賴的數(shù)據(jù)庫(kù)都是DDB，可以做到數(shù)據(jù)庫(kù)相關(guān)模塊故障異常在30s內(nèi)自動(dòng)恢復(fù)。在減少人工運(yùn)維成本的前提下，提高系統(tǒng)整體可靠性。

除了分布式數(shù)據(jù)庫(kù)，網(wǎng)易也有少量的單節(jié)點(diǎn)MySQL。出于成本和易用性的考慮，我們沒(méi)有選擇MHA方案，而是配合keepalive使用自定義的腳步進(jìn)行故障自切換與盡可能的保障可靠性。首先keepalive本身是一個(gè)多進(jìn)程的程序，可靠性和成熟度很高，不止可以做無(wú)狀態(tài)的nginx的高可用代理，還能通過(guò)配合第三方的腳本來(lái)做類似MySQL這種有狀態(tài)服務(wù)的高可用。

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

網(wǎng)易的這套keepalive的MySQL高可用方案采用的也是經(jīng)典的MySQL主主復(fù)制的架構(gòu)，然后配合自研的切換腳本進(jìn)行自定義故障判定以及升主的一致性檢查功能。一次完整的故障切換包含如下幾個(gè)步驟：首先利用Master上的keepalive定時(shí)調(diào)用故障檢查check腳本，發(fā)現(xiàn)異常后進(jìn)行3次重試，重試后MySQL依然無(wú)法正常服務(wù)則觸發(fā)切換。切換不是采用keepalive傳統(tǒng)的降低權(quán)值的方式進(jìn)行的，而是直接stop keepalive來(lái)觸發(fā)slave搶占VIP，升級(jí)為主。升級(jí)為主后slave keepalive會(huì)調(diào)用升主檢查腳本，判定relay log應(yīng)用完成后才放開(kāi)寫(xiě)，關(guān)閉read only正式提供服務(wù)。

這套keepalive高可用解決方案有如下幾個(gè)特點(diǎn)：

具備一致性檢驗(yàn)功能(檢查relay log是否應(yīng)用完)，配合杭研改進(jìn)的semisync 功能，可以保障數(shù)據(jù)的強(qiáng)一致;

具備防網(wǎng)絡(luò)抖動(dòng)功能，不會(huì)再網(wǎng)絡(luò)不穩(wěn)定的情況下頻繁切換;

原主恢復(fù)后不自動(dòng)升級(jí)為master功能(MySQL復(fù)制延遲);

自定義故障判定規(guī)則，貼近業(yè)務(wù)的高可用;

簡(jiǎn)單易用，方便管理，可以人工介入。

• Keepalived 使用注意事項(xiàng)

現(xiàn)象：

keepalived主從切換后，網(wǎng)關(guān)/交換機(jī)上的arp表沒(méi)有立刻更新VIP對(duì)應(yīng)備用 LVS 的mac，或者arp包被交換機(jī)drop掉，導(dǎo)致備機(jī)無(wú)法被訪問(wèn)。

解決：

arping -I eth1 -c 5 -s VIP GATEWAY

garp_master_refresh 選項(xiàng) (Release 1.2.10)

• Keepalived 不搶占的實(shí)現(xiàn)

Keepalived自帶nopreempt參數(shù)實(shí)現(xiàn)不搶占功能，但當(dāng)新主服務(wù)再掛掉后由于原主帶nopreempt參數(shù)，即使原主優(yōu)先級(jí)高仍無(wú)法完成切換。故現(xiàn)在通過(guò)自定義腳本實(shí)現(xiàn)類似功能(sudo /etc/init.d/keepalived stop)，備機(jī)節(jié)點(diǎn)腳本只有當(dāng)自身 MySQL可用且主機(jī)MySQL不可用時(shí)才觸發(fā)切換。

Keepalive這套方案在網(wǎng)易內(nèi)部主要用在一些負(fù)載比較小，但是對(duì)穩(wěn)定性和可靠性要求比較高的數(shù)據(jù)庫(kù)，比如openresty等云計(jì)算服務(wù)的元數(shù)據(jù)庫(kù)，易信朋友圈數(shù)據(jù)庫(kù)，也已經(jīng)在線上穩(wěn)定運(yùn)行了3，4年的時(shí)間，可以做到秒級(jí)別的切換。