本文基于360私有云-HULK云平臺(tái)技術(shù)積累，在過(guò)去幾年中我們從百十臺(tái)服務(wù)器，幾個(gè)機(jī)房，發(fā)展到數(shù)萬(wàn)臺(tái)服務(wù)器，幾十個(gè)機(jī)房。今天以最基本、最通用的LNMP架構(gòu)闡述前端WEB服務(wù)和后端數(shù)據(jù)庫(kù)服務(wù)，這“一前一后”在異地多活、集群管理等方面的實(shí)踐經(jīng)驗(yàn)，前端WEB服務(wù)經(jīng)驗(yàn)請(qǐng)翻閱前一篇http://os.51cto.com/art/201506/479450.htm。

今天著重介紹一下后端數(shù)據(jù)庫(kù)MySQL的相關(guān)運(yùn)維經(jīng)驗(yàn)，在前不久WOT移動(dòng)開(kāi)發(fā)者大會(huì)上我也提到，故障總會(huì)發(fā)生，只是時(shí)間問(wèn)題，單一的故障很難造成毀滅性的打擊，多種問(wèn)題組合起來(lái)才會(huì)讓我們束手無(wú)策，做好監(jiān)控、事故預(yù)案、應(yīng)急演練才能減少故障的發(fā)生率。

后端數(shù)據(jù)庫(kù)服務(wù)高可用

為了解決單機(jī)故障、單機(jī)房故障，我們的DBA經(jīng)過(guò)不斷的積累更迭，確立了適合360的數(shù)據(jù)庫(kù)架構(gòu)： 

下面我們剖析一下，這個(gè)架構(gòu)是如何解決我們現(xiàn)實(shí)的問(wèn)題。

1、 機(jī)器故障：

機(jī)器故障就跟天要下雨一樣，我們無(wú)法控制，但我們必須做的就是當(dāng)機(jī)器故障后我們能很快的進(jìn)行故障轉(zhuǎn)移，如下為機(jī)器故障的幾種場(chǎng)景：

1） 從庫(kù)故障：這種情況特別好處理，atlas會(huì)探測(cè)從庫(kù)是否異常，如果異常，會(huì)進(jìn)行標(biāo)記下線，這樣，從庫(kù)故障就不影響正常業(yè)務(wù)了。在從庫(kù)下線這里有一個(gè)技術(shù)點(diǎn)，當(dāng)從庫(kù)延時(shí)，我們?cè)趺崔k呢？這就是圖中監(jiān)控所做的事情了，當(dāng)監(jiān)控發(fā)現(xiàn)從庫(kù)延時(shí)超過(guò)10s，它會(huì)給atlas發(fā)送SET OFFLINE $backend_id 指令，強(qiáng)制從庫(kù)下線，這樣確保業(yè)務(wù)不讀取到延時(shí)太大的從庫(kù)了。

2） 主庫(kù)故障：該情況應(yīng)該屬于比較復(fù)雜情況 ，業(yè)內(nèi)也有很多技術(shù)方案，而這里，我們選用的是mysql5.6 Gtid+mysqlfailover+Atlas，mysqlfailover是一個(gè)監(jiān)控daemon，它實(shí)時(shí)監(jiān)控著mysql集群，尤其是mysql主庫(kù)的存活狀態(tài)，在探測(cè)中，一旦發(fā)現(xiàn)主庫(kù)異常，它會(huì)利用mysql5.6 gtid快速搭建主從關(guān)系的便利性，快速進(jìn)行其中的一個(gè)從庫(kù)到主庫(kù)升級(jí)，升級(jí)過(guò)程中包括幾個(gè)技術(shù)點(diǎn)：

• ⑴ 選擇ping值最少，延時(shí)不超過(guò)60s的從庫(kù)作為主庫(kù);
• ⑵ 新主庫(kù)串行的依次從其它從庫(kù)上同步數(shù)據(jù);
• ⑶ 當(dāng)同步完畢后，新主庫(kù)的數(shù)據(jù)將是***的，然后mysqlfailover會(huì)把其他從庫(kù)與新主庫(kù)建立同步關(guān)系,確保整個(gè)集群不存在數(shù)據(jù)不一致以及數(shù)據(jù)丟失的情況。

至此，mysql主從結(jié)構(gòu)調(diào)整完畢，mysqlfailover會(huì)通過(guò)REMOVE BACKEND 老主庫(kù)以及ADD MASTER新主庫(kù)，更換Atlas配置，到此，主庫(kù)故障自動(dòng)化完成，保證業(yè)務(wù)正常運(yùn)行；

3） Atlas故障：該情況比較簡(jiǎn)單，如果出現(xiàn)一臺(tái)atlas故障，lvs 會(huì)自動(dòng)下線失效的atlas，保證業(yè)務(wù)正常運(yùn)行；

2、 某機(jī)房故障：

1） 網(wǎng)絡(luò)故障：

設(shè)計(jì)再牛逼，我們也堅(jiān)信只需要一鏟子，就能引發(fā)較大面積的網(wǎng)絡(luò)故障，對(duì)于這樣的情況，我們?cè)撛趺崔k呢？我把它分為如下幾類(lèi)：

⑴ 機(jī)房出口網(wǎng)絡(luò)故障：

B機(jī)房故障：如果B機(jī)房出口網(wǎng)絡(luò)故障，由于數(shù)據(jù)庫(kù)是純內(nèi)網(wǎng)環(huán)境，所以，數(shù)據(jù)庫(kù)、atlas運(yùn)行狀態(tài)一切正常，故數(shù)據(jù)庫(kù)不需要做任何調(diào)整，只需要通過(guò)前端切換預(yù)案，摘除B機(jī)房的前端業(yè)務(wù)流量即可，把流量壓入A機(jī)房，保證業(yè)務(wù)正常運(yùn)行；

A機(jī)房故障：同上，只需要前端調(diào)整流量入口即可；

⑵ 機(jī)房?jī)?nèi)部網(wǎng)絡(luò)故障

B機(jī)房故障：如果B機(jī)房?jī)?nèi)部網(wǎng)絡(luò)出現(xiàn)異常，這個(gè)時(shí)候，我們通過(guò)WEB集群預(yù)案摘除B機(jī)房的業(yè)務(wù)流量即可，把流量壓入A機(jī)房，保證業(yè)務(wù)正常運(yùn)行；

A機(jī)房故障：除了通過(guò)WEB集群預(yù)案摘除A機(jī)房流量，把流量全部壓入B機(jī)房外，我們還需要做一些其他操作，從上面圖中能看出，這個(gè)時(shí)候其實(shí)比較杯具，因?yàn)槲覀兾ㄒ坏囊粋€(gè)主庫(kù)與failover都出現(xiàn)異常了，已經(jīng)沒(méi)有辦法做到自動(dòng)切換了，所以，我們需要通過(guò)Hulk的故障轉(zhuǎn)移模塊，辦自動(dòng)化的進(jìn)行主庫(kù)切換到B機(jī)房，確保業(yè)務(wù)的正常運(yùn)行;

⑶ 機(jī)房之間光纖異常：

如果光纖中斷，B機(jī)房的從庫(kù)出現(xiàn)延時(shí)，這種情況，為了讓處理流程更簡(jiǎn)單，我們依然采用WEB集群切斷B機(jī)房流量，把流量放入放入A機(jī)房，確保業(yè)務(wù)的正常運(yùn)行;

2） 內(nèi)部長(zhǎng)時(shí)間故障，如：機(jī)房斷電、地震、地災(zāi)等，這種情況，我們可以按照機(jī)房網(wǎng)絡(luò)出口故障場(chǎng)景處理。

再好的架構(gòu)也不可能萬(wàn)無(wú)一失，完善的備份體系是我們的救命稻草，接下來(lái)介紹一下我們的自動(dòng)化備份恢復(fù)系統(tǒng)

#p#

自動(dòng)化備份恢復(fù)系統(tǒng)

備份作為“救命稻草”，既要做到需要時(shí)有備份，也能做到快速恢復(fù)，為了實(shí)現(xiàn)數(shù)據(jù)庫(kù)自動(dòng)化備份和快速恢復(fù)，我們的DBA團(tuán)隊(duì)經(jīng)過(guò)不斷的嘗試自主開(kāi)發(fā)了一套自動(dòng)化備份恢復(fù)系統(tǒng)（主要用于MySQL同時(shí)兼容MongoDB以及Redis）。

MySQL自動(dòng)化備份總體架構(gòu)如下：

下面簡(jiǎn)單介紹一下自動(dòng)化備份的主要流程：

1）、自動(dòng)存儲(chǔ)選擇

每天的定時(shí)任務(wù)采集所有存儲(chǔ)的的容量信息，根據(jù)一定的策略更新數(shù)據(jù)庫(kù)中的存儲(chǔ)相關(guān)信息，保證線上所選存儲(chǔ)都可用。備份在存儲(chǔ)選擇時(shí)所有機(jī)房的存儲(chǔ)都是交叉選擇。即便某個(gè)機(jī)房的所有存儲(chǔ)被損毀，依然可以從其他機(jī)房的存儲(chǔ)拿到可用的備份進(jìn)行恢復(fù)。

2）、備份策略更新

每天備份策略定時(shí)任務(wù)自動(dòng)更新實(shí)例備份對(duì)應(yīng)信息（如從庫(kù)ip、備份保留策略、所選存儲(chǔ)機(jī)器等）保證備份策略里的信息***并且可用。

3）、正式執(zhí)行備份

備份任務(wù)根據(jù)備份策略信息、選擇備份時(shí)間點(diǎn)、存儲(chǔ)機(jī)器等，所有條件滿(mǎn)足后正式開(kāi)始備份。備份任務(wù)會(huì)自動(dòng)對(duì)數(shù)據(jù)庫(kù)大小進(jìn)行判斷然后選擇本地備份還是遠(yuǎn)程備份。無(wú)論哪種備份模式所有備份文件都會(huì)經(jīng)過(guò)壓縮加密后再傳輸。

4）、備份失敗檢查

備份失敗檢查任務(wù)會(huì)定期檢查每天的備份信息狀態(tài)并入庫(kù)，備份失敗相關(guān)信息會(huì)實(shí)時(shí)在360 hulk云平臺(tái)中展示并由DBA進(jìn)行及時(shí)處理。

5）、過(guò)期備份清理

數(shù)據(jù)總是一直增長(zhǎng)的，存儲(chǔ)空間總是有限的，因此我們會(huì)根據(jù)備份策略里的清理策略定期清理過(guò)期的備份以保證有足夠的空間可用。

你永遠(yuǎn)無(wú)法預(yù)測(cè)開(kāi)發(fā)哪天突然誤刪數(shù)據(jù)，你也無(wú)法想象某天苦x的DBA手一得瑟drop了某個(gè)庫(kù)。所以，完善的備份機(jī)制最終是為了快速恢復(fù)。

如下是我們MySQL自動(dòng)化恢復(fù)的流程圖：  

從圖中我們可以看到，總體上恢復(fù)可以基于單表/多表以及整庫(kù)等不同的維度進(jìn)行恢復(fù)，極端情況下甚至還可以利用binlog或relaylog進(jìn)行數(shù)據(jù)恢復(fù)。無(wú)論何種恢復(fù)方式人工干預(yù)都較少，這也一定程度上降低了人為操作的不確定性因素。至于恢復(fù)的時(shí)間基本上取決于數(shù)據(jù)庫(kù)或單表的大小以及恢復(fù)的時(shí)間點(diǎn)與備份日期的間隔長(zhǎng)短。

在實(shí)際的生產(chǎn)環(huán)境中，我們的備份恢復(fù)系統(tǒng)很大程度上已經(jīng)實(shí)現(xiàn)了自動(dòng)化，不過(guò)隨著業(yè)務(wù)和數(shù)據(jù)的不斷增長(zhǎng)以及行業(yè)對(duì)數(shù)據(jù)的重視程度越來(lái)越高，在快速自動(dòng)化備份和恢復(fù)這個(gè)方向上我們還有很長(zhǎng)的路要走還有更多的事情可做。希望我們的經(jīng)驗(yàn)可以供大家所用。

關(guān)于作者：

孔德亮（微信號(hào)：randykong），奇虎360云事業(yè)部總監(jiān)，跨領(lǐng)域技術(shù)專(zhuān)家，現(xiàn)任360私有云、公有云項(xiàng)目負(fù)責(zé)人。

孔德亮2009年加入奇虎360，隨著360業(yè)務(wù)快速發(fā)展，他也開(kāi)始了內(nèi)部創(chuàng)業(yè)之旅，先后負(fù)責(zé)應(yīng)用運(yùn)維、DBA、基礎(chǔ)架構(gòu)等工作，通過(guò)逐步積累形成了私有云平臺(tái)。眾所周知，運(yùn)維的工作“臟、苦、累”，一旦出現(xiàn)問(wèn)題，運(yùn)維人員似乎永遠(yuǎn)是那個(gè)背黑鍋的人，所以，他希望能夠?qū)⒓夹g(shù)產(chǎn)品化，使業(yè)務(wù)團(tuán)隊(duì)在借助云平臺(tái)的力量，縮短研發(fā)周期、降低運(yùn)維成本，同時(shí)能讓IT技術(shù)人員在靈活的操作體驗(yàn)中感受愉悅。

孔德亮：大規(guī)模集群運(yùn)維經(jīng)驗(yàn)（一）