京東數(shù)據(jù)庫運維自動化體系建設(shè)之路

運維自動化來源于工作中的痛點，京東數(shù)據(jù)庫團隊面對的是商城成千上萬的研發(fā)工程師，這種壓力推動我們不斷變革，然而變革不是一蹴而就，也經(jīng)歷過從手工到腳本化、自動化、平臺化、智能化的艱難轉(zhuǎn)變，所以說是需求在驅(qū)動運維體系的建設(shè)，而運維自動化的真諦在于解放運維人員，促進人率提升，減少人為故障，要學(xué)會培養(yǎng)自己“懶”這個好習(xí)慣。京東的自動化運維體系建設(shè)始于2012年，下面從兩個方面進行介紹。
1. 京東數(shù)據(jù)庫智能運維平臺
京東業(yè)務(wù)每年都在以爆發(fā)的形式在增長，數(shù)據(jù)庫服務(wù)器的數(shù)量眾多，產(chǎn)品線也多達上千條，要支持如此龐大的業(yè)務(wù)體系，需要一套完善的運維自動化管理平臺。目前京東MySQL數(shù)據(jù)庫管理平臺簡稱DBS，主要涵蓋以下內(nèi)容：完善的資產(chǎn)管理系統(tǒng)、數(shù)據(jù)庫流程管理系統(tǒng)、數(shù)據(jù)庫監(jiān)控系統(tǒng)、數(shù)據(jù)庫故障管理系統(tǒng)、數(shù)據(jù)庫報表系統(tǒng)、彈性數(shù)據(jù)庫系統(tǒng)以及數(shù)據(jù)庫輔助運維工具，涉及DBA運維的方方面面，實現(xiàn)了DBA對MySQL的自動化、自助化、可視化、智能化、服務(wù)化管理，避免DBA因手工操作失誤帶來的生產(chǎn)事故，保障京東數(shù)據(jù)庫的安全、穩(wěn)定、高效運行。這里著重介紹以下部分核心功能組件。

1.1. 元數(shù)據(jù)管理
作為自動化運維的基石，它的準確性直接關(guān)系到整個數(shù)據(jù)庫管理平臺的可靠性。京東數(shù)據(jù)庫管理平臺從數(shù)據(jù)庫業(yè)務(wù)方、DBA的運維習(xí)慣等方面出發(fā)，涵蓋機房、主機、業(yè)務(wù)、集群、實例、庫、表等多個維度。
? 機房和主機維度：主要記錄硬件方面的信息。
? 業(yè)務(wù)維度：主要記錄業(yè)務(wù)的名稱、等級及業(yè)務(wù)部門相關(guān)信息。
? 集群維度：主要記錄MySQL集群架構(gòu)信息。
? 實例維度：主要記錄MySQL的相關(guān)參數(shù)，為后續(xù)自動化運維提供保障。
? 庫維度：主要記錄數(shù)據(jù)庫名稱及業(yè)務(wù)人員聯(lián)系信息。

1.2. 自動化部署
面對繁雜的數(shù)據(jù)庫新增，擴容等運維工作，利用自動安裝部署平臺可以徹底解放DBA。目前京東的自動化部署系統(tǒng)包含申請服務(wù)器，部署數(shù)據(jù)庫實例，同步數(shù)據(jù)，一致性校驗，拆分及切換等操作，整個過程流程化，包含各級業(yè)務(wù)及DBA的操作審批，最終達到全面的MySQL服務(wù)的自動化和流程化部署，如下圖 。

主要功能點包含以下內(nèi)容：
? 安裝部署MySQL實例，架構(gòu)搭建，域名申請。分配規(guī)則要求同一集群主從實例不能在同一機柜，硬件性能好的主機優(yōu)先為主庫。
? 監(jiān)控部署，備份部署，資產(chǎn)注冊。
? MySQL服務(wù)采用鏡像的形式創(chuàng)建，鏡像依賴于k8s的鏡像倉庫。
? 應(yīng)用賬號是應(yīng)用方通過自動化上線系統(tǒng)申請創(chuàng)建的。
? 主從數(shù)據(jù)一致性校驗，通常會選擇夜間業(yè)務(wù)低峰期定時執(zhí)行。
1.3. 智能分析與診斷
京東的智能分析與診斷涵蓋4部分重要的內(nèi)容，數(shù)據(jù)庫監(jiān)控指標(biāo)采集，診斷分析，故障自愈，趨勢分析。

1.3.1 監(jiān)控系統(tǒng)
監(jiān)控系統(tǒng)為數(shù)據(jù)庫管理提供了精準的數(shù)據(jù)依據(jù)，能夠讓運維人員對生產(chǎn)服務(wù)系統(tǒng)運行情況了如指掌，核心的監(jiān)控指標(biāo)包含：OS負載，MySQL核心指標(biāo)，數(shù)據(jù)庫日志等。通過分析獲得的監(jiān)控信息，判斷被監(jiān)控數(shù)據(jù)庫的運行狀態(tài)，對可能出現(xiàn)的問題進行預(yù)測，并給出優(yōu)化方案，保證整個系統(tǒng)穩(wěn)定、高效。
京東的分布式監(jiān)控系統(tǒng)采用被動模式，server端和proxy端均做高可用，防止單點故障。以下是整體架構(gòu)和流程圖：

1.3.2 監(jiān)控性能分析

數(shù)據(jù)庫性能智能分析，主要是對數(shù)據(jù)庫監(jiān)控數(shù)據(jù)的二次分析，排除安全隱患。在實際的生產(chǎn)中，有些隱患沒有達到設(shè)置的報警閾值，處于一個報警的臨界點，其實這種情況是最危險的，隨時可能爆發(fā)，為解決這些隱患，我們通過對監(jiān)控數(shù)據(jù)的環(huán)比、同比、TOP指標(biāo)等方面進行分組匯總分析，提前發(fā)現(xiàn)隱患。
? 慢SQL分析

? 索引分析

? 空間分析及預(yù)測

? 鎖分析

1.3.3 故障自愈

故障出現(xiàn)的形態(tài)千奇百怪，而最核心的內(nèi)容依賴于監(jiān)控的輔助分析，如何提供最為精準的信息，所做內(nèi)容如下：
? 告警過濾：將告警中不重要的告警以及重復(fù)告警過濾掉
? 生成派生告警：根據(jù)關(guān)聯(lián)關(guān)系生成各類派生告警
? 告警關(guān)聯(lián)：同一個時間窗內(nèi)不同類型派生告警是否存在關(guān)聯(lián)
? 權(quán)重計算：根據(jù)預(yù)先設(shè)置的各類告警的權(quán)重，計算成為根源告警的可能性
? 生成根源告警：將權(quán)重最大的派生告警標(biāo)記為根源告警
? 根源告警合并：若多類告警計算出的根源告警相同，則將其合并
1.4. 智能切換系統(tǒng)
京東數(shù)據(jù)庫服務(wù)器的量級較大，會導(dǎo)致出故障的概率相對提高，同時對系統(tǒng)穩(wěn)定性的要求也較為苛刻。因此為確保實現(xiàn)數(shù)據(jù)庫高可用，保證7*24小時的持續(xù)服務(wù)，我們團隊自主研發(fā)了數(shù)據(jù)庫自動切換平臺，實現(xiàn)了自動和半自動兩種切換方式，實現(xiàn)了按單集群級別、多集群級別、機房級別等多維度的場景切換。切換過程包含監(jiān)控的修改、資產(chǎn)信息的修改、備份策略的修改、主從角色的修改等，一鍵化完成，避免人為因素帶來的二次故障。
1.4.1 分布式檢測
作為切換系統(tǒng)的核心組件，分布式檢測功能主要解決系統(tǒng)容災(zāi)方面的問題。按照京東數(shù)據(jù)庫服務(wù)器多數(shù)據(jù)中心部署的特征，獨立的數(shù)據(jù)中心各部署了一個檢測節(jié)點，并通過特殊標(biāo)識的接口域名區(qū)分。當(dāng)發(fā)生切換操作時，切換系統(tǒng)會根據(jù)傳入的故障主機IP等信息，隨機選取兩個機房接口執(zhí)行調(diào)用，探活操作如果發(fā)現(xiàn)有一個節(jié)點主機存活，那么認為主機存活，如果發(fā)現(xiàn)兩個節(jié)點都探測為宕機，那么認為主機宕機。
1.4.2 Master故障切換
主庫實例故障，切換系統(tǒng)會首先通過分布式檢測系統(tǒng)檢查實例存活狀態(tài)，確認宕機后將根據(jù)基礎(chǔ)信息中的實例切換標(biāo)識，選擇使用自動切換或手動切換，兩種切換方式原理相同：先在切換系統(tǒng)上創(chuàng)建切換任務(wù)，手動切換需要DBA執(zhí)行切換按鈕，切換操作會通過insert方式插入數(shù)據(jù)以驗證實例運行狀態(tài)，避免實例夯住和硬盤只讀的情況。如果沒有存活的從庫，則放棄本次操作并以郵件和短信的方式通知DBA。新主庫是按照先本地（先連接數(shù)少，后QPS負載低），后異地的原則選擇，執(zhí)行切換成功后將變更相應(yīng)元數(shù)據(jù)信息，示例如下：
某一主四從的集群，主庫 10.66.66.66:3366故障，需要切換，如下：

1.監(jiān)控系統(tǒng)檢測到主庫宕機，則自動創(chuàng)建切換任務(wù)，進行自動切換或者手動切換，以手動切換為例：

2.選目標(biāo)實例，假如例子中的4個從都是存活的，那么根據(jù)先本地后異地原則，選出10.66.66.68:3366，10.66.66.69:3366，然后再去查連接數(shù)，在連接數(shù)都相同的情況下，則去比較QPS，選出QPS負載低的10.66.66.69:3366作為目標(biāo)實例。

3.切換完成結(jié)果

1.4.3 Slave故障切換
從庫實例故障，將故障實例下的域名變更到該集群下的非故障實例上，選擇目標(biāo)實例方式與主庫實例選擇規(guī)則一致。切換成功或失敗都會發(fā)郵件及短信告知相應(yīng)的DBA。故障實例恢復(fù)后，DBA判斷是否需要回切。示例如下：
有一主四從的集群，從庫 10.88.88.89:3366故障，需要切換，如下：

監(jiān)控系統(tǒng)會自動創(chuàng)建任務(wù)，并根據(jù)先本地后異地原則，然后再查連接數(shù)，QPS，確定目標(biāo)實例為10.88.88.88:3366，進行自動切換，DBA可在切換任務(wù)列表查看詳情。

切換成功的任務(wù)會顯示回切按鈕，DBA可以執(zhí)行回切，并查看回切的具體信息。

1.4.4 主從計劃性切換
主從計劃性切換實現(xiàn)了按單集群，多集群的批量切換。執(zhí)行批量切換時可以查看子任務(wù)切換的具體步驟，切換后會有前后架構(gòu)的對比，具體示例如下：
集群1

批量創(chuàng)建任務(wù)，選擇原則根據(jù)先本地后異地，先連接數(shù)后QPS，10.66.66.66:3366選擇目標(biāo)主庫為：10.88.88.89:3366。
批量執(zhí)行切換

切換子任務(wù)詳細信息，可查看到每個子任務(wù)的切換結(jié)果，執(zhí)行步驟及前后架構(gòu)。

京東MySQL數(shù)據(jù)庫切換系統(tǒng)各功能模塊都已組件化、服務(wù) 簡化了DBA的操作流程，縮短了數(shù)據(jù)庫切換的時間。
1.5. 數(shù)據(jù)庫自動化備份恢復(fù)
1.5.1 架構(gòu)設(shè)計
京東數(shù)據(jù)庫備份系統(tǒng)在設(shè)計之初，就是為了將DBA從繁雜的備份管理工作中解脫出來，實現(xiàn)自動處理，減少人為干預(yù)，并提高備份文件的可用性。關(guān)于備份文件可用性問題，以輪詢恢復(fù)的策略確保每個集群在一個周期內(nèi)都被恢復(fù)到。系統(tǒng)架構(gòu)設(shè)計如下圖所示：

架構(gòu)具備以下幾個特點：

1) 調(diào)度觸發(fā)多樣化：
調(diào)度中心支持三種類型的觸發(fā)方式interval、crontab和date。
interval是周期調(diào)度，可以指定固定間隔時長的任務(wù)調(diào)度，支持時間單位有weeks、days、hours、minutes、seconds，并支持設(shè)定調(diào)度開始時間和結(jié)束時間以及時區(qū)設(shè)置。
crontab是定時調(diào)度，與Linux的crontab基本相同，支持year、month、day、week、day_of_week、hour、minute、second，并且支持設(shè)置調(diào)度開始時間和結(jié)束時間以及時區(qū)設(shè)置。
date是一次性定時調(diào)度，支持時區(qū)設(shè)置。
2) 并發(fā)控制：
由于調(diào)度任務(wù)設(shè)置具有不均衡性，可能某一時刻需要調(diào)度的任務(wù)較多，容易引起調(diào)度系統(tǒng)出現(xiàn)問題，因此執(zhí)行任務(wù)通過控制并發(fā)數(shù)來使任務(wù)調(diào)度執(zhí)行運行更加平穩(wěn)。
3) 觸發(fā)和執(zhí)行分層：
任務(wù)觸發(fā)本身是輕量級集的，而任務(wù)執(zhí)行一般都比較重，因此對觸發(fā)和執(zhí)行進行了分層設(shè)計，來防止因為執(zhí)行時間過長導(dǎo)致后續(xù)觸發(fā)出現(xiàn)問題。
4) 維護期間任務(wù)不丟失：
Linux的crontab在停機維護期間要運行的任務(wù)開機后并不會再次執(zhí)行，而基于APScheduler的調(diào)度中心則會在啟動后運行指定間隔內(nèi)尚未執(zhí)行的任務(wù)，減少因維護而錯失任務(wù)的執(zhí)行。
5) 備份策略增刪改查：
之前公司的備份系統(tǒng)是需要指定特定的IP，經(jīng)常因為服務(wù)器維護而導(dǎo)致備份失敗，故在設(shè)計之初就將備份策略與高可用結(jié)合在一起，備份策略指定域名而不是IP。從庫因為故障切換時DBS會將此從庫上的域名切換到集群內(nèi)的其他從庫，相應(yīng)的備份也跟隨到了此從庫，保證了備份服務(wù)器是可用的。
6) 失敗自動重試：
備份很可能因為偶然因素而失敗，因此加入了備份重試的功能，會對6小時以內(nèi)的備份失敗任務(wù)進行備份重試，最多重試3次，來獲得更高的備份成功率。
7) 自動恢復(fù)檢測：
備份在每一步都要嚴格地驗證，但是也無法絕對保證備份文件可用，因此引入了自動恢復(fù)檢測機制，來幫助DBA對備份文件進行檢測，及時發(fā)現(xiàn)因為各種未考慮到的情況導(dǎo)致備份文件不可用的情況，并且恢復(fù)檢測也是審計的一個硬性要求，自動恢復(fù)檢測也將DBA從繁重的恢復(fù)檢測工作中徹底解脫了出來。

1.5.2 調(diào)度設(shè)計

整個自動化備份恢復(fù)系統(tǒng)主要由調(diào)度系統(tǒng)、備份系統(tǒng)、恢復(fù)系統(tǒng)、恢復(fù)檢測系統(tǒng)、自動修復(fù)系統(tǒng)組成。其中調(diào)度系統(tǒng)是整個系統(tǒng)核心，通過調(diào)度系統(tǒng)來協(xié)調(diào)其他系統(tǒng)運行。調(diào)度系統(tǒng)可以部署Standby來實現(xiàn)高可用，執(zhí)行器以集群部署來實現(xiàn)高可用和橫向擴容。
備份系統(tǒng)每次備份時都會進行實例健康狀態(tài)檢查、備份運行狀態(tài)檢查等，防止對無效的數(shù)據(jù)庫實例進行備份；恢復(fù)系統(tǒng)主要是在需要進行數(shù)據(jù)恢復(fù)、彈性擴容等等需要從備份文件恢復(fù)成運行的數(shù)據(jù)庫實例時使用，能夠讓DBA通過簡單地操作即可完成數(shù)據(jù)的恢復(fù);恢復(fù)檢測在調(diào)度系統(tǒng)的指揮下自動對備份文件可用性進行檢測，來幫助DBA及時發(fā)現(xiàn)不可用的備份文件；備份失敗有些是能夠通過失敗自動重試來解決，但有一部分是重試所不能解決的，需要進行相應(yīng)修復(fù)，因此開發(fā)了自動修復(fù)系統(tǒng)來自動修復(fù)因為環(huán)境等問題引起的備份失敗。
調(diào)度系統(tǒng)是最核心的一個系統(tǒng)，是整個備份恢復(fù)系統(tǒng)的大腦，當(dāng)時考察了幾種實現(xiàn)方式，例如Linux的crontab、Azkaban和python的開源框架Apscheduler，最終認為Apscheduler更加靈活小巧，調(diào)度方式也更加多樣化，使用Python開發(fā)后期維護成本更低，因此采用Apscheduler開發(fā)了調(diào)度中心。

1.5.3 系統(tǒng)前端
主要分為備份策略管理、備份詳情、備份黑名單管理、恢復(fù)詳情四個模塊。
備份策略管理：

備份策略管理的頁面包含了備份狀態(tài)分布情況、存儲使用情況以及每個集群的當(dāng)前備份策略狀態(tài)，如果已經(jīng)添加了備份策略則可以在這里進行（時間、服務(wù)器、備份方式）修改、暫停（繼續(xù)）、刪除操作，如果沒有添加備份策略，則可以進行添加。
備份詳情：

備份詳情里面展示了最近備份總數(shù)，成功數(shù)，成功率，當(dāng)天備份任務(wù)運行狀態(tài)，備份任務(wù)24小時分布曲線圖以及備份詳細記錄。備份詳細的記錄可以根據(jù)集群名、項目名等信息進行查詢，方便DBA更好地掌握備份運行狀況。

恢復(fù)檢測詳情：

恢復(fù)檢測頁面包含最近每天恢復(fù)檢測數(shù)，恢復(fù)檢測成功數(shù)，成功率柱狀圖，當(dāng)天恢復(fù)檢測任務(wù)運行狀態(tài)餅圖和近期恢復(fù)檢測完成率，有助于DBA對恢復(fù)概況有更清晰的了解。

2. 數(shù)據(jù)庫變革
2.1. 過去
在ContainerDB之前，京東的數(shù)據(jù)庫服務(wù)實現(xiàn)了容器化，雖然數(shù)據(jù)庫服務(wù)已經(jīng)完全通過Docker容器實現(xiàn)了數(shù)據(jù)庫服務(wù)的快速交付和自動故障切換等基本功能，在一定程度上提高了數(shù)據(jù)庫服務(wù)的穩(wěn)定性和效率，但是數(shù)據(jù)庫服務(wù)的運維和使用方式與傳統(tǒng)方式基本無異，比較典型的問題如下：
2.1.1 資源分配粒度過大
數(shù)據(jù)庫服務(wù)器資源標(biāo)準固定，粒度過大，為數(shù)據(jù)庫服務(wù)可提供的資源標(biāo)準過少。
2.1.2 資源浪費嚴重
資源分配的標(biāo)準有DBA根據(jù)經(jīng)驗決定，存在很大的主觀性，不能根據(jù)業(yè)務(wù)的實際情況進行準確評估，而DBA在分配資源的時候一般都會考慮在3年以內(nèi)不需要對服務(wù)進行遷移或者擴容，而一次分配比較多的資源，存在嚴重資源浪費。而且由于數(shù)據(jù)庫資源標(biāo)準固定，標(biāo)準過大，導(dǎo)致宿主機中的碎片過大，經(jīng)常出現(xiàn)一臺宿主機只能創(chuàng)建一個容器，而剩下的資源滿足不了任何資源標(biāo)準，導(dǎo)致宿主機上資源使用率過低。
2.1.3 資源靜態(tài)、無調(diào)度
數(shù)據(jù)庫服務(wù)一旦提供，所占據(jù)的資源就會固定，不能根據(jù)數(shù)據(jù)庫的負載進行在線動態(tài)的調(diào)度，而一旦數(shù)據(jù)庫的硬盤使用率過高，需要DBA人工介入進行擴容處理，效率低下。

2.2. 現(xiàn)在
基于以上的問題，單純的數(shù)據(jù)庫服務(wù)容器化已經(jīng)無法解決，我們需要讓數(shù)據(jù)庫服務(wù)更聰明，讓數(shù)據(jù)庫的資源能夠動起來，提供資源分期交付的功能，于是ContainerDB應(yīng)運而生。ContainerDB基于負載的彈性調(diào)度為京東的數(shù)據(jù)庫資源賦予了智慧，令其資源真正地流動起來，并已成功服務(wù)于多次618和11.11大促。

ContainerDB針對每個業(yè)務(wù)應(yīng)用都有邏輯庫，邏輯庫中定義了針對整個業(yè)務(wù)所有表的拆分鍵（Sharding Key）進行哈希取模運算時模的范圍（KeySpace），在每個邏輯庫中可以創(chuàng)建多張表，但是每個表中必須定義Sharding Key。通過該Sharding Key將表中的數(shù)據(jù)拆分成多個分片（Shard），每個分片都對應(yīng)一個KeyRange，KeyRange表示對Sharding Key進行哈希取模運算之后得到的值（Sharding Index）的一個范圍，每個Shard都由一整套MySQL主從架構(gòu)提供數(shù)據(jù)庫服務(wù)支撐。應(yīng)用程序只跟Gate集群進行交互，由Gate根據(jù)元數(shù)據(jù)信息和SQL語句完成數(shù)據(jù)寫入和查詢的自動路由。ContainerDB中的監(jiān)控中心會對所有的基礎(chǔ)服務(wù)和資源使用狀況進行實時監(jiān)控，并通過在監(jiān)控中心注冊的Hook程序自動進行動態(tài)擴容、故障自愈、分片管理等，而這一系列操作對應(yīng)用程序來說是完全無感知的。
2.2.1 流式資源持續(xù)交付

數(shù)據(jù)庫以前的服務(wù)存在資源浪費的一個主要原因就是資源初始分配粒度太大，一開始就為業(yè)務(wù)提前預(yù)支3年甚至5年的資源。而資源池中的資源是有限的，不可能讓所有業(yè)務(wù)都提前預(yù)支資源，從而導(dǎo)致有些業(yè)務(wù)沒有資源。ContainerDB采用流式的方式進行資源的持續(xù)交付。每個業(yè)務(wù)接入初始都只會分配標(biāo)準的64G硬盤，隨著業(yè)務(wù)的發(fā)展和數(shù)據(jù)量的持續(xù)增加，會持續(xù)增加硬盤容量直到到達硬盤限制的上限256G。

通過這種方式，我們極大地拉長了數(shù)據(jù)庫資源的交付周期，進而可以在三年或者五年的所有資源預(yù)算到位之前就可以首先為所有服務(wù)提供數(shù)據(jù)庫服務(wù)，提升了數(shù)據(jù)庫的業(yè)務(wù)支撐能力。
2.2.2 基于負載的彈性調(diào)度
數(shù)據(jù)庫服務(wù)使用的資源分為兩類：瞬時資源和遞增資源。
瞬時資源是指會資源的使用率在短時間之內(nèi)會出現(xiàn)嚴重波動，這種資源主要包括CPU和內(nèi)存。
遞增資源是指資源的使用率不會再短時間之內(nèi)出現(xiàn)嚴重的波動，而是會緩慢增加，并且支持遞增，不會出現(xiàn)減少的情況，這種資源主要包括硬盤。ContainerDB對于不同的資源采取了不同的調(diào)度策略。針對于瞬時資源，ContainerDB為每個數(shù)據(jù)庫分配三種標(biāo)準：
? 下限：2C/4G， 上限：4C/8G
? 下限：4C/8G， 上限：8C/16G
? 下限：8C/16G， 上限：16C/32G
每個容器分配的初始資源為標(biāo)準的下限值，當(dāng)數(shù)據(jù)庫服務(wù)出現(xiàn)CPU負載過高或者內(nèi)存不足時，會嘗試申請多于下限的CPU或者內(nèi)存，但絕對不會超過上限，待負載恢復(fù)后釋放多申請的資源，直至恢復(fù)至CPU和內(nèi)存的下限為止。

針對遞增資源：磁盤，在業(yè)務(wù)接入之初，統(tǒng)一分配64G的硬盤，每當(dāng)當(dāng)前磁盤使用率達到80%，且沒有達到256G上限的時候，則進行垂直升級；若容器當(dāng)前磁盤達到了256G上限則進行在線Resharding。
垂直升級：首先會進行資源check，看宿主機是否有足夠的剩余硬盤資源進行垂直升級，若check通過，則會在宿主機施加全局資源鎖，并對硬盤進行垂直擴容再增加64G。若check不通過，則在宿主機上提供一個硬盤大小為：磁盤容量+64G大小，CPU和內(nèi)存與當(dāng)前容器相同的新容器，并將數(shù)據(jù)庫服務(wù)遷移到新的容器上。垂直升級是瞬間完成的不會影響數(shù)據(jù)庫服務(wù)。
在線Resharding：申請兩個新的Shard，新Shard中的數(shù)據(jù)庫Container的硬盤、CPU和內(nèi)存標(biāo)準與當(dāng)前Shard中的完全一致，根據(jù)當(dāng)前Shard中的數(shù)據(jù)庫主從關(guān)系，對新Shard中的所有數(shù)據(jù)庫重建MySQL主從關(guān)系，然后啟動Schema信息拷貝和過濾復(fù)制，最后更新路由規(guī)則并將讀寫流量切換到新的Shard上，將舊的Shard資源下線。
無論是垂直升級還是在線Resharding，都需要注意一個問題：在保證每個分片的Master在主機房的前提下，盡量不要將所有的資源都分配在一個宿主機/機架/機房，ContainerDB提供了強大的親和/反親和性資源分配能力。目前ContainerDB的親和/反親和性策略如下：

每個KeySpace都有一個主機房，屬于同一個Shard中的數(shù)據(jù)庫實例（目前一個shard中包含1主2從）的資源分配盡量應(yīng)該滿足：Master必須屬于主機房，不能有任意兩個實例屬于同一機架，不能有任意三個實例在同一IDC，這種策略可以避免某一機柜掉電而導(dǎo)致主從同時出現(xiàn)故障，也可以避免IDC故障從而導(dǎo)致所有數(shù)據(jù)庫實例均不可用。
由于是盡量滿足，所以當(dāng)資源池中的資源分布不均時，就有可能在資源分配的時候滿足不了上述的反親和性策略。因此ContainerDB有一個常駐后臺進程，不停的輪詢集群中的所有Shard，判斷Shard中的實例分布是否滿足反親和性規(guī)則，若不滿足，就會嘗試進行實例重新分布。重新分布時為了不影響線上業(yè)務(wù)，會優(yōu)先進行從庫重分布。
基于彈性調(diào)度的能力ContainerDB實現(xiàn)了如下三個功能：
在線擴容：當(dāng)某個Shard的數(shù)據(jù)庫負載達到閾值后，會自動觸發(fā)Shard的在線垂直升級、遷移或者Resharding。
在線自愈：當(dāng)Shard中的某個MySQL實例出現(xiàn)故障，ContainerDB首先判斷出現(xiàn)故障的實例是否為master，若是master，則選擇GTID最大的slave作為新的主，并進行復(fù)制關(guān)系重建和Slave補齊；若不是master，則直接進行slave補齊。
在線接入：ContainerDB允許用戶以完全自助化的方式啟動數(shù)據(jù)在線遷移與接入任務(wù)，該任務(wù)會將傳統(tǒng)MySQL數(shù)據(jù)庫中的數(shù)據(jù)在線遷移到ContainerDB中，待數(shù)據(jù)遷移完畢后，自動進行域名切換，完成業(yè)務(wù)系統(tǒng)數(shù)據(jù)源的在線無感知遷移。
ContainerDB通過在線服務(wù)能力擴容、在線自愈和在線接入三大功能，實現(xiàn)了京東數(shù)據(jù)庫服務(wù)的Always Online保證。
2.2.3 不止于調(diào)度
彈性和流式的資源交付與調(diào)度是ContainerDB的基石，但是除了這兩個核心功能之外，ContainerDB還在用戶易用性、兼容性和數(shù)據(jù)安全性等方面做了很多工作，包括：
數(shù)據(jù)保護
在傳統(tǒng)的直連數(shù)據(jù)庫的方案下，當(dāng)Master出現(xiàn)網(wǎng)絡(luò)不可達時，一般都會選擇新的Slave變?yōu)镸aster，然后將原來Master上的域名漂移到新的Master上。但是這種方案在網(wǎng)絡(luò)抖動的情況下很容易由于AppServer上的DNS緩存，而導(dǎo)致雙Master，并且出現(xiàn)臟寫的情況。從整體架構(gòu)圖可以看出，ContainerDB與用戶之間通過Gate連接。Gate是一個集群化服務(wù)，多個Gate服務(wù)都映射到一個域名下，Gate通過IP地址直接訪問各個MySQL服務(wù)，而且Gate對各個MySQL角色的識別完全依賴于元數(shù)據(jù)服務(wù)：Topology。當(dāng)ContainerDB中某個MySQL的Master產(chǎn)生網(wǎng)絡(luò)不可達時，會選出新的Master，并更新路由元數(shù)據(jù)信息，最后才做Master切換，這樣就避免了由于網(wǎng)絡(luò)抖動和DNS緩存而在成雙主和數(shù)據(jù)臟寫，從而對數(shù)據(jù)進行了嚴格的保護。
流式查詢處理

ContainerDB通過在Gate層實現(xiàn)基于優(yōu)先級的歸并排序提供了快速流式查詢的功能，在進行大批量數(shù)據(jù)查詢時，能瞬時返回部分查詢結(jié)果數(shù)據(jù)，極大提高客戶體驗。
無感知數(shù)據(jù)遷移
ContainerDB通過在交叉在Window函數(shù)中分別執(zhí)行部分存量數(shù)據(jù)拷貝和增量數(shù)據(jù)追加的算法，開發(fā)了在線數(shù)據(jù)遷移和接入工具JTransfer，通過JTransfer可以將傳統(tǒng)MySQL數(shù)據(jù)庫中的動態(tài)數(shù)據(jù)遷移到ContainerDB中，當(dāng)ContainerDB中的數(shù)據(jù)與源MySQL中的數(shù)據(jù)的lag小于5秒時，首先會將源MySQL停寫，待lag變?yōu)?時將源MySQL的域名漂移到Gate集群，整個遷移過程用戶AppServer無感知。
兼容MySQL協(xié)議
ContainerDB完全兼容MySQL協(xié)議，支持標(biāo)準MySQL客戶端和官方驅(qū)動程序接入，并且支持大部分ANSI SQL語法。

路由規(guī)則透明
ContainerDB與用戶之間通過Gate集群進行連接，Gate根據(jù)用戶發(fā)送的查詢語句形成的語法樹和查詢執(zhí)行計劃得到查詢中涉及到的所有表，并根據(jù)Topology中的元數(shù)據(jù)信息獲得各個表的分片信息，最后結(jié)合語句中的Join中的關(guān)聯(lián)條件和Where字句中的謂詞信息，將查詢或者寫入路由到正確的分片。整個過程都是Gate自動完成的，對用戶完全透明。
自助化服務(wù)
ContainerDB將對數(shù)據(jù)庫服務(wù)的實例化、DDL/DML執(zhí)行、分片升級和擴容等功能抽象成為獨立的接口，并借助于流程引擎提供了流程化的完全自助的用戶接入服務(wù)，用戶申請數(shù)據(jù)庫服務(wù)成功后，ContainerDB會將數(shù)據(jù)庫訪問口令自動推送到用戶郵箱。
3. 展望
過去已去，未來已來。
我們后續(xù)會更多的從用戶的角度去思考數(shù)據(jù)庫能夠產(chǎn)生的價值。我們相信京東以后的數(shù)據(jù)庫服務(wù)會：
More Smart：我們會基于各個數(shù)據(jù)庫實例中CPU/內(nèi)存/硬盤等各種不同資源的監(jiān)控數(shù)據(jù)進行深度學(xué)習(xí)和聚類分析，分析出各個不同數(shù)據(jù)庫實例的傾向資源，并智能化調(diào)高每個數(shù)據(jù)庫實例傾向資源的限制并調(diào)低非傾向資源的限制。
More Quick：我們會實時分析宿主機和容器的對應(yīng)關(guān)系、各個容器的限制參數(shù)以及各個容器的歷史資源增長速率，預(yù)先對容器所在宿主機碎片進行整理，從而盡量保證各個容器以垂直升級的方式實現(xiàn)擴容，從而極大地加快擴容速度。
More Cheap：我們會提供完全自主研發(fā)的存儲引擎，計劃實現(xiàn)查詢引擎與存儲引擎的集成，并提供多模型數(shù)據(jù)庫引擎，從而實現(xiàn)多種數(shù)據(jù)模型的統(tǒng)一，極大節(jié)省數(shù)據(jù)庫服務(wù)所需資源以及研發(fā)成本。
More Friendly：無論是ContainerDB還是我們自主研發(fā)的多模型數(shù)據(jù)庫，我們都會完全兼容MySQL協(xié)議及語法，從而使得現(xiàn)有應(yīng)用的遷移成本趨近于0。
More Open：ContainerDB會在經(jīng)過京東內(nèi)部的各種場景的磨練之后會擁抱開源，并希望與業(yè)界各位同仁一起將ContainerDB不斷完善。同時我們后續(xù)的多模型數(shù)據(jù)庫最終也會貢獻給開源社區(qū)，并期待其服務(wù)于業(yè)界。