孔德亮：大規(guī)模集群運維經驗（二）

原創(chuàng)
作者：孔德亮 奇虎360云事業(yè)部總監(jiān) 2015-08-31 05:51:37

云計算 本文基于360私有云-HULK云平臺技術積累，著重介紹一下后端數(shù)據(jù)庫MySQL的相關運維經驗。本文作者是奇虎360云事業(yè)部總監(jiān)孔德亮，作者以最基本、最通用的LNMP架構闡述前端WEB服務和后端數(shù)據(jù)庫服務，這“一前一后”在異地多活、集群管理等方面的實踐經驗。

創(chuàng)新互聯(lián)建站擁有十多年成都網站建設工作經驗,為各大企業(yè)提供成都網站設計、網站制作服務，對于網頁設計、PC網站建設（電腦版網站建設）、重慶APP開發(fā)、wap網站建設（手機版網站建設）、程序開發(fā)、網站優(yōu)化（SEO優(yōu)化）、微網站、國際域名空間等，憑借多年來在互聯(lián)網的打拼，我們在互聯(lián)網網站建設行業(yè)積累了很多網站制作、網站設計、網絡營銷經驗，集策劃、開發(fā)、設計、營銷、管理等網站化運作于一體，具備承接各種規(guī)模類型的網站建設項目的能力。

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

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

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

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

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

1、 機器故障：

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

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

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

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

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

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

2、 某機房故障：

1） 網絡故障：

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

⑴ 機房出口網絡故障：

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

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

⑵ 機房內部網絡故障

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

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

⑶ 機房之間光纖異常：

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

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

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

#p#

自動化備份恢復系統(tǒng)

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

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

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

1）、自動存儲選擇

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

2）、備份策略更新

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

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

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

4）、備份失敗檢查

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

5）、過期備份清理

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

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

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

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

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

關于作者：

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

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

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

分享標題：孔德亮：大規(guī)模集群運維經驗（二）
新聞來源：http://www.dlmjj.cn/article/djejdii.html