本文基于360私有云-HULK云平臺技術積累，在過去幾年中我們從百十臺服務器，幾個機房，發展到數萬臺服務器，幾十個機房。今天以最基本、最通用的LNMP架構闡述前端WEB服務和后端數據庫服務，這“一前一后”在異地多活、集群管理等方面的實踐經驗，前端WEB服務經驗請翻閱前一篇http://os.51cto.com/art/201506/479450.htm。

今天著重介紹一下后端數據庫MySQL的相關運維經驗，在前不久WOT移動開發者大會上我也提到，故障總會發生，只是時間問題，單一的故障很難造成毀滅性的打擊，多種問題組合起來才會讓我們束手無策，做好監控、事故預案、應急演練才能減少故障的發生率。

后端數據庫服務高可用

為了解決單機故障、單機房故障，我們的DBA經過不斷的積累更迭，確立了適合360的數據庫架構： 

下面我們剖析一下，這個架構是如何解決我們現實的問題。

1、 機器故障：

機器故障就跟天要下雨一樣，我們無法控制，但我們必須做的就是當機器故障后我們能很快的進行故障轉移，如下為機器故障的幾種場景：

1） 從庫故障：這種情況特別好處理，atlas會探測從庫是否異常，如果異常，會進行標記下線，這樣，從庫故障就不影響正常業務了。在從庫下線這里有一個技術點，當從庫延時，我們怎么辦呢？這就是圖中監控所做的事情了，當監控發現從庫延時超過10s，它會給atlas發送SET OFFLINE $backend_id 指令，強制從庫下線，這樣確保業務不讀取到延時太大的從庫了。

2） 主庫故障：該情況應該屬于比較復雜情況 ，業內也有很多技術方案，而這里，我們選用的是mysql5.6 Gtid+mysqlfailover+Atlas，mysqlfailover是一個監控daemon，它實時監控著mysql集群，尤其是mysql主庫的存活狀態，在探測中，一旦發現主庫異常，它會利用mysql5.6 gtid快速搭建主從關系的便利性，快速進行其中的一個從庫到主庫升級，升級過程中包括幾個技術點：

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

至此，mysql主從結構調整完畢，mysqlfailover會通過REMOVE BACKEND 老主庫以及ADD MASTER新主庫，更換Atlas配置，到此，主庫故障自動化完成，保證業務正常運行；

3） Atlas故障：該情況比較簡單，如果出現一臺atlas故障，lvs 會自動下線失效的atlas，保證業務正常運行；

2、 某機房故障：

1） 網絡故障：

設計再牛逼，我們也堅信只需要一鏟子，就能引發較大面積的網絡故障，對于這樣的情況，我們該怎么辦呢？我把它分為如下幾類：

⑴ 機房出口網絡故障：

B機房故障：如果B機房出口網絡故障，由于數據庫是純內網環境，所以，數據庫、atlas運行狀態一切正常，故數據庫不需要做任何調整，只需要通過前端切換預案，摘除B機房的前端業務流量即可，把流量壓入A機房，保證業務正常運行；

A機房故障：同上，只需要前端調整流量入口即可；

⑵ 機房內部網絡故障

B機房故障：如果B機房內部網絡出現異常，這個時候，我們通過WEB集群預案摘除B機房的業務流量即可，把流量壓入A機房，保證業務正常運行；

A機房故障：除了通過WEB集群預案摘除A機房流量，把流量全部壓入B機房外，我們還需要做一些其他操作，從上面圖中能看出，這個時候其實比較杯具，因為我們唯一的一個主庫與failover都出現異常了，已經沒有辦法做到自動切換了，所以，我們需要通過Hulk的故障轉移模塊，辦自動化的進行主庫切換到B機房，確保業務的正常運行;

⑶ 機房之間光纖異常：

如果光纖中斷，B機房的從庫出現延時，這種情況，為了讓處理流程更簡單，我們依然采用WEB集群切斷B機房流量，把流量放入放入A機房，確保業務的正常運行;

2） 內部長時間故障，如：機房斷電、地震、地災等，這種情況，我們可以按照機房網絡出口故障場景處理。

再好的架構也不可能萬無一失，完善的備份體系是我們的救命稻草，接下來介紹一下我們的自動化備份恢復系統

#p#

自動化備份恢復系統

備份作為“救命稻草”，既要做到需要時有備份，也能做到快速恢復，為了實現數據庫自動化備份和快速恢復，我們的DBA團隊經過不斷的嘗試自主開發了一套自動化備份恢復系統（主要用于MySQL同時兼容MongoDB以及Redis）。

MySQL自動化備份總體架構如下：

下面簡單介紹一下自動化備份的主要流程：

1）、自動存儲選擇

每天的定時任務采集所有存儲的的容量信息，根據一定的策略更新數據庫中的存儲相關信息，保證線上所選存儲都可用。備份在存儲選擇時所有機房的存儲都是交叉選擇。即便某個機房的所有存儲被損毀，依然可以從其他機房的存儲拿到可用的備份進行恢復。

2）、備份策略更新

每天備份策略定時任務自動更新實例備份對應信息（如從庫ip、備份保留策略、所選存儲機器等）保證備份策略里的信息***并且可用。

3）、正式執行備份

備份任務根據備份策略信息、選擇備份時間點、存儲機器等，所有條件滿足后正式開始備份。備份任務會自動對數據庫大小進行判斷然后選擇本地備份還是遠程備份。無論哪種備份模式所有備份文件都會經過壓縮加密后再傳輸。

4）、備份失敗檢查

備份失敗檢查任務會定期檢查每天的備份信息狀態并入庫，備份失敗相關信息會實時在360 hulk云平臺中展示并由DBA進行及時處理。

5）、過期備份清理

數據總是一直增長的，存儲空間總是有限的，因此我們會根據備份策略里的清理策略定期清理過期的備份以保證有足夠的空間可用。

你永遠無法預測開發哪天突然誤刪數據，你也無法想象某天苦x的DBA手一得瑟drop了某個庫。所以，完善的備份機制最終是為了快速恢復。

如下是我們MySQL自動化恢復的流程圖：  

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

在實際的生產環境中，我們的備份恢復系統很大程度上已經實現了自動化，不過隨著業務和數據的不斷增長以及行業對數據的重視程度越來越高，在快速自動化備份和恢復這個方向上我們還有很長的路要走還有更多的事情可做。希望我們的經驗可以供大家所用。

關于作者：

孔德亮（微信號：randykong），奇虎360云事業部總監，跨領域技術專家，現任360私有云、公有云項目負責人。

孔德亮2009年加入奇虎360，隨著360業務快速發展，他也開始了內部創業之旅，先后負責應用運維、DBA、基礎架構等工作，通過逐步積累形成了私有云平臺。眾所周知，運維的工作“臟、苦、累”，一旦出現問題，運維人員似乎永遠是那個背黑鍋的人，所以，他希望能夠將技術產品化，使業務團隊在借助云平臺的力量，縮短研發周期、降低運維成本，同時能讓IT技術人員在靈活的操作體驗中感受愉悅。

孔德亮：大規模集群運維經驗（一）