好的 MySQL 相容性可以做到什麼程度? PolarDB-X 如何做生態相容

程式碼派就是我發表於2022-06-02

——吳學強( 燧木

阿里雲資料庫高階技術專家


瞭解更多PolarDB-X 內容: https://developer.aliyun.com/topic/polardbx_release


眾所周知,資料庫是基礎的軟體系統,而基礎的軟體都有自己的生態。生態的構建有兩種正規化,第一種正規化是從  0   1  的構建,第二種是基於已有的生態繼續演化。

分散式資料庫是資料庫領域的熱門方向,目前已有非常多的開源專案。這些開源的專案大多都選擇了第二種方式,即從已有的   MySQL   Oracle  生態進行自己的生態構建。

而採用第二種方式,就不得不考慮與已有生態的相容性。相容性並不是  1  的二分割槽別,用相容度來表達會更客觀。作為新的資料庫,更應該關注的是它解決了什麼新的問題 是帶來了什麼新的特性。


一、為什麼要相容 MySQL 

image.png

2003  年淘寶網成立之後,業務飛速發展,其後臺架構也進行了多次迭代。 2009  年之前,淘寶網後臺的資料庫架構是經典的   IOE   組合。 IOE   是指  IBM  的小型機、  Oracle  的資料庫加上  EMC  的高階儲存。這套組合成本高昂,但依然 無法 滿足淘寶網對於高併發、大容量的擴充套件性需求。

為了解決這兩個問題,  2009  年,淘寶發起了“去   IOE ” 運動,其目標是用自研的分庫分表中介軟體  TDDL   加自己維護的  MySQL  分支  Ali SQL  來替換   IOE   組合。這套架構在  2011  年雙  11  大促的時候,成功接管了交易的核心庫之一——商品庫,從而驗證了   TDDL  + Ali SQL  方案的可行性。

伴隨著此套方案的普及,“去 IOE” 活動在 2013 年正式結束, TDDL  + Ali SQL  組合成為了阿里巴巴所有業務接入資料庫的標準。

同時因為   TDDL  + Ali SQL  組合,即分庫分表中介軟體+  MySQL  方式在阿里的成功驗證,其他國內網際網路廠商也都緊隨其後,分庫分表中介軟體的方案在國內得到了普及。

2015  年, TDDL  以中介軟體的形態在阿里雲上釋出,名為   DRDS   ,即 分散式關係型資料庫。

image.png

此後, DRD S   繼續迭代。迭代過程中,也嘗試解決了中介軟體形態幾個比較大的問題。  2016  ,透過外部系統來嘗試解決此形態下擴容的問題。 2017  年 ,基於  MySQL  X 實現了內建的分散式事務能力。 2018  ,為了解決此組合的運維複雜度,進行了產品形態上一體化設計的嘗試。 2019  ,阿里對過去  10  年的技術實踐和  5  年的上雲經驗進行了重新思考,並對產品架構做了全新的梳理和設計。


2020  ,阿里釋出了全新一代的產品架構,並將   DRDS   產品品牌升級到了   PolarDB-X。 在 2021 年雲棲大會, PolarDB-X   正式對外開源。

回顧產品發展的歷史,可以得出兩個顯而易見的結論: PolarDB-X  產品的出發點就是  MySQL  ,因此產品後續的迭代都是以相容  MySQL  作為目標之一;

第二,透過近 10 年的不斷探索,從中介軟體形態到分散式資料庫形態,並沒有不可跨越的技術鴻溝。


二、怎麼做相容:以 CDC 為例

image.png

CDC C hange Data  C apture   增量資料捕捉,用來解決一些特定的業務問題。


後臺系統一般可以分為上層業務系統和下層資料庫系統。業務最原始的資料都存在資料庫系統中。一份重要資料有很多問題需要考慮,其中之一便是如何解決資料孤島的問題——如果想進一步挖掘這份資料的價值,如何將它與其他生態系統進行互通?

image.png

MySQL  透過  Binlog  特性來打通與下游工具 系統的互通。 Bin log  可以簡單地理解為單一的佇列,佇列按照時間順序嚴格記錄了  MySQL  裡面所有資料的變更過程。下游工具 系統透過消費佇列來實時獲取到  MySQL  裡資料的變更。

image.png

PolarDB-X   提供  CDC  能力,首先需要考慮能否提供完全相容  MySQL Binlog  的  CDC  能力。在分散式系統中提供上述能力,會面臨若干問題,而這些問題都由同一個原因引起。

分散式資料庫系統中通常有多個計算節點和儲存節點,如上圖所示的  CN   DN  節點。多個節點會產生多個事件佇列,會面臨以下幾個問題:


①  在不同佇列裡,事件之間的順序如何確定?

②  通常分散式事務會涉及到多個佇列,如何找到分佈事務包含的所有增量事件,以保證分散式事務的完整性?

③  分散式系統中,  DDL  操作不可能在所有  CN   DN  節點中同時生效,也就意味著在若干個增量的事件佇列裡,可能會存在不同版本的  schema  如何解決?

④  分散式系統很大的特點就是彈性,自動擴縮容所引發的事件佇列的增減問題如何處理?


針對以上問題進行非常詳細的分析之後,我們最終得出的結論是:這些問題可解,但代價較高,而最終工程量在可接受範圍之內。因此,我們將  CDC  這項能力的目標設計為保持與  MySQL Binlog  的體驗完全一致。


實現此功能後,  MySQL  能夠訂閱  Binlog  的工具 系統,可以從  MySQL  無縫 切換到   PolarDB-X, 這項能力被稱為   G lobal Binlog  (全域性  Binlog )。

  全域性 Binlog 能力已於 2021 年雲棲大會發布。此後我們進行了持續迭代,包括穩定性相關的繼續最佳化、效能的最佳化且驗證了更多下游工具 系統。

  Flink CDC 為例, Flink CDC  已經提供了  MySQL  C onnect or   的連線方式。因為   PolarDB-X  提供了一種與  MySQL Binlog  完全相容的全域性  Binlog  能力,所以可以將  Flink CDC   MySQL Connector  直接與   PolarDB-X   進行互通。

最終,從產生接入的想法,到   Flink  CDC   github  上出現支援   PolarDB-X  資料庫作為源端,整個過程只花費不到一週的時間,充分證明了做到與  MySQL  Bin log  完全相容之後帶來的便利性。


Global Binlog   Flink CDC  連線演示——雙十一交易大屏模擬


 

image.png

去年在雲棲大會開源之後到現在,我們的工作又有了一些進展。上圖橙色部分是已經在  2.1  版本里實現的新功能,主要是對下游工具 系統的驗證。

下一步,我們會驗證更多工具,嘗試支援 GTID,以及實現  Binlog  多流的能力。

image.png

前文解決了資料庫下游的問題,上游的問題也不可忽視。

分散式資料庫是用來處理特定的情況下,比如其高併發 擴充套件性遇到問題的資料庫型別,這也意味著業務在上線之初,通常採用單機形態的資料庫。而從原來的單機資料庫往分佈資料庫遷移 切換時,如何平滑、有效地完成遷移,也是不得不考慮的問題。


MySQL  實現平滑遷移,主要透過其 原生的主備複製能力,以保持主節點和備節點之間的實時增量同步,即  replication  能力。 它所用的  SQL  指令為change  master 


如果   PolarDB-X   提供同樣的能力,是否可行?


經過分析之後,我們認為可行,但有一定的工程量。因此,最後結論依然是提供與  MySQL  完全相容的複製能力,稱為   R eplica 


Replication   演示

本次演示以  MySQL  為主 , PolarDB-X   為備,搭建一條主備同步鏈路,以展示   PolarDB-X     R eplica  能力。

 

 

以上,這兩個例子就是  PolarDB-X   開源後在  MySQL  相容方向上 新加入的一些能力。

image.png


PolarDB-X Replication 擁有如下 特性:


①  產品體驗上,能夠支援  MySQL  原生的  change master  指令,即可以在   PolarDB-X   裡直接輸入  change master  指令來搭建  MySQL    PolarDB-X   主備同步鏈路。

源端也支援以   PolarDB-X   作為主庫,意味著可搭建   PolarDB-X    PolarDB-X  主備同步的鏈路。支援 DDL  同步,以及支援事務複製、行級複製,使用者可以在效能和 事務 的完證性兩個方面進行選擇。


②  效能方面,單條複製鏈路目前支援  1.5   RPS  ,沒有大事務等特殊場景下,支援  1  秒以內的同步延遲。


③  目前已驗證的上游系統包括  MySQL /  MariaDB     PolarDB-X,後續 會嘗試驗證其他系統。


下一步,我們的工作主要將圍繞以下三方面開展:接入多流能力,使得 PolarDB-X     PolarDB-X   之間的同步鏈路有更強的效能增強;適配  global Binlog    GTID  能力,使得同步鏈路在事務複製時可以支援並行複製能力;適配更多源端。



三、完全相容 MySQL 嗎

image.png

MySQL  是非常複雜的系統,可以將其拆解為若干特性 功能項,再進行逐項分析。


首先,特性的重要性如何?上圖中以扇形對應的角度來表示;其次, PolarDB-X   在這項能力上對 MySQL  的相容程度有多少?上圖中以扇形半徑來表示。如果   PolarDB-X   做到了與  MySQL  特性完全相容,扇形的半徑應該與外面圓的半徑相等;如果只做到部分相容,則扇形離圓的邊緣有一部分空白;如果目前   PolarDB-X   還不支援此特性,則對應的扇形為空白。


上圖顯示了評估後的結果。可以看出   PolarDB-X   在基礎能力的相容性上總體表現不錯;高階特性也相容了很大一部分,但是有部分特性依然不相容。


PolarDB-X   的目標並不是完全相容  MySQL ,而在於上 圖的下半部分圓——   PolarDB-X    MySQL  資料庫更多能力的增強 新增。比如併發的讀/寫、儲存容量 單表的容量、彈性、高可用和容災、 H TAP   、企業級特性等能力,相對  MySQL  都有了非常大的增強。



四、進入 Kubernetes 生態

PolarDB-X  也是雲原生的資料庫,而云原生以  K8S  為底座

因此,  PolarDB-X   K8S  上也做了非常多工作,比如基於 K8S 進行了資源的編排、構建了  CICD  流程、進行混沌測試等。

2021年雲棲大會,我們開放了最基礎的  PolarDB-X  O perator  能力。而  PolarDB-X 2.1  最新版新增了基於 Prometheus+Grafana 監控的系統,增強了可觀測性。

image.png

上圖為監控系統頁面截圖,展示了系統的資源、 QPS 等豐富的監控維度。使用者可以在  github  倉庫上下載、安裝和體驗。


另外,我們對   O perator  也進行了持續迭代。此前提供的   O perator  只具備基本例項生命週期的管理能力,比如例項的建立、銷燬等。後續已新增比如擴縮容、升降配、資料自動  rebalance  等能力。

image.png

 K8S  方向上,我們還有豐富的規劃。上圖展示了後續計劃的工作。

綠色部分是目前已經完成的,使用者可以透過開源倉庫進行體驗:

  • 生命週期管理上,提供例項的建立、刪除、升降級等;
  • 彈性上,支援例項的水平擴縮容、垂直擴縮容、資料 rebalance  等;
  • 高可用和容災上,支援 CN 高可用、 DN 高可用、GMS 高可用、CDC 高可用等;
  • 監控上:支援支援 CN 監控、 DN 監控、GMS 監控等。


黃色部分代表當前正在研發的能力,比如備份恢復、 SQL 審計、   D ashboard  資料透視等。

白色部分代表未來更長期的規劃,比如國產化、引數設定功能等。


以上就是我們在雲原生能力上的一個規劃,後續也會有節奏的開放給使用者使用。

 


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31550522/viewspace-2898710/,如需轉載,請註明出處,否則將追究法律責任。

相關文章