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

——吳學強（ 燧木 ）

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

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

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

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

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

一、為什麼要相容 MySQL 

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   ，即 分散式關係型資料庫。

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

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

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

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

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

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

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

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

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  連線演示——雙十一交易大屏模擬

 

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

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

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

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

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

而 如果   PolarDB-X   提供同樣的能力，是否可行？

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

Replication   演示

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

 

 

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

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 嗎

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 監控的系統，增強了可觀測性。

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

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

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

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

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

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

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

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