本文由雲+社區發表 CynosDB for PostgreSQL是騰訊雲自研的一款雲原生資料庫，其主要核心思想來自於亞馬遜的雲資料庫服務Aurora。這種核心思想就是“基於日誌的存儲”和“存儲計算分離”。同時，CynosDB在架構和工程實現上確實有很多和Aurora不一樣的地方。 下圖為CynosD ...
本文由雲+社區發表
本文作者：許中清，騰訊雲自研資料庫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的回檔也就完成了。
此文已由作者授權騰訊雲+社區發佈
