輕量級CloudDB實(shí)例的高可用實(shí)現(xiàn)方案

崔?？?/p>

（對外經(jīng)濟(jì)貿(mào)易大學(xué)統(tǒng)計(jì)學(xué)院，北京 100029）

0 引言

云計(jì)算框架可以為數(shù)據(jù)庫集群提供基礎(chǔ)環(huán)境操作系統(tǒng)、網(wǎng)絡(luò)、存儲、計(jì)算單元可彈性配置的容器，越來越多的企業(yè)部署輕量級云計(jì)算框架[1]。IAAS層使用OpenStack方案[2]，PaaS層CloudDB數(shù)據(jù)庫集群單實(shí)例采用MySQL內(nèi)核，每個(gè)集群由主庫帶多個(gè)從庫對業(yè)務(wù)提供數(shù)據(jù)讀寫服務(wù)，但當(dāng)主庫故障的時(shí)候會對阻塞業(yè)務(wù)的寫入造成業(yè)務(wù)寫中斷，尤其是在金融場景中帶來交易中斷等嚴(yán)重事故，因此必須提供高可用方案，實(shí)現(xiàn)故障切換并且在切換過程中確保數(shù)據(jù)不丟失，保障故障切換過程在可控的時(shí)間內(nèi)完成，高可用技術(shù)方案是數(shù)據(jù)庫集群最核心的技術(shù)之一，本文就高可用方案進(jìn)行分析和實(shí)現(xiàn)。

1 開源框架應(yīng)對高可用需求遇到的問題

針對傳統(tǒng)架構(gòu)的流量接入層故障，應(yīng)用和管控程序是無狀態(tài)的，開源云計(jì)算框架識別與恢復(fù)較容易[3]，但無法根據(jù)容器內(nèi)數(shù)據(jù)庫實(shí)例的狀態(tài)進(jìn)行調(diào)度，狀態(tài)與調(diào)度策略需要因業(yè)務(wù)變化而定，這是開源框架無法通過標(biāo)準(zhǔn)協(xié)議解決的問題，而且容器內(nèi)數(shù)據(jù)庫版本差異和狀態(tài)參數(shù)也不相同，因此對數(shù)據(jù)庫實(shí)例并不能簡單地容器故障轉(zhuǎn)移來實(shí)現(xiàn)高可用，開源云計(jì)算框架應(yīng)對數(shù)據(jù)庫高可用功能顯得力不從心。

2 高可用功能的設(shè)計(jì)目標(biāo)

2.1 高可用實(shí)現(xiàn)的功能

首先確認(rèn)高可用要解決的問題，當(dāng)提供讀寫服務(wù)的實(shí)例發(fā)生故障時(shí),其故障導(dǎo)致無法寫入，需快速對其進(jìn)行處理，如果實(shí)例故障恢復(fù)環(huán)節(jié)由人工參與，由于故障的時(shí)間難預(yù)測，其故障發(fā)生時(shí)人員到位時(shí)間不可控，人工操作恢復(fù)時(shí)間較長，且受到數(shù)據(jù)庫實(shí)例個(gè)數(shù)的和人工切換熟練程度的限制，當(dāng)數(shù)據(jù)不一致的時(shí)候，其直接影響到服務(wù)，或者即使切換程序由系統(tǒng)程序?qū)崿F(xiàn)，但程序高可用切換策略不可調(diào)整，這些因素都直接影響到服務(wù)的可用性，尤其對于金融類業(yè)務(wù)來說影響更大，因此設(shè)計(jì)動態(tài)可配置可調(diào)整的高可用功能，自動化對主庫故障進(jìn)行處理，快速適配不同環(huán)境業(yè)務(wù)場景需求。

實(shí)例故障切換模塊目標(biāo)在于保證數(shù)據(jù)服務(wù)的穩(wěn)定性，其主要包括以下幾方面的功能，集群故障感知：能對集群的實(shí)例故障進(jìn)行快速識別，并且通過組合判斷條件從庫之間的狀態(tài)，來識別出主實(shí)例故障；集群高可用切換：其主要包括集群主庫故障切換和例行切換兩部分，主庫故障切換是指主庫故障直接影響到服務(wù)的可用性，其需要在主庫故障情況下，快速進(jìn)行數(shù)據(jù)補(bǔ)齊、選取新主等操作，從而保證服務(wù)的可正常運(yùn)行；例行主從切換：是指其在主庫機(jī)器過保、非故障類異常情況下，能夠通過例行的切換操作來將主庫進(jìn)行替換，替換后對原實(shí)例所在機(jī)器進(jìn)行下線處理后續(xù)操作；所有的故障感知條件和切換步驟可配置可定制；

2.2 設(shè)計(jì)的性能指標(biāo)

故障感知小于10秒，切換小于10秒，無數(shù)據(jù)丟失，故障恢復(fù)小于30秒，在數(shù)據(jù)庫故障切換周期內(nèi)讀服務(wù)不受影響，故障實(shí)例數(shù)據(jù)恢復(fù)后能在30秒內(nèi)作為從庫上線提供只讀服務(wù)。

3 高可用功能的架構(gòu)設(shè)計(jì)

高可用管控功能主要由以下組件構(gòu)成：

agent：其主要對服務(wù)器或者虛機(jī)、容器內(nèi)的數(shù)據(jù)庫實(shí)例和數(shù)據(jù)庫代理實(shí)例進(jìn)行托管，負(fù)責(zé)所托管實(shí)例的創(chuàng)建、監(jiān)控?cái)?shù)據(jù)采集，日志管理，定時(shí)任務(wù)處理，集群拓?fù)涫諗浚?/p>

zookeeper：拓?fù)鋷?，集群狀態(tài)協(xié)調(diào)者與單點(diǎn)切換協(xié)調(diào)，主要存儲單點(diǎn)切換的節(jié)點(diǎn)、拓?fù)湎嚓P(guān)的信息，包括節(jié)點(diǎn)靜態(tài)信息存儲：節(jié)點(diǎn)的網(wǎng)址、端口、切換權(quán)值、角色等配置、拓?fù)湫畔ⅲ杭褐鲙臁膸?、備庫等，協(xié)調(diào)整個(gè)故障切換的狀態(tài)，對切換加鎖等，防止切換過程中出現(xiàn)臟信息，對節(jié)點(diǎn)的存活狀態(tài)信息進(jìn)行監(jiān)控；

haproxy：訪問代理用于應(yīng)用連接拓?fù)鋾r(shí)的網(wǎng)址配置，應(yīng)用只需要連接一個(gè)網(wǎng)址，而不用關(guān)心數(shù)據(jù)庫拓?fù)渚唧w網(wǎng)絡(luò)配置。

4 實(shí)例故障感知

4.1 單實(shí)例故障感知策略

主要對MySQL實(shí)例進(jìn)行故障檢測，由agent進(jìn)行，通過重試連接數(shù)過多，識別判斷機(jī)器壓力大，防止出現(xiàn)誤判；通過硬盤檢測，識別出硬件故障；

通過讀寫請求來識別數(shù)據(jù)庫壓力；判斷完畢實(shí)例故障后，根據(jù)實(shí)例角色觸發(fā)對應(yīng)的處理流程，當(dāng)單實(shí)例是從庫時(shí)，對寫并不造成影響，摘除該實(shí)例的讀服務(wù)，如果實(shí)例是主庫，則需要進(jìn)行故障切換，故障感知策略可配置，所有配置均放置于拓?fù)鋷熘小?/p>

4.2 多實(shí)例集群故障感知

agent能對其托管的數(shù)據(jù)庫實(shí)例進(jìn)行故障感知，但是當(dāng)主庫機(jī)器自身異常時(shí)，其需要通過其他從庫實(shí)例的狀態(tài)來聯(lián)合判斷出主庫狀態(tài)，通過從庫的主從狀態(tài)來對集群的主庫存活進(jìn)行判斷，如果所有從庫的主從狀態(tài)均異常，此時(shí)認(rèn)為主庫狀態(tài)異常，進(jìn)入單點(diǎn)切換流程，所有從庫主從狀態(tài)正常，此時(shí)需要進(jìn)行二次判斷，從庫通過使用同步賬戶來重試連接主庫，如果均連接失敗，則認(rèn)為主庫狀態(tài)異常，以上每個(gè)故障感知方法可以配置，每個(gè)環(huán)節(jié)的順序和環(huán)節(jié)數(shù)可以配置、調(diào)整。

4.3 集群拓?fù)涔收细兄?/h3>

在上述聯(lián)合判斷出主庫故障后，仍然要根據(jù)前后故障感知和當(dāng)前集群副本數(shù)來進(jìn)行二次判斷，防止集群因?yàn)轭l繁切換導(dǎo)致雪崩，或者因?yàn)槿萘坎蛔銓?dǎo)致集群切換后仍然無法使用的情況，該流程對整個(gè)集群的切換狀態(tài)進(jìn)行二次判斷，其主要包括兩類：兩次切換時(shí)間間隔，防止因?yàn)榫W(wǎng)絡(luò)頻繁抖動，或者因?yàn)闃I(yè)務(wù)流量暴增導(dǎo)致主庫頻繁故障，此時(shí)如果頻繁進(jìn)行切換，導(dǎo)致雪崩無主庫可用；集群當(dāng)前副本數(shù)：當(dāng)集群的副本數(shù)少于期望的容量副本數(shù)時(shí)，其不進(jìn)行切換，防止切換后，讀寫請求容量不足導(dǎo)致整個(gè)集群異常，以上集群拓?fù)渥兓兄呗钥膳渲谩?/p>

5 實(shí)例故障切換策略

5.1 實(shí)例狀態(tài)協(xié)調(diào)

拓?fù)鋷煸趩吸c(diǎn)切換過程中主要進(jìn)行拓?fù)湫畔⒋鎯蜖顟B(tài)協(xié)調(diào)，具體包括五種信息，分別是靜態(tài)節(jié)點(diǎn)信息，主庫存活標(biāo)識，單點(diǎn)切換標(biāo)識，又處于正常、切換、故障三種狀態(tài)，動態(tài)節(jié)點(diǎn)信息，拓?fù)湫畔ⅰ?/p>

5.2 例行切換流程

舊主庫設(shè)置只讀->所有從庫設(shè)置只讀，并且判斷是否完成同步，未完成數(shù)據(jù)同步則繼續(xù)等待，判斷的依據(jù)是根據(jù)事務(wù)編號與主庫的最大事務(wù)編號進(jìn)行比較判斷，事務(wù)日志格式采用的是ROW格式，如果同步完成則停掉與主庫的數(shù)據(jù)同步進(jìn)程->新主庫給所有從庫新增同步賬戶授權(quán)并設(shè)置可寫->動態(tài)修改代理配置文件->所有從庫建立到新主庫同步連接，如果有錯(cuò)誤應(yīng)從拓?fù)渲袆h除該從庫節(jié)點(diǎn)->完成切換。

5.3 主庫故障切換流程

所有從庫設(shè)置只讀，并檢查所有從庫的事務(wù)編號，從所有從庫的事務(wù)編號中找到最大值作為數(shù)據(jù)最多的從庫實(shí)例，并記錄該實(shí)例作為期望新主庫->補(bǔ)齊數(shù)據(jù)，所有從庫中其他從庫從數(shù)據(jù)最多的實(shí)例中同步數(shù)據(jù)，數(shù)據(jù)同步方法采用原生的主從同步方法，待所有從庫事務(wù)編號一致后，數(shù)據(jù)補(bǔ)齊步驟完成->選取數(shù)據(jù)庫量最多節(jié)點(diǎn)為主庫->動態(tài)修改代理配置文件->所有從庫建立到新主庫同步連接，如果有錯(cuò)誤應(yīng)從拓?fù)渲袆h除該從庫節(jié)點(diǎn)->完成切換。

5.4 故障切換過程中數(shù)據(jù)同步方案

保障數(shù)據(jù)不丟失是切換過程的首要任務(wù)，不同的數(shù)據(jù)庫實(shí)例獲取事務(wù)日志后回放事務(wù)日志的速度可能不盡相同，必須保障所有的從庫都能回放事務(wù)完成后再進(jìn)行新主庫的開寫，所有的從庫與新主庫的事務(wù)編號差異對比，通過事務(wù)編號比較，獲取到差異集合后，從庫獲取這些差異的事務(wù)編號所在的事務(wù)日志文件并回放，經(jīng)過多次切換的集群事務(wù)編號可能由多段字符串組成，這樣需要獲取到每段的事務(wù)編號對應(yīng)的事務(wù)日志進(jìn)行回放，如果新主庫的事務(wù)編號對應(yīng)的事務(wù)日志文件已經(jīng)由于過期而不存在了，則未回放完畢的從庫造成數(shù)據(jù)同步中斷，這時(shí)候會導(dǎo)致切換過程中斷無法繼續(xù)后續(xù)進(jìn)程，為了避免數(shù)據(jù)不一致默認(rèn)是不跳過這些差異事務(wù)的回放，而是通過在線拉取主庫數(shù)據(jù)副本，拉取的時(shí)間可能會導(dǎo)致切換時(shí)間變長，但保障了數(shù)據(jù)的一致性。

6 結(jié)語

本文提出并實(shí)現(xiàn)了輕量級CloudDB高可用方案，采用可配置的故障檢測策略和高可用故障切換策略，能夠保障在實(shí)例故障時(shí)，業(yè)務(wù)在無感知或者阻塞寫入極短的時(shí)間內(nèi)恢復(fù)業(yè)務(wù)的寫入操作，切換過程數(shù)據(jù)無丟失，整個(gè)流程均是可配置，能夠快速的適配多個(gè)場景，可以使用在單機(jī)房、同城雙活、異地容災(zāi)、兩地三中心等多個(gè)場景中，可以是小型私有云，公有云，也可以是混合云，在提供云計(jì)算服務(wù)的服務(wù)棧中，可以部署在客戶業(yè)務(wù)的服務(wù)中，也可以部署在系統(tǒng)支撐的服務(wù)中。