發佈會傳送門：https://yqh.aliyun.com/live/polardbx2021
背景
我們作為開發者都瞭解或熟悉後臺系統，後臺系統可以抽象為兩個組成部分：一個是業務系統，該部分負責處理系統的業務邏輯，在現代化的架構中，該部分通常設計成可水平擴展的無狀態節點；另一個是數據庫系統，該部分負責存儲系統的狀態，這其中便包括最核心的業務數據。
站在數據庫的視角，數據的流入包括兩個部分，一個是業務系統的實時寫入，這是核心數據來源的主要部分；另一個是從上游數據系統一次性或週期性導入的數據。因為這些核心數據在這裡首次產生，所以這個數據庫也被稱為 SSOT（Single Source of Truth）。
SSOT 是後臺系統中最重要的數據資產，那麼隨之便產生兩個問題需要妥善處理。第一個問題是，作為最重要的資產，通常我們需要將這些數據實時同步到其他系統進行 BI 分析等進一步的處理，如果沒有這樣的實時同步機制，那麼這份數據將成為數據孤島。第二個問題是，這份數據可能因為各種原因遭到破壞，比如硬件故障或軟件 Bug 導致的數據損壞、不當操作引起的數據損壞、錯誤 SQL 引起的數據錯亂等，提供多種機制保障這份數據的安全顯得非常必要。
全局 Binlog
PolarDB-X 是一款高度兼容 MySQL 生態的分佈式數據庫產品，所以我們首先來看下 MySQL 是如果解決數據孤島問題的。
從 DB-Engines 排行榜可以看出，MySQL 的流行度比其他開源數據庫的總和還要高，這意味著 MySQL 的生態非常繁榮，比如 MySQL 的下游系統有 Kafka、MySQL 備節點、Canal 多種數據同步工具、Pulsar 等等。MySQL 通過 Binlog 機制實現了與下游系統的實時增量數據同步。Binlog 可以看做是一個消息隊列，隊列中按順序保存了 MySQL 中詳細的增量變更信息，通過消費這個隊列，下游系統或工具實現了與 MySQL 的實時數據同步，這樣的機制也稱為 CDC（Change Data Capture），即增量數據捕捉。
分佈式數據庫提供 CDC 能力相對於單機有更高的複雜度。一個分佈式數據庫通常包含多個節點，這些節點會產生多個增量日誌隊列，那麼下游如果要消費多個隊列會涉及幾個問題。
- 因為是多個隊列，那麼下游消費時多個隊列內變更事件的順序如何確定？
- 分佈式事務的變更可能涉及多個隊列，如果要保證消費時事務的完整性，那麼如何發現併合並同一個事務的變更事件？
- 系統發生了擴縮容（也就是隊列的增減）下游如何正確處理？
- DDL 會涉及多個隊列，下游如何精確識別出每個隊列 Schema 變化前後的位置並協調好消費進度？
面對這些問題，分佈式數據庫的 CDC 能力需要在實現難度、支持特性、易用性等方面做 trade-off。通常來說，給下游提供多個隊列、不保障事務完整性僅提供最終一致性、提供自定義格式的增量日誌是一種較易實現的方案，但該方案會對下游消費提出更高的要求，比如要開發相應的消費代碼或工具、需要考慮多個隊列的協同問題等。一種體驗更友好的方式是，通過提供與 MySQL Binlog 完全一致體驗的 CDC 能力，讓下游可以像消費 MySQL Binlog 一樣透明的消費分佈式數據庫的增量變更，從而極大降低數據同步鏈路的搭建成本，這也是 PolarDB-X 2.0 採用的方案，我們稱為全局 Binlog。
PolarDB-X 2.0 採用的是可水平擴展的 Share-Nothing 架構，系統基本組成單位是節點（即 Node），每個節點又可分為計算節點（即CN）和數據節點（即DN）兩個部分。如上圖所示，為提供全局 Binlog 能力，PolarDB-X 2.0 在此基礎上增加了 CDC 組件，CDC 是一個具備彈性能力的集群。
全局 Binlog 的生成過程可分為三個階段：
- CDC 組件從每個 DN 拉取其增量日誌，也就是物理 Binlog，之後進行單隊列排序、內部事件過濾、DDL 相關的整形等操作，以便為下一階段提供一個“乾淨”的增量事件隊列，同時若系統發生了擴縮容，CDC 組件會在該階段自動感知並做相關處理；
- CDC 組件將所有“乾淨”的增量事件隊列進行合併，期間會對屬於同一分佈式事務的事件進行合併，並會根據事務時間戳進行全局排序，這樣便得到一個全局有序的保障事務完整性的事件隊列，同時該階段還會處理好 DDL 在隊列中的位置。之後 CDC 組件會將該隊列生成兼容 MySQL Binlog 格式的文件，即全局 Binlog 文件；
- CN 組件在收到下游訂閱全局 Binlog 請求後，會按照 MySQL DUMP 協議將全局 Binlog 發送給下游消費。
經過上面三個階段，PolarDB-X 2.0 實現了完全兼容 MySQL Binlog 的全局 Binlog 能力。如果對詳細的實現原理感興趣，歡迎關注我們的知乎專欄《PolarDB-X 知乎專欄》。
備份恢復
對於數據損壞問題，PolarDB-X 2.0 提供不同粒度的數據恢復能力，包括實例級的一致性備份恢復能力、表級的表回收站能力、SQL 級的 SQL 閃回能力、行級的 Flashback Query 能力等。下面分別介紹這四項能力的特點和使用場景。
一致性備份恢復
首先來看下一致性備份恢復，該能力的特點是可以提供實例級任意時間點的歷史數據恢復能力，這個時間點可以精確到秒級。
單機數據庫中，可以認為全量數據和增量日誌都存儲在一臺機器上，實現一致性備份和恢復的話，只需要將全量數據和增量日誌備份就好。分佈式數據庫中若要做到一致性備份恢復，因為全量數據和增量日誌都存儲在多臺機器上的緣故，實現上會有額外的複雜度。
PolarDB-X 2.0 中通過將所有 DN 做全量備份+全局 Binlog 的方式實現了一致性備份恢復能力。
以上圖為例，比如我們有一個 PolarDB-X 2.0 實例每週一、週二和週五的零點進行備份，某天產生一個需求，需要將數據恢復到週日的 14:25:26，那麼我們的系統會選擇離恢復點最近的一個全量備份集---- 也就是週五零點點這份，並從週五零點開始重放全局 Binlog，直到週日 14:25:26 結束，這樣我們便得到了想要的快照。
PolarDB-X 2.0 的一致性備份恢復能力備份期間不會鎖庫，該能力依賴全局 Binlog，也就是可恢復的區間是全局 Binlog 的保存區間。該能力目前有幾個限制，比如備份期間不能進行擴縮容、僅支持同構恢復等。
表回收站
PolarDB-X 2.0 提供的第二項數據恢復能力叫做表回收站。顧名思義，我們會將 DROP 的表臨時放入一個回收站，若兩小時內發現需要恢復該表，那麼可以在回收站中找回。
表回收站提供了完整的管理功能，比如查看回收站中所有的表、徹底刪除某張表、恢復某張表等。回收站目前僅緩存兩小時內刪除的表，並且不支持找回通過 TRUNCATE TABLE 刪除的表。
SQL 閃回（即將上線）
PolarDB-X 2.0 提供的第三項數據恢復能力叫做 SQL 閃回。該能力可精確恢復一條誤操作 SQL 影響的數據。PolarDB-X 1.0 中同樣提供了該能力，上線以來，該能力幫助眾多誤刪數據的用戶找回了數據，是一項被廣泛認可的數據恢復能力。下面我們以一個例子來介紹這項能力的具體使用過程。
如上圖所示，在 T1 時我們想把職位是 "Developer" 名字是 "Ralph" 的記錄刪掉，但 WHERE 條件中忘了加 "name='Ralph'" ，導致名字為 "Mary" 的記錄被一同刪掉了。這兩個刪除事件以及對應 SQL 的 ID 會被記錄在全局 Binlog 中。
T2 時，我們發現了誤刪問題，並通過 PolarDB-X 的審計功能找到了對應的 SQL 和 ID。
T3 時，我們通過 SQL ID 和 SQL 閃回能力生成了恢復 SQL。SQL 閃回的原理是，在拿到 SQL ID 後，通過在全局 Binlog 中進行搜索，找到該 SQL 對應的所有變更事件（此處為兩個刪除事件），並逐個生成逆向恢復 SQL。
T4 時，我們將恢復 SQL 執行後得到了被誤刪的兩條數據。
SQL 閃回針對 SQL 誤操作場景可提供精確的數據恢復能力，可以看出，能夠恢復的時間區間依賴於全局 Binlog 的保存區間。
Flashback Query（即將上線）
PolarDB-X 2.0 提供的第四項數據恢復能力叫做 Flashback Query。該能力可提供一定時間範圍內行級的數據精確恢復能力。下面我們仍以 SQL 誤操作場景為例。
如上圖所示，T1 時我們想把職位是 "Developer" 名字是 "Ralph" 的記錄職位更新為 "CTO"，但 WHERE 條件中忘了加 "name='Ralph'"，導致所有職位是 "Developer" 的記錄都被更新成了 "CTO"。這些變更都會記錄在版本為 Vn+1 的 undo log 中（undo log 是數據庫中的一個基礎數據結構，裡面詳細的記錄了每行數據的變更內容，可簡單類比成 GIT commit log）。
T2 時，我們馬上發現了誤改問題並確定了誤操作時間和影響的數據範圍。
T3 時，我們通過 Flashback Query 能力直接查到了被影響的兩行記錄在 T1 時刻正確的值。
T4 時，我們根據 Flashback Query 返回的正確值對數據進行了訂正。
可以看出，Flashback Query 能力依賴 undo log 的保存時長。與 SQL 閃回相比，該能力可提供更快速、精確到行級的恢復能力，但 undo log 通常不如全局 Binlog 保存的時間長，所以可恢復區間上弱於 SQL 閃回。
總結
PolarDB-X 2.0 針對數據孤島問題提供了全局 Binlog 能力，該能力為下游生態提供了與 MySQL Binlog 完全一致的增量日誌消費體驗。針對數據損壞問題提供了實例級、表級、SQL 級和行級等不同粒度的數據恢復能力，包括一致性備份恢復、表回收站、SQL 閃回、Flashback Query 等。PolarDB-X 2.0 還在持續打造更多產品能力，敬請期待~