自研數據庫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的回檔也就完成了。

此文已由做者受權騰訊雲+社區發佈