揭祕MySQL生態重要功能，X-Engine引擎核心能力——OnlineDDL

簡介：做者：雁閒、無哈，阿里雲數據庫技術專家

概述

X-Engine是阿里自研的數據庫存儲引擎，以插件的方式接入到MySQL生態，支持行鎖，事務，MVCC等OLTP場景的核心功能。

X-Engine的核心優點是低成本，高性價比，尤爲適用於歷史庫場景，目前阿里巴巴內部的核心交易歷史庫(原來是Hbase)，釘釘消息歷史庫(原來是MySQL(InnoDB))，淘寶商家的圖片空間等業務均經過X-Engine解決了成本問題。

同時，X-Engine也賦能阿里雲數據庫服務，做爲雲上RDS-MySQL的存儲引擎，對外售賣，讓更多的用戶享受到新技術帶來的紅利，有關X-Engine的詳細介紹，請移步2019年10月的數據庫內核月報。本文主要介紹X-Engine引擎的一個核心功能，OnlineDDL。

OnlineDDL毫無疑問是MySQL生態的一個重要的功能，想當初MySQL 5.6之前，DBA執行DDL變動時，爲了保證7*24小時服務，只能採用最老土的主備切換的方式來進行。數據庫存儲引擎區別於NoSQL引擎的一種重要指標就是是否支持SQL，是否有schema(數據字典)。有了schema，還需靈活地支持在線變動，這樣才能從容應對業務快速變化的需求。MySQL生態中這麼多存儲引擎只有InnoDB完整地支持了OnlineDDL，X-Engine做爲MySQL生態的新成員，雖然採用了徹底不一樣於InnoDB的存儲架構，但OnlineDDL給用戶的體驗是同樣的 。

總體流程

X-Engine採用類LSM的分層架構，數據按照時序邏輯分紅多層，每一層數據有序，新數據在較高的層次，最老的歷史數據在最底層。對於X-Engine來講，每一個主表和二級索引數據都是一棵分層的LSM-tree結構，內部稱之爲Subtable。每一個Subtable分爲4層，Memtable，L0，L1和L2，每一層都保持有序，數據按新舊順序依次往更深的層次遷移，其中Memtable在內存中，其它幾層按需能夠在不一樣的存儲介質上。OnlineDDL功能實現充分利用了X-Engine的數據組織特色，將新build數據分爲兩部分，基線數據和增量數據。基線數據是指變動開始時，經過拿snapshot能遍歷獲得的數據；增量數據是指，變動開始後，用戶寫入的新數據。拿Snapshot過程須要短期禁寫，由於咱們強依賴這個一致性位點，確保基線+增量數據的完整性。

OnlineDDL總共包括了4個階段，包括Prepare階段，Inplace-build階段，Commit階段和Post-ddl階段。

一、Prepare階段，這個階段主要是準備數據字典，構建底層存儲數據的Subtable，爲後續的增量寫入作準備。

二、 Inplace-build階段，這個階段OnlineDDL的核心階段，一方面經過Snapshot獲取基線，另外一方面還須要實時維護增量數據，利用X-Engine的數據組織的append-only特性，將基線和增量合併，即完成了OnlineDDL新數據構建的過程。這個過程的詳細邏輯會在下一個小節詳細介紹。

3.、Commit階段，這個階段是OnlineDDL引擎層變動生效階段，若是整個OnlineDDL過程當中沒有出現異常或錯誤，那麼Commit階段會生效新的數據字典，生效新的數據。
四、 Post-ddl階段，這個階段是OnlineDDL真正生效階段，這個階段完成後，纔會返回給用戶DDL成功。這個階段的引入，主要是由於MySQL經過Server層+引擎層這樣的一個二層結構實現擴展，而每一層都有本身的數據字典，在Commit階段只能保證引擎層的數據和數據字典是完整的，爲了保證DDL變動的原子性(Server層和引擎層數據字典保持一致)，引入Post-ddl階段作清理和藹後工做，有關DDL原子性的討論會在下面的章節詳細介紹。

核心邏輯

OnlineDDL的核心邏輯在於如何作到執行DDL變動時，不堵塞用戶對該表的DML和SELECT操做。X-Engine實現OnlineDDL有兩個關鍵點，第1，利用X-Engine的數據組織append-only特色，增量維護在Memtable，L0，L1中，而基線數據維護在L2中；第2，維護增量時，採用雙寫，同時維護old-table和new-table中的數據。與InnoDB引擎相似，根據DDL是否涉及到數據記錄格式變動，將DDL變動分爲Inplace-rebuild和Inplace-norebuild兩種類型。對於X-Engine來講，二者本質是同樣的，區別在於維護的索引個數。Inplace-rebuild類型的DDL須要同時維護new-table中全部索引；而Inplace-norebuild類型的DDL只須要維護new-table的新增的索引。

整個Inplace-Build按照時間序有3個關鍵節點，t0時刻是獲取快照的時間點，t1時刻是build基線完成的時間點，t2時刻是惟一約束檢查完成的時間點。那麼兩個階段的主要邏輯以下：t0-->t1主要工做是在build新表的基線，經過將old-table的數據結合new-table的數據字典生成新的記錄，最終寫入新表對應的L2層；在build新表基線的過程當中，產生的增量寫入到新表的(Mem,L0,L1)。DDL過程當中，須要對後臺的Compaction任務作必定的控制，確保不執行合併到L2的Compaction任務。t1-->t2是惟一性校驗階段，確保新增的主鍵或者惟一索引的惟一性，t2時刻將(Mem,L0,L1,L2)中的數據合併，最終獲得new-table的全量數據。記錄轉換的過程以下：
其中，DDL事務表示DDL線程，它的任務是掃描基線，生成新表的基線數據；DML事務表示DDL過程當中，併發的DML事務，它們的任務是，經過雙寫機制同時維護新表和老表的增量。

對比InnoDB實現邏輯

雖然X-Engine與InnoDB的OnlineDDL都是採用基線+增量的方式實現，但具體邏輯是不一樣的，主要是由於InnoDB採用的的是原地更新操做而且經過row-log機制來維護增量，而X-Engine是一個append-only的存儲引擎，自然地支持數據的多版本存儲，能夠實時維護增量數據，在基線創建完成後只須要將基線與增量數據合併，即便基線中的數據在增量中被修改，但增量中數據的版本比基線數據版本更新，從而在合併時會覆蓋基線中老版本的數據。下圖是InnoDB引擎OnlineDDL過程。

能夠看到InnoDB引擎的OnlineDDL也包括3個關鍵時間點，與X-Engine引擎的區別在於，t1-->t2 是InnoDB追row-log過程，而對應X-Engine是惟一約束檢查的過程。固然對於X-Engine來講，t1-->t2不是必需的，由於DDL變動可能並不涉及惟一索引操做。

Instant-DDL

與MySQL8.0(InnoDB)相似，X-Engine一樣也支持Instant-DDL。在全部支持的OnlineDDL中，若DDL操做只涉及修改表的屬性信息，或只是作了加列操做，不須要修改記錄格式，也不須要新增索引，那麼這些OnlineDDL操做能夠優化成Instant-DDL。這些DDL操做能夠「極速」完成，用戶基本無感知。因爲Instant-DDL執行時，並無真正涉及引擎數據的修改，爲了後續查詢結果和DDL操做的正確性，須要對於引擎的記錄格式作必定的調整，加一些控制元信息。新增一個1字節來標示生成這個記錄時，表是否執行過instant-ddl。同時，生成記錄時，還須要記錄有多少個列是已有的，以及有多少個null列等；在讀取解析記錄時，根據字典信息，就能知道有多少個列是須要根據instant列信息來補充，確保instant-DDL後，返回查詢結果的正確性。

DDL原子性保證

從OnlineDDL的總體流程中咱們瞭解到，OnlineDDL最後一個階段是Post-ddl階段。MySQL8.0之前，Server層的元數據都是經過文件來存儲，好比frm文件，par文件以及trg文件等。一個DDL操做修改，涉及到文件修改，引擎數據修改以及引擎字典的修改，這些操做沒法作成一個事務，必然致使整個DDL操做沒法作到原子性。若DDL過程當中出現異常，就可能會致使Server層和引擎層數據不一致，以及殘餘的垃圾沒有清理等問題。MySQL8.0將Server層的全部字典信息統一存儲在DD(DataDictionary)中，而且經過InnoDB引擎存儲，那麼DDL過程當中，咱們只要保證Server層數據字典的修改，以及引擎層數據字典的修改封裝成一個事務便可。

對於InnoDB引擎而言，DD數據字典操做，InnoDB引擎數據字典操做都是經過InnoDB引擎存儲，經過InnoDB事務特徵來保證原子性。對於X-Engine引擎而言，DD數據字典操做，X-Engine引擎數據字典操做分別採用InnoDB引擎和X-Engine引擎，除了依賴於InnoDB和X-Engine自身是事務引擎特徵，還須要藉助於內部的2PC協議來保證整個事務的原子性。若是MySQL開啓了binlog，那麼就是binlog，X-Engine，InnoDB三者一塊兒經過2PC協議保證事務的原子性。而Post-ddl階段就是作善後和清理工做，若是最終整個事務提交，Post-ddl階段負責真正清理old-table數據；若是最終整個事務回滾，那麼Post-ddl階段負責清理臨時產生的new-table數據，確保DDL變動先後，數據庫的狀態是一致的。

使用體驗

X-Engine做爲MySQL的一個新引擎，在語法使用層面徹底與MySQL(InnoDB)相同，經過algorithm_option指定Online類型，經過lock_option指定DDL過程當中，是否容許其它併發的DML和SELECT操做。一般狀況下，這兩個選項都不用特別指定，採用默認值便可，MySQL內部會優先選擇Instant類型和Inplace類型，對於不支持Online的DDL操做，選擇Copy類型。在功能層面也與MySQL(InnoDB)相同，目前X-Engine暫時還不支持全文索引，虛擬列，外鍵等功能，所以與這些功能相關的DDL操做會不支持，其它DDL操做與MySQL(InnoDB)相同。經常使用的DDL操做分類以下：

後續工做

X-Engine做爲一個新的數據庫存儲引擎，經過集團業務場景的打磨，已經體現了它的價值，咱們但願經過雲上RDS場景，讓更多用戶享受到新技術帶來的紅利。固然，目前X-Engine還有一些不足，尤爲是相對於傳統成熟的MySQL(InnoDB)和Oracle，因此X-Engine引擎在優化自身的穩定性和性能同時，會持續不斷地豐富數據庫功能，包括支持外鍵，全文索引，虛擬列等。除了公有云的RDS輸出，基於X-Engine的一體化分佈式數據庫PolarDB-X也是一個重要方向，咱們會以專有云形式輸出，服務更多對分佈式數據庫有強需求的用戶。