自研資料庫CynosDB儲存系統如何實現即時恢復

本文由雲+社群發表 本文作者：許中清，騰訊雲自研資料庫CynosDB的分散式儲存CynosStore負責人。從事資料庫核心開發、資料庫產品架構和規劃。曾就職於華為，2015年加入騰訊，參與過TBase（PGXZ）、CynosDB等資料庫產品研發。專注於關聯式資料庫、資料庫叢集、新型資料庫架構等領域。目前擔任CynosDB的分散式儲存CynosStore負責人。

CynosDB for PostgreSQL是騰訊雲自研的一款雲原生資料庫，其主要核心思想來自於亞馬遜的雲資料庫服務Aurora。這種核心思想就是“基於日誌的儲存”和“儲存計算分離”。同時，CynosDB在架構和工程實現上確實有很多和Aurora不一樣的地方。

下圖為CynosDB for PostgreSQL的產品架構圖，CynosDB是一個基於共享儲存、支援一寫多讀的資料庫叢集。

CynosDB for PostgreSQL產品架構圖

CynosDB基於CynosStore之上，CynosStore是一個分散式儲存，為CynosDB提供堅實的底座。CynosStore由多個Storage Node和CynosStore Client組成。CynosStore Client以二進位制包的形式與DB（PostgreSQL）一起編譯，為DB提供訪問介面，以及負責主從DB之間的日誌流傳輸。除此之外，每個Storage Node會自動將資料和日誌持續地備份到騰訊雲物件儲存服務COS上，用來實現PIT（Point In Time）功能。

CynosStore會為每一個資料庫分配一段儲存空間，我們稱之為Pool，一個資料庫對應一個Pool。資料庫儲存空間的擴縮容是通過Pool的擴縮容來實現的。一個Pool會分成多個Segment Group（SG），每個SG固定大小為10G。我們也把每個SG叫做一個邏輯分片。一個Segment Group（SG）由多個物理的Segment組成，一個Segment對應一個物理副本，多個副本通過RAFT協議來實現一致性。Segment是CynosStore中最小的資料遷移和備份單位。每個SG儲存屬於它的資料以及對這部分資料最近一段時間的寫日誌。

CynosStore 資料組織形式

圖二中CynosStore一共有3個Store Node，CynosStore中建立了一個Pool，這個Pool由3個SG組成，每個SG有3個副本。CynosStore還有空閒的副本，可以用來給當前Pool擴容，也可以建立另一個Pool，將這空閒的3個Segment組成一個SG並分配個這個新的Pool。

資料庫使用者有可能因為某種原因需要回到過去某個時間點的資料庫快照，CynosDB提供快照備份特性，滿足使用者的回檔需求。當然，可以回到過去的時間段總是有限的，這取決於快照備份的儲存空間成本。CynosStore通過持續不斷地將各個SG上的資料和日誌備份到騰訊雲物件儲存服務COS上。其中，基礎資料的快照根據一定頻率定期備份，而日誌則從RAFT狀態機中源源不斷地向COS備份。為了避免備份本身對SG的同步日誌過程產生影響， SG會先將日誌持久化到所在Store Node的本地儲存，然後通過Journal Backup Service將本地Journal上傳到COS。每個SG向COS備份的過程是完全獨立並互不依賴的。每個SG備份時的故障處理也是獨立的。

CynosStore即時恢復

相比SG的備份，一個資料庫例項回檔到某個時間點的過程要複雜得多，因為回檔過程必須保證這個Pool的所有SG回到同一個快照點。當CynosStore接收到一個回檔Pool的請求，CynosStore會根據這個Pool上所有SG備份的日誌資訊找到並計算出與這個時間點對應的VDL。這個計算的依據是每個SG的日誌中會定期不斷地加入一個時間戳日誌。每個SG根據需要回檔的時間點和Pool全域性VDL找到時間上最接近的前一個快照以及相應的日誌檔案。然後根據快照和日誌重放SG，各個SG重放過

程互不依賴。這個回檔過程藉助Replayer Service服務來完成，其根據某個SG的快照資料和日誌重放到給定的一致性點，並將新產生的快照資料上傳到COS。然後由META Center在CynosStore中構建新的Pool和新的SG，通知新SG leader從COS獲取剛剛生成的快照資料，這樣就完成了一個SG的回檔。當這個Pool上所有的SG的回檔完成，那麼這個Pool的回檔也就完成了。

此文已由作者授權騰訊雲+社群釋出

---