輕量級CloudDB實例的高可用實現方案

崔校郡

（對外經濟貿易大學統計學院，北京 100029）

0 引言

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

1 開源框架應對高可用需求遇到的問題

針對傳統架構的流量接入層故障，應用和管控程序是無狀態的，開源云計算框架識別與恢復較容易[3]，但無法根據容器內數據庫實例的狀態進行調度，狀態與調度策略需要因業務變化而定，這是開源框架無法通過標準協議解決的問題，而且容器內數據庫版本差異和狀態參數也不相同，因此對數據庫實例并不能簡單地容器故障轉移來實現高可用，開源云計算框架應對數據庫高可用功能顯得力不從心。

2 高可用功能的設計目標

2.1 高可用實現的功能

首先確認高可用要解決的問題，當提供讀寫服務的實例發生故障時,其故障導致無法寫入，需快速對其進行處理，如果實例故障恢復環節由人工參與，由于故障的時間難預測，其故障發生時人員到位時間不可控，人工操作恢復時間較長，且受到數據庫實例個數的和人工切換熟練程度的限制，當數據不一致的時候，其直接影響到服務，或者即使切換程序由系統程序實現，但程序高可用切換策略不可調整，這些因素都直接影響到服務的可用性，尤其對于金融類業務來說影響更大，因此設計動態可配置可調整的高可用功能，自動化對主庫故障進行處理，快速適配不同環境業務場景需求。

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

2.2 設計的性能指標

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

3 高可用功能的架構設計

高可用管控功能主要由以下組件構成：

agent：其主要對服務器或者虛機、容器內的數據庫實例和數據庫代理實例進行托管，負責所托管實例的創建、監控數據采集，日志管理，定時任務處理，集群拓撲收斂；

zookeeper：拓撲庫，集群狀態協調者與單點切換協調，主要存儲單點切換的節點、拓撲相關的信息，包括節點靜態信息存儲：節點的網址、端口、切換權值、角色等配置、拓撲信息：集群主庫、從庫、備庫等，協調整個故障切換的狀態，對切換加鎖等，防止切換過程中出現臟信息，對節點的存活狀態信息進行監控；

haproxy：訪問代理用于應用連接拓撲時的網址配置，應用只需要連接一個網址，而不用關心數據庫拓撲具體網絡配置。

4 實例故障感知

4.1 單實例故障感知策略

主要對MySQL實例進行故障檢測，由agent進行，通過重試連接數過多，識別判斷機器壓力大，防止出現誤判；通過硬盤檢測，識別出硬件故障；

通過讀寫請求來識別數據庫壓力；判斷完畢實例故障后，根據實例角色觸發對應的處理流程，當單實例是從庫時，對寫并不造成影響，摘除該實例的讀服務，如果實例是主庫，則需要進行故障切換，故障感知策略可配置，所有配置均放置于拓撲庫中。

4.2 多實例集群故障感知

agent能對其托管的數據庫實例進行故障感知，但是當主庫機器自身異常時，其需要通過其他從庫實例的狀態來聯合判斷出主庫狀態，通過從庫的主從狀態來對集群的主庫存活進行判斷，如果所有從庫的主從狀態均異常，此時認為主庫狀態異常，進入單點切換流程，所有從庫主從狀態正常，此時需要進行二次判斷，從庫通過使用同步賬戶來重試連接主庫，如果均連接失敗，則認為主庫狀態異常，以上每個故障感知方法可以配置，每個環節的順序和環節數可以配置、調整。

4.3 集群拓撲故障感知

在上述聯合判斷出主庫故障后，仍然要根據前后故障感知和當前集群副本數來進行二次判斷，防止集群因為頻繁切換導致雪崩，或者因為容量不足導致集群切換后仍然無法使用的情況，該流程對整個集群的切換狀態進行二次判斷，其主要包括兩類：兩次切換時間間隔，防止因為網絡頻繁抖動，或者因為業務流量暴增導致主庫頻繁故障，此時如果頻繁進行切換，導致雪崩無主庫可用；集群當前副本數：當集群的副本數少于期望的容量副本數時，其不進行切換，防止切換后，讀寫請求容量不足導致整個集群異常，以上集群拓撲變化感知策略可配置。

5 實例故障切換策略

5.1 實例狀態協調

拓撲庫在單點切換過程中主要進行拓撲信息存儲和狀態協調，具體包括五種信息，分別是靜態節點信息，主庫存活標識，單點切換標識，又處于正常、切換、故障三種狀態，動態節點信息，拓撲信息。

5.2 例行切換流程

舊主庫設置只讀->所有從庫設置只讀，并且判斷是否完成同步，未完成數據同步則繼續等待，判斷的依據是根據事務編號與主庫的最大事務編號進行比較判斷，事務日志格式采用的是ROW格式，如果同步完成則停掉與主庫的數據同步進程->新主庫給所有從庫新增同步賬戶授權并設置可寫->動態修改代理配置文件->所有從庫建立到新主庫同步連接，如果有錯誤應從拓撲中刪除該從庫節點->完成切換。

5.3 主庫故障切換流程

所有從庫設置只讀，并檢查所有從庫的事務編號，從所有從庫的事務編號中找到最大值作為數據最多的從庫實例，并記錄該實例作為期望新主庫->補齊數據，所有從庫中其他從庫從數據最多的實例中同步數據，數據同步方法采用原生的主從同步方法，待所有從庫事務編號一致后，數據補齊步驟完成->選取數據庫量最多節點為主庫->動態修改代理配置文件->所有從庫建立到新主庫同步連接，如果有錯誤應從拓撲中刪除該從庫節點->完成切換。

5.4 故障切換過程中數據同步方案

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

6 結語

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