：

：

作者：阿里雲資料庫 胡慶達，張海平，季育軒

在過去的幾年裡，我們觀察到，當資料達到一定規模後，PolarDB for MySQL（後文簡稱PolarDB）的部分使用者（包括集團內部使用者和公有云上的外部客戶）更願意使用gh-ost/pt-osc這樣的外部工具來進行DDL操作。PolarDB核心團隊為使用者case by case地解決了很多DDL使用帶來的問題，在處理這些問題的同時，我們也在不斷地思考和討論，雲上客戶越來越多，中小客戶群體不斷擴大，我們究竟要如何在核心層面解決DDL日益凸顯的繁重弊端，讓客戶少為DDL擔憂。

DDL面臨的問題

DDL在生產環境下面臨的問題主要來自兩個方面：一個是MDL導致的阻塞問題，一個是全量資料複製帶來的資源使用問題。

為了保證DD的一致性，MDL被引入來同步DDL，DML和DQL，這使得同一個表上的各種操縱必須在MDL這一粗粒度鎖上匯聚，由此引發了各種超時問題，嚴重影響了上層業務。此外，在PolarDB共享儲存結構下，多節點間的DD一致性要求使得這一問題擴充到了讀寫節點之間，也為使用者帶來了諸多困擾。

在PolarDB內部，資料物理儲存和資料定義是分離的，因此DDL操作常常需要進行全量資料的重建，由此導致了單次DDL操作耗時甚至可以達到天級。這種操作的潛藏風險讓使用者不得不焦躁地在客戶群裡反覆和研發同學溝通確認。同時，全量資料的重建會佔用大量的系統資源。PolarDB的雲原生優勢已經在相當程度上為客戶規避了這一問題，資源的快速彈性伸縮防止了OOM，磁碟空間不足等問題，但是系統資源的大量佔用將提高其他操作的耗時，降低資料庫的整體吞吐，最終將影響上層業務的穩定性。

此外，在全面上雲的大背景下，雲上中小客戶群體不斷擴大，他們中很多還缺乏處理資料庫複雜生產環境下的各種細節問題的經驗。在我們的觀察裡，這些客戶的DDL操作頻率顯著高於集團內部使用者和其他大客戶，DDL使用過程中的很多問題讓這些使用者焦頭爛額。

最佳化和演進方向

解決DDL帶來的問題，本質上我們需要做到的只有一點：降低DDL執行耗時。如果DDL可以在瞬間完成，那麼DDL帶來的諸多問題都將迎刃而解。於是在這樣一種思路的指導下，我們提出了Instant DDL + Parallel DDL + 物理複製鏈路最佳化的整體解決方案。

對於可透過變更資料定義完成的DDL型別，如加列，減列等，我們將其Instant化，使其無需修改存量資料，因而可在瞬間完成；對於必須全量掃描並構建資料的DDL型別，如重建主鍵索引，新建二級索引等，我們允許其在引擎內部被並行地處理，從而充分利用系統資源，降低執行耗時。

此外，我們還使用了並行MDL同步方案，解決DDL過程MDL在讀寫節點上的阻塞問題，同時最佳化了物理複製使用的Redo Log,降低了DDL操作時讀節點同步Redo Log的負載。這些物理複製鏈路上的最佳化和DDL執行鏈路上的整體演進共同作用，構成了攻克DDL難關的主力軍和護衛隊。

Instant DDL

像add column這類DDL，原有的執行邏輯包含兩個部份的操作，分別涉及資料字典和存量資料。其中資料字典的修改是非常快速的，但是表全量資料的重建則耗時漫長。

Instant DDL則僅改變資料字典中的表定義資訊，而不修改任何存量資料，從而使得DDL操作可以在瞬間完成。

目前add column at last instantly已經在PolarDB 5.7和8.0上得到支援， add column at any position instantly和drop column instantly等也將在隨後的版本中上線，未來所有邏輯上可Instant 化的DDL操作都將支援Instant演算法。使用者只需熱升級到相應的版本，即可讓原本耗時達到小時級甚至天級的DDL操作在瞬間完成。

Parallel DDL

新建二級索引這類DDL操作，執行時必須掃描全量資料，並構建新的索引樹，整體耗時非常長。

Parallel DDL則將Data Scan和B+ Tree Build操作劃分成多個子任務，透過內部的並行服務子系統進行排程並適時地執行，最後將各個子任務的執行結果進行合併得到最終結果。

Parallel DDL 透過儲存引擎內部的並行執行，充分利用系統資源，使得部分DDL的執行效率最高可提高十倍以上，從而將整個DDL的時間視窗縮小到原來的十分之一。目前parallelly create secondary index 已經在PolarDB 8.0上得到支援，後續將陸續上線到其他版本，同時其他型別的Parallel DDL支援也將在隨後的版本中釋出。

物理複製鏈路上的DDL最佳化

Instant DDL 和Parallel DDL 是DDL執行鏈路上的演進方案。但是在PolarDB共享儲存架構下，複製鏈路上的問題同樣制約著DDL的能力。例如為了保證各節點的一致性，必須在讀寫節點間透過Redo Log同步MDL資訊，然而MDL鎖的阻塞將影響Redo Log的同步，為此我們採用了並行MDL同步方案，將MDL資訊的同步和Redo Log的同步解偶，提高了整個叢集在DDL時的吞吐能力。此外我們改進了DDL過程中的Redo Log同步路徑，不僅最佳化了寫節點在產生DDL Redo Log時的IO開銷，同時讓只讀節點有選擇的同步Redo Log，降低DDL 操作時只讀節點的負載，從而降低DDL過程中的讀寫節點間的同步代價。這些物理複製鏈路上的最佳化為DDL執行鏈路上的最佳化效果保駕護航，兩者協同使得整個叢集處理DDL的能力顯著增強。

小結

DDL是PolarDB所有操作中最繁重的一種，曾經為使用者帶去了很多不好的使用體驗。而Instant DDL + Parallel DDL + 物理複製鏈路最佳化是切實解決DDL 繁重弊端的重要組合拳。相信經過未來若干版本的迭代和演進，PolarDB DDL將為客戶帶來體驗上翻天覆地的變化。期待未來使用者執行DDL操作像執行簡單查詢一樣淡定坦然，PolarDB核心團隊將始終如一地為使用者打造最佳的雲原生關係性資料庫管理系統。