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

作者：阿里技術(shù) 2020-09-01 13:13:59


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

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

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

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

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

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

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

??

??

一 需求&挑戰(zhàn)

在考慮云原生場(chǎng)景下的 MySQL 高可用架構(gòu)時(shí)，主要有如下幾個(gè)方面的挑戰(zhàn)：

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

二 目標(biāo)&關(guān)鍵考慮點(diǎn)

SlightShift MySQL 高可用方案要達(dá)到的目標(biāo)：

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

除以上目標(biāo)外，在技術(shù)架構(gòu)設(shè)計(jì)時(shí)還需重點(diǎn)考慮以下關(guān)鍵點(diǎn)：

• 高可用
• 應(yīng)用接入成本
• 資源占用量
• 可擴(kuò)展性
• 可維護(hù)性

三 架構(gòu)設(shè)計(jì)

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

??

??

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

路由層使用 ProxySQL 作為 SQL 請(qǐng)求代理，能夠?qū)崿F(xiàn)讀寫分離、負(fù)載均衡和動(dòng)態(tài)配置探測(cè)。

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

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

四 關(guān)鍵技術(shù)

狀態(tài)持久化

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

對(duì)于 MySQL 等存儲(chǔ)型分布式應(yīng)用，它的多個(gè)實(shí)例之間往往有依賴關(guān)系，比如：主從關(guān)系、主備關(guān)系。各個(gè)實(shí)例往往都會(huì)在本地磁盤上保存一份數(shù)據(jù)，當(dāng)實(shí)例被殺掉，即便重建出來(lái)，實(shí)例與數(shù)據(jù)之間的對(duì)應(yīng)關(guān)系也已經(jīng)丟失，從而導(dǎo)致應(yīng)用失敗。

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

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

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

??

??

Local PV 利用機(jī)器上的磁盤來(lái)存放業(yè)務(wù)需要持久化的數(shù)據(jù)，和遠(yuǎn)端存儲(chǔ)類似，Pod 的數(shù)據(jù)和生命周期是互相獨(dú)立的，即使業(yè)務(wù) Pod 被刪除，數(shù)據(jù)也不會(huì)丟失。

同時(shí)，和遠(yuǎn)端存儲(chǔ)相比，本地存儲(chǔ)可以避免網(wǎng)絡(luò) IO 開(kāi)銷，擁有更高的讀寫性能，所以分布式文件系統(tǒng)和分布式數(shù)據(jù)庫(kù)這類對(duì) IO 要求很高的應(yīng)用非常適合本地存儲(chǔ)。

不同于其他類型的存儲(chǔ)，Local PV 本地存儲(chǔ)強(qiáng)依賴于節(jié)點(diǎn)。換言之，在調(diào)度 Pod 的時(shí)候還要考慮到這些 Local PV 對(duì)容量和拓?fù)溆虻囊蟆?/p>

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

另外，MySQL 使用的 Local PV 還需通過(guò) nodeAffinity 將 Pod 調(diào)度到正確的 Node 上。

下面展示了 MySQL 使用 Local PV 的簡(jiǎn)單配置示例：

--- 
 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 的基礎(chǔ)用法，而 MySQL 還需考慮節(jié)點(diǎn)的彈性伸縮，這就要求底層存儲(chǔ)也能夠隨著 MySQL 實(shí)例伸縮來(lái)動(dòng)態(tài)配置。這里提出兩種解決方案：

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

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

自動(dòng)化選主

SlightShift MySQL 高可用架構(gòu)基于 Raft 強(qiáng)一致協(xié)議實(shí)現(xiàn)分布式 MySQL 自動(dòng)化選主。

??

??

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

當(dāng)一個(gè) follower 在 election timeout 時(shí)間內(nèi)沒(méi)有接收到通信，那么它會(huì)開(kāi)始選主。

選主的步驟如下：

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

candidate 會(huì)在下述三種情況下退出：

• server 本身成為 leader。
• 其他的 server 選為 leader。
• 一段時(shí)間后，沒(méi)有 server 成為 leader。

故障轉(zhuǎn)移

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

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

??

??

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

關(guān)于代理層，ProxySQL 會(huì)實(shí)時(shí)探測(cè) MySQL 實(shí)例的可讀寫配置，當(dāng) MySQL 實(shí)例的可讀寫配置發(fā)生變化時(shí)，ProxySQL 會(huì)自動(dòng)調(diào)整MySQL 實(shí)例的讀寫分組配置，最終保證在 Failover 之后讀寫分離能正確運(yùn)行。

??

??

SlightShift MySQL 自動(dòng)故障轉(zhuǎn)移的步驟如下：

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

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

故障自動(dòng)恢復(fù)

宕機(jī)的 Master 節(jié)點(diǎn)恢復(fù)時(shí)：

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

宕機(jī)的 Slave 節(jié)點(diǎn)恢復(fù)時(shí)：

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

狀態(tài)管理

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

MySQL 服務(wù)由一個(gè) Master 節(jié)點(diǎn)和多個(gè)從 Master 上異步復(fù)制數(shù)據(jù)的 Slave 節(jié)點(diǎn)組成，即一主多從復(fù)制模型。其中，Master 節(jié)點(diǎn)可用來(lái)處理用戶的讀寫請(qǐng)求，Slave 節(jié)點(diǎn)只能用來(lái)處理用戶的讀請(qǐng)求。

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

在 MySQL 集群中，狀態(tài)轉(zhuǎn)移最常發(fā)生在 Master 發(fā)生故障，集群進(jìn)行故障轉(zhuǎn)移期間。當(dāng) Master 發(fā)生故障宕機(jī)時(shí)會(huì)自動(dòng)觸發(fā)選主邏輯，選主結(jié)束后會(huì)進(jìn)行故障切換，直至 New Master 正常提供讀寫服務(wù)，故障轉(zhuǎn)移過(guò)程是需要時(shí)間的，在故障轉(zhuǎn)移過(guò)程中 MySQL 服務(wù)會(huì)處于不可寫狀態(tài)。

在故障轉(zhuǎn)移期間，Dead Master 實(shí)例會(huì)被 k8s 集群自動(dòng)拉起，Dead Master 被拉起后會(huì)認(rèn)為自己是合法的 Master，這樣會(huì)造成集群中同時(shí)存在兩個(gè) Master，寫請(qǐng)求很可能會(huì)被隨機(jī)分配到兩個(gè) Master 節(jié)點(diǎn)，從而造成腦裂問(wèn)題。

為了解決這種場(chǎng)景下的腦裂問(wèn)題，我們引入了 InitContainer 機(jī)制，再配合 Sentinel 就能很好的解決該問(wèn)題。

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

我們?cè)诿恳粋€(gè) MySQL 的實(shí)例中都加入了 InitContainer，在 Dead Master 被 k8s 自動(dòng)拉起之后，InitContainer 會(huì)自動(dòng)檢測(cè)集群中是否處于 Failover 階段，如果處于Failover 階段會(huì)進(jìn)入 Sleep 輪詢狀態(tài)，直至 Failover 結(jié)束。

??

??

當(dāng) Failover 結(jié)束后，Sentinel 檢測(cè)到 Dead Master 被拉起，會(huì)自動(dòng)將 Dead Master 設(shè)置為 New Master 的 Slave 節(jié)點(diǎn)，以此來(lái)完成一次完整的 Failover 過(guò)程，并避免集群出現(xiàn)腦裂問(wèn)題。

聲明式運(yùn)維

我們?cè)谑褂?k8s 時(shí)，一般會(huì)通過(guò) k8s 的 Resource 滿足應(yīng)用管理的需求：

• 通過(guò) Deployment、StatefulSet 等 workload 部署服務(wù)。
• 通過(guò) Service、Ingress 管理對(duì)服務(wù)的訪問(wèn)。
• 通過(guò) ConfigMap、Secrets 管理服務(wù)的配置。
• etc.

上述 Resource 表征 User 的期望，kube-controller-mananger 中的 Controller 會(huì)監(jiān)聽(tīng) Resource Events 并執(zhí)行相應(yīng)的動(dòng)作，來(lái)實(shí)現(xiàn) User 的期望。

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

Controller 會(huì)通過(guò)各種機(jī)制來(lái)確保實(shí)現(xiàn) User 的期望，如通過(guò)不斷檢測(cè) Object 的狀態(tài)來(lái)驅(qū)使 Object 當(dāng)前狀態(tài)符合用戶期望，這種運(yùn)維模式我們稱之為聲明式運(yùn)維。

但如果僅僅使用 k8s 提供的基礎(chǔ)類型，對(duì)于 MySQL 這類復(fù)雜應(yīng)用來(lái)說(shuō)運(yùn)維成本依然很高。如果能將聲明式運(yùn)維的模式進(jìn)行擴(kuò)展延伸到 MySQL 應(yīng)用，會(huì)極大程度降低 MySQL 應(yīng)用的部署和運(yùn)維成本。

??

??

為了解決這個(gè)問(wèn)題，slightshift-mysql-operator 應(yīng)運(yùn)而生。

slightshift-mysql-operator 本質(zhì)上是 Resource + Controller：

• Resource

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

• Controller

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

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

User 通過(guò)類似使用 Deployment 的方式描述對(duì) MySQL 的需求

在 k8s 上部署 MySQL 應(yīng)用的姿勢(shì)與 k8s 官方資源的操作方式相同。

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

• 監(jiān)聽(tīng) Resource Events。
• 針對(duì)不同類型 (ADD/UPDATE/DELETE) 的 Events 執(zhí)行相應(yīng)的動(dòng)作。
• 不斷檢測(cè) Object 的狀態(tài)來(lái)執(zhí)行動(dòng)作，驅(qū)使服務(wù)的狀態(tài)符合 User 期望。

??

??

slightshift-mysql-operator 的設(shè)計(jì)理念：

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

??

??

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

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

部署結(jié)構(gòu)如下圖所示：

??

??

備份與恢復(fù)

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

通過(guò) Cronjob 對(duì) Mysql 數(shù)據(jù)進(jìn)行備份：

• 在 Kubernetes 集群中創(chuàng)建 Cronjob，Cronjob 會(huì)定期進(jìn)行數(shù)據(jù)備份。
• 備份數(shù)據(jù)會(huì)被打上時(shí)間標(biāo)簽，并上傳到對(duì)象存儲(chǔ)服務(wù)器(Ceph、Minio)。

通過(guò)創(chuàng)建 Job 對(duì) Mysql 進(jìn)行數(shù)據(jù)恢復(fù)：

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

五 技術(shù)演進(jìn)

唯有進(jìn)化，才能站到食物鏈頂端。

根據(jù) Gartner 報(bào)告預(yù)測(cè)，數(shù)據(jù)庫(kù)云平臺(tái)市場(chǎng)份額將會(huì)在下一個(gè)五年中翻倍，而70%的用戶將開(kāi)始使用 dbPaaS 數(shù)據(jù)庫(kù)云平臺(tái)。因此，為了滿足各類應(yīng)用程序?qū)?shù)據(jù)庫(kù)云平臺(tái)的需求，同時(shí)為了減少私有云部署中對(duì)大量不同類型數(shù)據(jù)存儲(chǔ)產(chǎn)品的運(yùn)維復(fù)雜性，數(shù)據(jù)庫(kù)的架構(gòu)演進(jìn)將是未來(lái)十年數(shù)據(jù)庫(kù)轉(zhuǎn)型的主要方向之一。

云原生數(shù)據(jù)庫(kù)是未來(lái)數(shù)據(jù)庫(kù)發(fā)展的一個(gè)重要方向，云原生數(shù)據(jù)庫(kù)架構(gòu)隨著云化要求也需要進(jìn)行相應(yīng)的迭代，未來(lái)在云原生數(shù)據(jù)庫(kù)架構(gòu)的演進(jìn)還會(huì)隨著需求的變化而持續(xù)發(fā)展。

??

??

六 未來(lái)展望

中間件作為構(gòu)筑上層業(yè)務(wù)系統(tǒng)的基石和核心技術(shù)，具有高可靠性、高擴(kuò)展性、強(qiáng)專業(yè)性等特點(diǎn)。

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

??

??

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

首先談?wù)勎覍?duì)中間件平臺(tái)的理解，中間件平臺(tái)應(yīng)該是一系列中間件解決方案集合的能力開(kāi)放式技術(shù)中臺(tái)，它形成了完整、久經(jīng)考驗(yàn)、開(kāi)放和組件化的解決方案，旨在為復(fù)雜多變的上層業(yè)務(wù)領(lǐng)域提供穩(wěn)定可靠的計(jì)算、存儲(chǔ)服務(wù)。

任何一個(gè)平臺(tái)型產(chǎn)品的發(fā)展歷程，都不是一開(kāi)始就做平臺(tái)的，而是先有業(yè)務(wù)需求，為了解決實(shí)際業(yè)務(wù)需求而積累了某些領(lǐng)域的知識(shí)，進(jìn)而成為了這些領(lǐng)域的專家，最終再向平臺(tái)轉(zhuǎn)變。換句話說(shuō)，平臺(tái)是一個(gè)持續(xù)積累的過(guò)程，也是一個(gè)水到渠成的過(guò)程。

??

??

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

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

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

標(biāo)題名稱：云原生下，如何實(shí)現(xiàn)高可用的MySQL？
轉(zhuǎn)載注明：http://www.fisionsoft.com.cn/article/dhiiegi.html