云原生下，如何實現高可用的MySQL？
MySQL 作為當前比較受歡迎的關系型數據庫(RDS)，在云原生浪潮中仍然面臨諸多挑戰。如何用 Cloud Native 的設計原則，通過沙箱隔離、計算和數據的完全分離，實現低成本、可擴展、高可用的 Cloud RDS 方案?阿里云數據庫團隊的姜杉彪(孟宇)同學將介紹一種云原生分布式 MySQL 高可用數據庫方案，分享其中的關鍵技術，并對云原生場景下傳統數據庫的發展趨勢做簡要分析。
云時代的到來，無論傳統行業還是互聯網行業，業務越來越多樣，迭代速度越來越快，使得整體數據量大幅提升。
近兩年，隨著 Docker + Kubernetes 等技術的興起，大家都將業務往容器化遷移，團隊的技術也在往云原生方向演進。早期的 Kubernetes 著重解決 Stateless 和 Share Nothing 的應用部署場景，然而在如今愈發復雜的應用場景中經常會遇到有狀態保存的需求。
從 Kubernetes 1.9 開始，針對有狀態服務的資源類型 Statefulset 進入 GA，而且 Kubernetes 1.14 版本 Local Volume、CSI 等存儲功能也進入 GA 階段，Kubernetes 對有狀態服務的支持得到全面加強，這使得很多數據存儲型基礎中間件往 Kubernetes 遷移成為可能。
MySQL 作為當前比較受歡迎的開源關系型數據庫(RDS)，集可靠、易用、功能豐富、適用范圍廣等特點于一身，使其成為關系型數據庫的主要選擇。雖然備受關注，但 MySQL 在云原生浪潮中卻也面臨著諸多挑戰。如何用 Cloud Native 的設計原則，通過沙箱隔離、計算和數據的完全分離，實現低成本、可擴展、高可用的 Cloud RDS 方案?
本文介紹一種云原生分布式 MySQL 高可用數據庫方案(下稱“SlightShift MySQL 高可用方案”)，并對云原生場景下傳統數據庫的發展趨勢做簡要分析。
?? 
一 需求&挑戰
在考慮云原生場景下的 MySQL 高可用架構時，主要有如下幾個方面的挑戰：
- 故障轉移：主庫發生宕機時，集群能夠自動選主并快速轉移故障，且轉移前后數據一致。
- 敏捷彈性伸縮：基于副本的彈性橫向擴展，擴縮容過程不中斷業務訪問。
- 數據安全性：數據定時冷備/實時熱備，以便故障恢復和數據遷移。
- 數據強一致性：用作備份/只讀副本的Slave節點數據應該和主節點數據保持實時或半實時一致。
二 目標&關鍵考慮點
SlightShift MySQL 高可用方案要達到的目標：
- SLA保障：一年內可接受最高 52.56 分鐘服務不可用(99.99%)。
- 故障轉移：主庫出現異常時主從切換耗時 < 2min。
- 彈性擴展：從庫理論可無限擴展，擴展從庫耗時 < 2min。
- 冷備恢復：MySQL集群出現不可恢復性問題時，從冷備恢復耗時 < 10min。
除以上目標外，在技術架構設計時還需重點考慮以下關鍵點：
- 高可用
- 應用接入成本
- 資源占用量
- 可擴展性
- 可維護性
三 架構設計
該 MySQL 高可用方案使用一主多從的復制結構，主從數據復制采用半同步復制，保證了數據一致性和讀寫效率，理論上從庫可無限擴展。
?? 
在數據引擎上層添加了仲裁器，使用 Raft 分布式一致性算法實現自動化選主和故障切換。
路由層使用 ProxySQL 作為 SQL 請求代理，能夠實現讀寫分離、負載均衡和動態配置探測。
監控告警方面，采用 Prometheus-Operator 方案實現整個 MySQL 高可用系統的資源監控告警。
運維管控方面，引入 Kubernetes Operator 的管控模型來實現 DB-Operator，能夠做到聲明式配置、集群狀態管理以及On Demand(按需創建)。另外，可以在 MySQL 控制臺上進行 MySQL 的基礎運維，例如：數據庫管理、表管理、SQL查詢，索引變更、配置變更、數據備份&恢復等。
四 關鍵技術
狀態持久化
容器技術誕生后，大家很快發現用它來封裝“無狀態應用”(Stateless Application)非常好用。但如果想要用容器運行“有狀態應用”，其困難程度就會直線上升。
對于 MySQL 等存儲型分布式應用，它的多個實例之間往往有依賴關系，比如：主從關系、主備關系。各個實例往往都會在本地磁盤上保存一份數據，當實例被殺掉，即便重建出來，實例與數據之間的對應關系也已經丟失，從而導致應用失敗。
這種實例之間有不對等關系，以及實例對外部數據有依賴關系的應用，被稱為“有狀態應用”(Stateful Application)。
Kubernetes 集群中使用節點本地存儲資源的方式有 emptyDir、hostPath、Local PV 等幾種方式。其中，emptyDir 無法持久化數據，hostPath 方式需要手動管理卷的生命周期，運維壓力大。
因此在MySQL場景中，出于性能和運維成本考慮需要使用本地存儲，Local PV 是目前為止唯一的選擇。
?? 
Local PV 利用機器上的磁盤來存放業務需要持久化的數據，和遠端存儲類似，Pod 的數據和生命周期是互相獨立的，即使業務 Pod 被刪除，數據也不會丟失。
同時，和遠端存儲相比，本地存儲可以避免網絡 IO 開銷，擁有更高的讀寫性能，所以分布式文件系統和分布式數據庫這類對 IO 要求很高的應用非常適合本地存儲。
不同于其他類型的存儲，Local PV 本地存儲強依賴于節點。換言之，在調度 Pod 的時候還要考慮到這些 Local PV 對容量和拓撲域的要求。
MySQL 在使用 Local PV 時，主要用到兩個特性：延遲綁定機制和 volume topology-aware scheduling。延遲綁定機制可以讓 PVC 的綁定推遲到有 MySQL Pod 使用它并且完成調度后，而 volume topology-aware scheduling 則可以讓 Kubernetes 的調度器知道卷的拓撲約束，也就是這個存儲卷只能在特定的區域或節點上使用(訪問)，讓調度器在調度 Pod 的時候必須考慮這一限制條件。
另外，MySQL 使用的 Local PV 還需通過 nodeAffinity 將 Pod 調度到正確的 Node 上。
下面展示了 MySQL 使用 Local PV 的簡單配置示例：
以上是 Local PV 的基礎用法，而 MySQL 還需考慮節點的彈性伸縮，這就要求底層存儲也能夠隨著 MySQL 實例伸縮來動態配置。這里提出兩種解決方案：
在 Kubernetes 集群中引入 LVM Manager，以 DaemonSet 形式運行，負責管理每個節點上的磁盤，匯報節點磁盤容量和剩余容量、動態創建 PV 等;再引入 local storage scheduler 調度模塊，負責為使用本地存儲的 Pod 選擇合適(有足夠容量)的節點。
使用開源方案 OpenEBS：iSCSI 提供底層存儲功能，OpenEBS 管理 iSCSI(目前只支持PV的 ReadWriteOnce 訪問模式)。
自動化選主
SlightShift MySQL 高可用架構基于 Raft 強一致協議實現分布式 MySQL 自動化選主。
?? 
Raft 使用心跳來觸發選主，當 MySQL Server 啟動時狀態是 follower。當 server 從 leader 或者 candidate 接收到合法的RPC時，它會保持在 follower 狀態，leader 會發送周期性的心跳來表明自己是 leader。
當一個 follower 在 election timeout 時間內沒有接收到通信，那么它會開始選主。
選主的步驟如下：
- 增加 current term。
- 轉成 candidate 狀態。
- 選自己為主，然后把選主RPC并行地發送給其他的 server。
- candidate 狀態會繼續保持，直到下述三種情況出現。
candidate 會在下述三種情況下退出：
- server 本身成為 leader。
- 其他的 server 選為 leader。
- 一段時間后，沒有 server 成為 leader。
故障轉移
在正常運行的主從復制環境中，故障轉移(Failover)模塊會監聽集群狀態，當 Master 發生故障時會自動觸發故障轉移。
故障轉移的第一步是自動化選主，自動化選主的邏輯在上面已介紹過;其次是數據一致性保障，需最大化保證 Dead Master的 數據被同步到 New Master。
?? 
在將 Master 切換到 New Master 之前，部分 slave 可能還未接收到最新的 relay log events，故障轉移模塊也會從最新的 slave 自動識別差異的 relay log events，并 apply 差異的 event 到其他 slaves，以此保證所有 slave 的數據都是一致的。
關于代理層，ProxySQL 會實時探測 MySQL 實例的可讀寫配置，當 MySQL 實例的可讀寫配置發生變化時，ProxySQL 會自動調整MySQL 實例的讀寫分組配置，最終保證在 Failover 之后讀寫分離能正確運行。
?? 
SlightShift MySQL 自動故障轉移的步驟如下：
- HA-Manager 偵測到 Master Server 連接異常，啟動 Failover。
- 嘗試關閉 Dead Master 以避免腦裂(此步驟可選)。
- 獲取最新數據 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秒監測到主機故障，5-10秒 apply 差異 relay logs，然后注冊到新的 master，通常10-30秒即可 total downtime。另外，可在配置文件里配置各個 slave 當選為 New Master 的優先級，這在多機房部署 MySQL 場景下很實用。
故障自動恢復
宕機的 Master 節點恢復時：
- 如果恢復的節點重新創建 Mysql Pod 并加入集群，Sentinel 會配置新 Pod 為 Slave，通過獲取當前 Master Mysql 的 log file 和 Position 來實現新加入 Slave 的數據同步。
- 如果恢復的節點中 Mysql Pod 依然存在且可用，Sentinel 此時會發現2個 Label 為 master 的 Pod。Sentinel 會依然使用宕機期間選擇的新 Master，且把恢復的 Master 強制設置為Slave，并開啟只讀模式。
宕機的 Slave 節點恢復時：
- 如果恢復節點重新創建 Mysql Pod 并加入集群，Sentinel會配置新 Pod 為Slave，通過獲取當前 Master Mysql 的 log file 和 Position 來實現新加入 Slave 的數據同步。
- 如果恢復的節點中 Mysql Pod 依然存在且可用，調度器不會執行操作，proxysql-service 會監測到新加入的 Slave，并將其加入到 endpoints 列表。
狀態管理
狀態管理并非新鮮話題，它為中心化系統分發一致的狀態，確保分布式系統總是朝預期的狀態收斂，是中心化系統的基石之一 。
MySQL 服務由一個 Master 節點和多個從 Master 上異步復制數據的 Slave 節點組成，即一主多從復制模型。其中，Master 節點可用來處理用戶的讀寫請求，Slave 節點只能用來處理用戶的讀請求。
為了部署這樣的有狀態服務，除了 StatefulSet 之外，還需要使用許多其它類型的 k8s 資源對象，包括 ConfigMap、Headless Service、ClusterIP Service 等。正是它們間的相互配合，才能讓 MySQL 這樣的有狀態服務有條件運行在 k8s 之上。
在 MySQL 集群中，狀態轉移最常發生在 Master 發生故障，集群進行故障轉移期間。當 Master 發生故障宕機時會自動觸發選主邏輯，選主結束后會進行故障切換，直至 New Master 正常提供讀寫服務，故障轉移過程是需要時間的，在故障轉移過程中 MySQL 服務會處于不可寫狀態。
在故障轉移期間，Dead Master 實例會被 k8s 集群自動拉起，Dead Master 被拉起后會認為自己是合法的 Master，這樣會造成集群中同時存在兩個 Master，寫請求很可能會被隨機分配到兩個 Master 節點，從而造成腦裂問題。
為了解決這種場景下的腦裂問題，我們引入了 InitContainer 機制，再配合 Sentinel 就能很好的解決該問題。
InitContainer，顧名思義，在容器啟動的時候會先啟動一個或多個容器去完成一些前置性工作，如果有多個，Init Container將按照指定的順序依次執行，只有所有的 InitContainer 執行完后主容器才會啟動。
我們在每一個 MySQL 的實例中都加入了 InitContainer，在 Dead Master 被 k8s 自動拉起之后，InitContainer 會自動檢測集群中是否處于 Failover 階段，如果處于Failover 階段會進入 Sleep 輪詢狀態，直至 Failover 結束。
?? 
當 Failover 結束后，Sentinel 檢測到 Dead Master 被拉起，會自動將 Dead Master 設置為 New Master 的 Slave 節點，以此來完成一次完整的 Failover 過程，并避免集群出現腦裂問題。
聲明式運維
我們在使用 k8s 時，一般會通過 k8s 的 Resource 滿足應用管理的需求：
- 通過 Deployment、StatefulSet 等 workload 部署服務。
- 通過 Service、Ingress 管理對服務的訪問。
- 通過 ConfigMap、Secrets 管理服務的配置。
- etc.
上述 Resource 表征 User 的期望，kube-controller-mananger 中的 Controller 會監聽 Resource Events 并執行相應的動作，來實現 User 的期望。
這種操作方式給應用管理帶來了很大的便利，User 可以通過聲明式的方式管理應用，不用再關心如何使用傳統的 HTTP API、RPC 調用等。
Controller 會通過各種機制來確保實現 User 的期望，如通過不斷檢測 Object 的狀態來驅使 Object 當前狀態符合用戶期望，這種運維模式我們稱之為聲明式運維。
但如果僅僅使用 k8s 提供的基礎類型，對于 MySQL 這類復雜應用來說運維成本依然很高。如果能將聲明式運維的模式進行擴展延伸到 MySQL 應用，會極大程度降低 MySQL 應用的部署和運維成本。
?? 
為了解決這個問題，slightshift-mysql-operator 應運而生。
slightshift-mysql-operator 本質上是 Resource + Controller：
- Resource
- 自定義資源(CRD, Custom Resource Definitions)，為 User 提供一種聲明式的方式描述對服務的期望。
- Controller
實現 Resource 中 User 的期望。
- slightshift-mysql-operator 通過組合 k8s 中已有的概念，極大降低了部署和運維 MySQL 的成本：
User 通過類似使用 Deployment 的方式描述對 MySQL 的需求
在 k8s 上部署 MySQL 應用的姿勢與 k8s 官方資源的操作方式相同。
由 slightshift-mysql-operator 的 Controller 監聽、處理事件請求
- 監聽 Resource Events。
- 針對不同類型 (ADD/UPDATE/DELETE) 的 Events 執行相應的動作。
- 不斷檢測 Object 的狀態來執行動作，驅使服務的狀態符合 User 期望。
?? 
slightshift-mysql-operator 的設計理念：
- 聲明式配置：提升可讀性和運維效率，降低運維成本。
- 最終一致性：動態調整集群狀態實現最終一致性。
?? 
slightshift-mysql-operator 極大程度上降低了在 Kubernetes 集群中使用和管理 MySQL 應用的成本，User 可以通過聲明式的 CR 創建應用，Vendor 可將管理應用的專業知識封裝，對 User 透明。
slightshift-mysql-operator 在架構層面上使用分層設計，簡化了架構復雜度，同時盡可能降低了 MySQL 多個集群實例間相互干擾，實現各個實例的自治。
部署結構如下圖所示：
?? 
備份與恢復
為保證數據安全性，還需對數據進行定期備份，保證用戶數據在極端情況下(集群崩潰)時數據可恢復。
通過 Cronjob 對 Mysql 數據進行備份：
- 在 Kubernetes 集群中創建 Cronjob，Cronjob 會定期進行數據備份。
- 備份數據會被打上時間標簽，并上傳到對象存儲服務器(Ceph、Minio)。
通過創建 Job 對 Mysql 進行數據恢復：
- 在集群中創建恢復 Job，Job 根據 SNAP_SHOT 到存儲服務器(OSS、Minio)上獲取備份數據。
- Job 把數據恢復到 Mysql Master 實例，同時 Slave 會完成數據同步。
五 技術演進
唯有進化，才能站到食物鏈頂端。
根據 Gartner 報告預測，數據庫云平臺市場份額將會在下一個五年中翻倍，而70%的用戶將開始使用 dbPaaS 數據庫云平臺。因此，為了滿足各類應用程序對數據庫云平臺的需求，同時為了減少私有云部署中對大量不同類型數據存儲產品的運維復雜性，數據庫的架構演進將是未來十年數據庫轉型的主要方向之一。
云原生數據庫是未來數據庫發展的一個重要方向，云原生數據庫架構隨著云化要求也需要進行相應的迭代，未來在云原生數據庫架構的演進還會隨著需求的變化而持續發展。
?? 
六 未來展望
中間件作為構筑上層業務系統的基石和核心技術，具有高可靠性、高擴展性、強專業性等特點。
關于未來，由于中間件的這些特點，未來云原生中間件會向著規范化、構建化、松耦合和平臺化的方向發展。平臺化能夠更快速響應業務變化，為業務的橫向發展提供集中的技術解決方案。
?? 
從終態來看，我們想做一個企業級云原生中間件 PaaS 平臺，涵蓋基礎中間件的部署、配置、升級、伸縮、故障處理等自動化能力。
首先談談我對中間件平臺的理解，中間件平臺應該是一系列中間件解決方案集合的能力開放式技術中臺，它形成了完整、久經考驗、開放和組件化的解決方案，旨在為復雜多變的上層業務領域提供穩定可靠的計算、存儲服務。
任何一個平臺型產品的發展歷程，都不是一開始就做平臺的，而是先有業務需求，為了解決實際業務需求而積累了某些領域的知識，進而成為了這些領域的專家，最終再向平臺轉變。換句話說，平臺是一個持續積累的過程，也是一個水到渠成的過程。
?? 
在企業信息平臺構建過程中，有效、合理、規范化的利用中間件平臺來快速構建上層業務系統，可以為企業及時響應需求變化提供有力保障，形成企業的集約化管理，進而提升企業核心力量獲得可持續競爭的優勢。
【本文為51CTO專欄作者“阿里巴巴官方技術”原創稿件，轉載請聯系原作者】
