云原生下，如何實現(xiàn)高可用的mysql？

作者：阿里技術 2020-09-01 13:13:59


云原生 MySQL 作為當前比較受歡迎的關系型數(shù)據庫(RDS)，在云原生浪潮中仍然面臨諸多挑戰(zhàn)。如何用 Cloud Native 的設計原則，通過沙箱隔離、計算和數(shù)據的完全分離，實現(xiàn)低成本、可擴展、高可用的 Cloud RDS 方案?

MySQL 作為當前比較受歡迎的關系型數(shù)據庫(RDS)，在云原生浪潮中仍然面臨諸多挑戰(zhàn)。如何用 Cloud Native 的設計原則，通過沙箱隔離、計算和數(shù)據的完全分離，實現(xiàn)低成本、可擴展、高可用的 Cloud RDS 方案?阿里云數(shù)據庫團隊的姜杉彪(孟宇)同學將介紹一種云原生分布式 MySQL 高可用數(shù)據庫方案，分享其中的關鍵技術，并對云原生場景下傳統(tǒng)數(shù)據庫的發(fā)展趨勢做簡要分析。

云時代的到來，無論傳統(tǒng)行業(yè)還是互聯(lián)網行業(yè)，業(yè)務越來越多樣，迭代速度越來越快，使得整體數(shù)據量大幅提升。

近兩年，隨著 Docker + Kubernetes 等技術的興起，大家都將業(yè)務往容器化遷移，團隊的技術也在往云原生方向演進。早期的 Kubernetes 著重解決 Stateless 和 Share Nothing 的應用部署場景，然而在如今愈發(fā)復雜的應用場景中經常會遇到有狀態(tài)保存的需求。

從 Kubernetes 1.9 開始，針對有狀態(tài)服務的資源類型 Statefulset 進入 GA，而且 Kubernetes 1.14 版本 Local Volume、CSI 等存儲功能也進入 GA 階段，Kubernetes 對有狀態(tài)服務的支持得到全面加強，這使得很多數(shù)據存儲型基礎中間件往 Kubernetes 遷移成為可能。

MySQL 作為當前比較受歡迎的開源關系型數(shù)據庫(RDS)，集可靠、易用、功能豐富、適用范圍廣等特點于一身，使其成為關系型數(shù)據庫的主要選擇。雖然備受關注，但 MySQL 在云原生浪潮中卻也面臨著諸多挑戰(zhàn)。如何用 Cloud Native 的設計原則，通過沙箱隔離、計算和數(shù)據的完全分離，實現(xiàn)低成本、可擴展、高可用的 Cloud RDS 方案?

本文介紹一種云原生分布式 MySQL 高可用數(shù)據庫方案(下稱“SlightShift MySQL 高可用方案”)，并對云原生場景下傳統(tǒng)數(shù)據庫的發(fā)展趨勢做簡要分析。

??

??

一 需求&挑戰(zhàn)

在考慮云原生場景下的 MySQL 高可用架構時，主要有如下幾個方面的挑戰(zhàn)：

• 故障轉移：主庫發(fā)生宕機時，集群能夠自動選主并快速轉移故障，且轉移前后數(shù)據一致。
• 敏捷彈性伸縮：基于副本的彈性橫向擴展，擴縮容過程不中斷業(yè)務訪問。
• 數(shù)據安全性：數(shù)據定時冷備/實時熱備，以便故障恢復和數(shù)據遷移。
• 數(shù)據強一致性：用作備份/只讀副本的Slave節(jié)點數(shù)據應該和主節(jié)點數(shù)據保持實時或半實時一致。

二 目標&關鍵考慮點

SlightShift MySQL 高可用方案要達到的目標：

• SLA保障：一年內可接受最高 52.56 分鐘服務不可用(99.99%)。
• 故障轉移：主庫出現(xiàn)異常時主從切換耗時 < 2min。
• 彈性擴展：從庫理論可無限擴展，擴展從庫耗時 < 2min。
• 冷備恢復：MySQL集群出現(xiàn)不可恢復性問題時，從冷備恢復耗時 < 10min。

除以上目標外，在技術架構設計時還需重點考慮以下關鍵點：

• 高可用
• 應用接入成本
• 資源占用量
• 可擴展性
• 可維護性

三 架構設計

該 MySQL 高可用方案使用一主多從的復制結構，主從數(shù)據復制采用半同步復制，保證了數(shù)據一致性和讀寫效率，理論上從庫可無限擴展。

??

??

在數(shù)據引擎上層添加了仲裁器，使用 Raft 分布式一致性算法實現(xiàn)自動化選主和故障切換。

路由層使用 ProxySQL 作為 SQL 請求代理，能夠實現(xiàn)讀寫分離、負載均衡和動態(tài)配置探測。

監(jiān)控告警方面，采用 Prometheus-Operator 方案實現(xiàn)整個 MySQL 高可用系統(tǒng)的資源監(jiān)控告警。

運維管控方面，引入 Kubernetes Operator 的管控模型來實現(xiàn) DB-Operator，能夠做到聲明式配置、集群狀態(tài)管理以及On Demand(按需創(chuàng)建)。另外，可以在 MySQL 控制臺上進行 MySQL 的基礎運維，例如：數(shù)據庫管理、表管理、SQL查詢，索引變更、配置變更、數(shù)據備份&恢復等。

四 關鍵技術

狀態(tài)持久化

容器技術誕生后，大家很快發(fā)現(xiàn)用它來封裝“無狀態(tài)應用”(Stateless Application)非常好用。但如果想要用容器運行“有狀態(tài)應用”，其困難程度就會直線上升。

對于 MySQL 等存儲型分布式應用，它的多個實例之間往往有依賴關系，比如：主從關系、主備關系。各個實例往往都會在本地磁盤上保存一份數(shù)據，當實例被殺掉，即便重建出來，實例與數(shù)據之間的對應關系也已經丟失，從而導致應用失敗。

這種實例之間有不對等關系，以及實例對外部數(shù)據有依賴關系的應用，被稱為“有狀態(tài)應用”(Stateful Application)。

Kubernetes 集群中使用節(jié)點本地存儲資源的方式有 emptyDir、hostPath、Local PV 等幾種方式。其中，emptyDir 無法持久化數(shù)據，hostPath 方式需要手動管理卷的生命周期，運維壓力大。

因此在MySQL場景中，出于性能和運維成本考慮需要使用本地存儲，Local PV 是目前為止唯一的選擇。

??

??

Local PV 利用機器上的磁盤來存放業(yè)務需要持久化的數(shù)據，和遠端存儲類似，Pod 的數(shù)據和生命周期是互相獨立的，即使業(yè)務 Pod 被刪除，數(shù)據也不會丟失。

同時，和遠端存儲相比，本地存儲可以避免網絡 IO 開銷，擁有更高的讀寫性能，所以分布式文件系統(tǒng)和分布式數(shù)據庫這類對 IO 要求很高的應用非常適合本地存儲。

不同于其他類型的存儲，Local PV 本地存儲強依賴于節(jié)點。換言之，在調度 Pod 的時候還要考慮到這些 Local PV 對容量和拓撲域的要求。

MySQL 在使用 Local PV 時，主要用到兩個特性：延遲綁定機制和 volume topology-aware scheduling。延遲綁定機制可以讓 PVC 的綁定推遲到有 MySQL Pod 使用它并且完成調度后，而 volume topology-aware scheduling 則可以讓 Kubernetes 的調度器知道卷的拓撲約束，也就是這個存儲卷只能在特定的區(qū)域或節(jié)點上使用(訪問)，讓調度器在調度 Pod 的時候必須考慮這一限制條件。

另外，MySQL 使用的 Local PV 還需通過 nodeAffinity 將 Pod 調度到正確的 Node 上。

下面展示了 MySQL 使用 Local PV 的簡單配置示例：

--- 
 apiVersion: storage.k8s.io/v1 
 kind: StorageClass 
 metadata: 
   creationTimestamp: null 
   name: local-storage 
 provisioner: kubernetes.io/no-provisioner 
 reclaimPolicy: Delete 
 --- 
 apiVersion: v1 
 kind: PersistentVolumeClaim 
 metadata: 
   annotations: 
     pv.kubernetes.io/bound-by-controller: "yes" 
   creationTimestamp: null 
   labels: 
     app: slightshift-mysql 
     mysql-node: "true" 
   name: data-slightshift-mysql-0 
 spec: 
   accessModes: 
   - ReadWriteOnce 
   resources: 
     requests: 
       storage: 10Gi 
   storageClassName: local-volume-storage 
   volumeName: mysqlha-local-pv-0 
 --- 
 apiVersion: v1 
 kind: PersistentVolume 
 metadata: 
   annotations: 
     helm.sh/hook: pre-install,pre-upgrade 
     helm.sh/resource-policy: keep 
     volume.alpha.kubernetes.io/node-affinity: '{ "requiredDuringSchedulingIgnoredDuringExecution": 
       { "nodeSelectorTerms": [ { "matchExpressions": [ { "key": "kubernetes.io/hostname", 
       "operator": "In", "values": ["yz2-worker004"] } ]} ]} }' 
   labels: 
     pv-label: slightshift-mysql-data-pv 
     type: local 
   name: slightshift-mysql-data-pv-0 
 spec: 
   accessModes: 
   - ReadWriteOnce 
   capacity: 
     storage: 500Gi 
   local: 
     path: /var/lib/ali/mysql 
   persistentVolumeReclaimPolicy: Retain 
   storageClassName: pxc-mysql-data

以上是 Local PV 的基礎用法，而 MySQL 還需考慮節(jié)點的彈性伸縮，這就要求底層存儲也能夠隨著 MySQL 實例伸縮來動態(tài)配置。這里提出兩種解決方案：

在 Kubernetes 集群中引入 LVM Manager，以 DaemonSet 形式運行，負責管理每個節(jié)點上的磁盤，匯報節(jié)點磁盤容量和剩余容量、動態(tài)創(chuàng)建 PV 等;再引入 local storage scheduler 調度模塊，負責為使用本地存儲的 Pod 選擇合適(有足夠容量)的節(jié)點。

使用開源方案 OpenEBS：iSCSI 提供底層存儲功能，OpenEBS 管理 iSCSI(目前只支持PV的 ReadWriteOnce 訪問模式)。

自動化選主

SlightShift MySQL 高可用架構基于 Raft 強一致協(xié)議實現(xiàn)分布式 MySQL 自動化選主。

??

??

Raft 使用心跳來觸發(fā)選主，當 MySQL Server 啟動時狀態(tài)是 follower。當 server 從 leader 或者 candidate 接收到合法的RPC時，它會保持在 follower 狀態(tài)，leader 會發(fā)送周期性的心跳來表明自己是 leader。

當一個 follower 在 election timeout 時間內沒有接收到通信，那么它會開始選主。

選主的步驟如下：

• 增加 current term。
• 轉成 candidate 狀態(tài)。
• 選自己為主，然后把選主RPC并行地發(fā)送給其他的 server。
• candidate 狀態(tài)會繼續(xù)保持，直到下述三種情況出現(xiàn)。

candidate 會在下述三種情況下退出：

• server 本身成為 leader。
• 其他的 server 選為 leader。
• 一段時間后，沒有 server 成為 leader。

故障轉移

在正常運行的主從復制環(huán)境中，故障轉移(Failover)模塊會監(jiān)聽集群狀態(tài)，當 Master 發(fā)生故障時會自動觸發(fā)故障轉移。

故障轉移的第一步是自動化選主，自動化選主的邏輯在上面已介紹過;其次是數(shù)據一致性保障，需最大化保證 Dead Master的 數(shù)據被同步到 New Master。

??

??

在將 Master 切換到 New Master 之前，部分 slave 可能還未接收到最新的 relay log events，故障轉移模塊也會從最新的 slave 自動識別差異的 relay log events，并 apply 差異的 event 到其他 slaves，以此保證所有 slave 的數(shù)據都是一致的。

關于代理層，ProxySQL 會實時探測 MySQL 實例的可讀寫配置，當 MySQL 實例的可讀寫配置發(fā)生變化時，ProxySQL 會自動調整MySQL 實例的讀寫分組配置，最終保證在 Failover 之后讀寫分離能正確運行。

??

??

SlightShift MySQL 自動故障轉移的步驟如下：

• HA-Manager 偵測到 Master Server 連接異常，啟動 Failover。
• 嘗試關閉 Dead Master 以避免腦裂(此步驟可選)。
• 獲取最新數(shù)據 slave 的 end_log_pos，并從 Dead Master 同步 bin-log，最終保證所有 slave 的 end_log_pos 一致。
• 使用 raft 分布式算法選舉 New Master。
• 將 Master 切換到 New Master。
• 回調 ProxySQL 代碼服務，剔除 Dead Master 配置。
• ProxySQL 網關檢測到各個 MySQL 實例的可讀寫配置變化，調整讀寫分離配置。
• 通知切換結果(郵件、釘釘群機器人)。

SlightShift MySQL 能做到秒級故障轉移，5-10秒監(jiān)測到主機故障，5-10秒 apply 差異 relay logs，然后注冊到新的 master，通常10-30秒即可 total downtime。另外，可在配置文件里配置各個 slave 當選為 New Master 的優(yōu)先級，這在多機房部署 MySQL 場景下很實用。

故障自動恢復

宕機的 Master 節(jié)點恢復時：

• 如果恢復的節(jié)點重新創(chuàng)建 Mysql Pod 并加入集群，Sentinel 會配置新 Pod 為 Slave，通過獲取當前 Master Mysql 的 log file 和 Position 來實現(xiàn)新加入 Slave 的數(shù)據同步。
• 如果恢復的節(jié)點中 Mysql Pod 依然存在且可用，Sentinel 此時會發(fā)現(xiàn)2個 Label 為 master 的 Pod。Sentinel 會依然使用宕機期間選擇的新 Master，且把恢復的 Master 強制設置為Slave，并開啟只讀模式。

宕機的 Slave 節(jié)點恢復時：

• 如果恢復節(jié)點重新創(chuàng)建 Mysql Pod 并加入集群，Sentinel會配置新 Pod 為Slave，通過獲取當前 Master Mysql 的 log file 和 Position 來實現(xiàn)新加入 Slave 的數(shù)據同步。
• 如果恢復的節(jié)點中 Mysql Pod 依然存在且可用，調度器不會執(zhí)行操作，proxysql-service 會監(jiān)測到新加入的 Slave，并將其加入到 endpoints 列表。

狀態(tài)管理

狀態(tài)管理并非新鮮話題，它為中心化系統(tǒng)分發(fā)一致的狀態(tài)，確保分布式系統(tǒng)總是朝預期的狀態(tài)收斂，是中心化系統(tǒng)的基石之一 。

MySQL 服務由一個 Master 節(jié)點和多個從 Master 上異步復制數(shù)據的 Slave 節(jié)點組成，即一主多從復制模型。其中，Master 節(jié)點可用來處理用戶的讀寫請求，Slave 節(jié)點只能用來處理用戶的讀請求。

為了部署這樣的有狀態(tài)服務，除了 StatefulSet 之外，還需要使用許多其它類型的 k8s 資源對象，包括 ConfigMap、Headless Service、ClusterIP Service 等。正是它們間的相互配合，才能讓 MySQL 這樣的有狀態(tài)服務有條件運行在 k8s 之上。

在 MySQL 集群中，狀態(tài)轉移最常發(fā)生在 Master 發(fā)生故障，集群進行故障轉移期間。當 Master 發(fā)生故障宕機時會自動觸發(fā)選主邏輯，選主結束后會進行故障切換，直至 New Master 正常提供讀寫服務，故障轉移過程是需要時間的，在故障轉移過程中 MySQL 服務會處于不可寫狀態(tài)。

在故障轉移期間，Dead Master 實例會被 k8s 集群自動拉起，Dead Master 被拉起后會認為自己是合法的 Master，這樣會造成集群中同時存在兩個 Master，寫請求很可能會被隨機分配到兩個 Master 節(jié)點，從而造成腦裂問題。

為了解決這種場景下的腦裂問題，我們引入了 InitContainer 機制，再配合 Sentinel 就能很好的解決該問題。

InitContainer，顧名思義，在容器啟動的時候會先啟動一個或多個容器去完成一些前置性工作，如果有多個，Init Container將按照指定的順序依次執(zhí)行，只有所有的 InitContainer 執(zhí)行完后主容器才會啟動。

我們在每一個 MySQL 的實例中都加入了 InitContainer，在 Dead Master 被 k8s 自動拉起之后，InitContainer 會自動檢測集群中是否處于 Failover 階段，如果處于Failover 階段會進入 Sleep 輪詢狀態(tài)，直至 Failover 結束。

??

??

當 Failover 結束后，Sentinel 檢測到 Dead Master 被拉起，會自動將 Dead Master 設置為 New Master 的 Slave 節(jié)點，以此來完成一次完整的 Failover 過程，并避免集群出現(xiàn)腦裂問題。

聲明式運維

我們在使用 k8s 時，一般會通過 k8s 的 Resource 滿足應用管理的需求：

• 通過 Deployment、StatefulSet 等 workload 部署服務。
• 通過 Service、Ingress 管理對服務的訪問。
• 通過 ConfigMap、Secrets 管理服務的配置。
• etc.

上述 Resource 表征 User 的期望，kube-controller-mananger 中的 Controller 會監(jiān)聽 Resource Events 并執(zhí)行相應的動作，來實現(xiàn) User 的期望。

這種操作方式給應用管理帶來了很大的便利，User 可以通過聲明式的方式管理應用，不用再關心如何使用傳統(tǒng)的 HTTP API、RPC 調用等。

Controller 會通過各種機制來確保實現(xiàn) User 的期望，如通過不斷檢測 Object 的狀態(tài)來驅使 Object 當前狀態(tài)符合用戶期望，這種運維模式我們稱之為聲明式運維。

但如果僅僅使用 k8s 提供的基礎類型，對于 MySQL 這類復雜應用來說運維成本依然很高。如果能將聲明式運維的模式進行擴展延伸到 MySQL 應用，會極大程度降低 MySQL 應用的部署和運維成本。

??

??

為了解決這個問題，slightshift-mysql-operator 應運而生。

slightshift-mysql-operator 本質上是 Resource + Controller：

• Resource

• 自定義資源(CRD, Custom Resource Definitions)，為 User 提供一種聲明式的方式描述對服務的期望。

• Controller

實現(xiàn) Resource 中 User 的期望。

• slightshift-mysql-operator 通過組合 k8s 中已有的概念，極大降低了部署和運維 MySQL 的成本：

User 通過類似使用 Deployment 的方式描述對 MySQL 的需求

在 k8s 上部署 MySQL 應用的姿勢與 k8s 官方資源的操作方式相同。

由 slightshift-mysql-operator 的 Controller 監(jiān)聽、處理事件請求

• 監(jiān)聽 Resource Events。
• 針對不同類型 (ADD/UPDATE/DELETE) 的 Events 執(zhí)行相應的動作。
• 不斷檢測 Object 的狀態(tài)來執(zhí)行動作，驅使服務的狀態(tài)符合 User 期望。

??

??

slightshift-mysql-operator 的設計理念：

• 聲明式配置：提升可讀性和運維效率，降低運維成本。
• 最終一致性：動態(tài)調整集群狀態(tài)實現(xiàn)最終一致性。

??

??

slightshift-mysql-operator 極大程度上降低了在 Kubernetes 集群中使用和管理 MySQL 應用的成本，User 可以通過聲明式的 CR 創(chuàng)建應用，Vendor 可將管理應用的專業(yè)知識封裝，對 User 透明。

slightshift-mysql-operator 在架構層面上使用分層設計，簡化了架構復雜度，同時盡可能降低了 MySQL 多個集群實例間相互干擾，實現(xiàn)各個實例的自治。

部署結構如下圖所示：

??

??

備份與恢復

為保證數(shù)據安全性，還需對數(shù)據進行定期備份，保證用戶數(shù)據在極端情況下(集群崩潰)時數(shù)據可恢復。

通過 Cronjob 對 Mysql 數(shù)據進行備份：

• 在 Kubernetes 集群中創(chuàng)建 Cronjob，Cronjob 會定期進行數(shù)據備份。
• 備份數(shù)據會被打上時間標簽，并上傳到對象存儲服務器(Ceph、Minio)。

通過創(chuàng)建 Job 對 Mysql 進行數(shù)據恢復：

• 在集群中創(chuàng)建恢復 Job，Job 根據 SNAP_SHOT 到存儲服務器(OSS、Minio)上獲取備份數(shù)據。
• Job 把數(shù)據恢復到 Mysql Master 實例，同時 Slave 會完成數(shù)據同步。

五 技術演進

唯有進化，才能站到食物鏈頂端。

根據 Gartner 報告預測，數(shù)據庫云平臺市場份額將會在下一個五年中翻倍，而70%的用戶將開始使用 dbPaaS 數(shù)據庫云平臺。因此，為了滿足各類應用程序對數(shù)據庫云平臺的需求，同時為了減少私有云部署中對大量不同類型數(shù)據存儲產品的運維復雜性，數(shù)據庫的架構演進將是未來十年數(shù)據庫轉型的主要方向之一。

云原生數(shù)據庫是未來數(shù)據庫發(fā)展的一個重要方向，云原生數(shù)據庫架構隨著云化要求也需要進行相應的迭代，未來在云原生數(shù)據庫架構的演進還會隨著需求的變化而持續(xù)發(fā)展。

??

??

六 未來展望

中間件作為構筑上層業(yè)務系統(tǒng)的基石和核心技術，具有高可靠性、高擴展性、強專業(yè)性等特點。

關于未來，由于中間件的這些特點，未來云原生中間件會向著規(guī)范化、構建化、松耦合和平臺化的方向發(fā)展。平臺化能夠更快速響應業(yè)務變化，為業(yè)務的橫向發(fā)展提供集中的技術解決方案。

??

??

從終態(tài)來看，我們想做一個企業(yè)級云原生中間件 PaaS 平臺，涵蓋基礎中間件的部署、配置、升級、伸縮、故障處理等自動化能力。

首先談談我對中間件平臺的理解，中間件平臺應該是一系列中間件解決方案集合的能力開放式技術中臺，它形成了完整、久經考驗、開放和組件化的解決方案，旨在為復雜多變的上層業(yè)務領域提供穩(wěn)定可靠的計算、存儲服務。

任何一個平臺型產品的發(fā)展歷程，都不是一開始就做平臺的，而是先有業(yè)務需求，為了解決實際業(yè)務需求而積累了某些領域的知識，進而成為了這些領域的專家，最終再向平臺轉變。換句話說，平臺是一個持續(xù)積累的過程，也是一個水到渠成的過程。

??

??

在企業(yè)信息平臺構建過程中，有效、合理、規(guī)范化的利用中間件平臺來快速構建上層業(yè)務系統(tǒng)，可以為企業(yè)及時響應需求變化提供有力保障，形成企業(yè)的集約化管理，進而提升企業(yè)核心力量獲得可持續(xù)競爭的優(yōu)勢。

【本文為51CTO專欄作者“阿里巴巴官方技術”原創(chuàng)稿件，轉載請聯(lián)系原作者】

??戳這里，看該作者更多好文??

本文標題：云原生下，如何實現(xiàn)高可用的MySQL？
本文地址：http://m.5511xx.com/article/dhiiegi.html