乾貨分享！CynosDB for PostgreSQL 架構淺析

科技 09-14

導語

CynosDB是新一代高性能高可用的企業級分散式雲資料庫，採用共享存儲架構，作為騰訊雲NewSQL資料庫家族成員之一，由騰訊雲資料庫產品中心和TEG數據平台部聯合打造，滿足企業按需分配計算和存儲資源，實現彈性調度，動態擴容，節約用戶成本，將結合新硬體，新網路，全球分布，自動化等不斷演進。本文簡要介紹CynosDB for PostgreSQL架構，事務並發機制，緩存管理及數據載入，寫數據流程，以及恢復等方面，後續將進一步補充相關信息，本文僅供參考，交流和學習，感謝您閱讀！

前言

NewSQL是一項系統工程，而系統工程是組織管理NewSQL系統規劃，研究，設計，研發，測試和使用的科學方法，其綜合計算機系統，軟體工程，網路工程，項目及產品管理，安全，數據科學，機器學習，運維體系等方方面面，而架構是系統工程的藍圖，供系統在生命周期內的各個階段（包括研發，管理，實施，運營和運維）提供參考和指導。NewSQL架構與現有系統架構並非完全不同，其中多數技術已存在於傳統DBMS，其創新之處在於將這些技術重新梳理，統一整合到一個管理平台中，通過結合當前新硬體，新網路特點，達到高可靠，高可用，高性能，安全，自動化，充分利用資源的目的。

CynosDB是新一代高性能高可用的企業級分散式雲資料庫，採用共享存儲架構，作為騰訊雲NewSQL資料庫家族成員之一，由騰訊雲資料庫產品中心和TEG數據平台部聯合打造，滿足企業按需分配計算和存儲資源，實現彈性調度，動態擴容，節約用戶成本，具有多租戶，水平擴展存儲，融合傳統關係資料庫、雲計算與新硬體，新網路優勢，100%兼容PostgreSQL。

CynosDB 架構

[ 圖1 CynosDB 全局視圖 ]

CynosDB 由兩類資料庫實例組成：

主實例（讀寫): 除查詢外，還能執行資料庫更新(包括寫入Insert + 修改Update + 刪除Delete)，以及DDL和DCL操作，每個CynosDB資料庫集群均有一個主實例，資料庫實例安裝在獨立的VPC，多個客戶的資料庫實例不會產生計算資源（包括內存）的競爭，可理解為物理隔離計算資源。

副本(只讀): 每個資料庫集群可擁有一個支持讀寫操作的主實例，以及多個副本，多個副本將均衡客戶應用程序的讀操作，還可通過將副本置於單獨的可用區中來提高資料庫可用性。

每個資料庫實例可以在1個騰訊雲虛擬專用雲（VPC）和 3個專用網路（1個管理專用網+ 2個存儲專網）進行通信：客戶應用程序通過客戶VPC與資料庫實例進行交互，資料庫實例所在節點上的Agent 進程通過管理專用網路與管控平台進行交互，資料庫引擎通過存儲專用網路與存儲服務進行交互，而存儲服務與冷備存儲系統通過存儲專用網路進行傳輸，各個專用網路相互隔離，遵從 1987年，關係資料庫設計者C.J.Date在《Distributed Database: A Closer Look》中提出12條規則的本地自治 + 位置透明和獨立性 + 可持續操作 + 硬體獨立性 + 網路獨立性等原則。

[ 圖2 CynosDB 架構 ]

CynosDB使用騰訊雲資料庫運營平台作為控制面板，由實例管理器（Instance Manager）向資源管理器(Resource Manager)註冊申請一個對象池Pool，然後創建和部署CynosDB 資料庫實例，並在該資料庫實例的 VPC 上安裝一個代理（Agent）進程，負責監視資料庫實例的運行狀況，其根據實例運行情況進行故障切換或更換實例。資源管理器(Resource Manager)根據Pool註冊信息初始化一個稱為段組 SegmentGroup的調度單元，根據調度規則選擇最佳節點做為該資料庫實例的物理存儲，調度規則將參考Pool信息，根據裝箱演算法從可用區開始，依次篩選數據中心，機架，物理節點，磁碟容量，以及結合當前整個CynosDB 運行情況（IO + 網路 + 容量），選擇最佳節點。存儲管理器（Storage Manager）負責管控 CynosDB物理存儲資源以及備份和恢複數據需要的詳細信息，對於長時間運行的操作，如存儲節點故障後的資料庫恢復或修復（重新複製）等操作，使用非同步機制通過後端作業進行調度，為保持高可用性，指標採集服務持續監控存儲操作的所有關鍵方面，積極主動，自動化的探測實際的和潛在的問題，如關鍵性能或可用性指標發現問題就會觸發警報而引起關注。存儲服務部署在訪問管理CAM上，並配置多個存儲磁碟（SSD），存儲節點之間採用RDMA技術進行數據的高效傳送，存儲節點維護本地SSD與資料庫引擎實例，其他對等存儲節點以及備份/恢復服務進行交互，備份/恢復服務把資料庫物理日誌持續備份到COS平台，並定期增量數據備份到COS平台，這樣可以按時間點進行數據的快速恢復。

CynosDB 特點:

可管理性：一鍵式部署啟動或停止計算資源和內存資源，計算資料庫實例擴展操作通常在幾分鐘內完成，標準PostgreSQL 導入和導出工具與 CynosDB for PostgreSQL 配合使用進行遷移，可使用實例管理器查看有關資料庫實例的關鍵運營指標，包括計算、內存、存儲、查詢吞吐量、緩存點擊率以及活動連接等信息。可使用最新修補程序不斷更新的資料庫實例，通過資料庫引擎版本管理，控制是否修補實例，以及何時進行修補。靈活的資料庫事件通知機制，通過電子郵件，簡訊，微信等方式通知重要資料庫事件，如自動故障轉移，通過實例管理器訂閱資料庫相關的事件。

可擴展性：計算按需擴展，而存儲服務自動擴容，隨著資料庫存儲需求的增長而自動提高資料庫容量大小，其容量將以 10GB（不含存儲副本）增加，最大可增加到 256TB，無需為資料庫預配置多餘的存儲空間。

可靠性：資料庫實例上的Agent持續監控資料庫實例及其運行狀況，發生資料庫故障時，Agent將自動重啟資料庫及相關進程，而不需要對資料庫重做日誌進行崩潰恢復回放，從而大大減少啟動時間。存儲採用類似的監控機制來監控存儲集群的監控狀態，而存儲副本缺失將自動修補，存儲副本之間採用Batch + Pipeline的 Raft庫來保證存儲副本數據的一致性，而存儲副本分配控制由資源管理器統一分配和調度，如副本數為 3，則允許一個副本丟失，內部自動修復。自動、連續、增進式備份和時間點恢復，能夠將資料庫恢復到保留期內任何一秒鐘的狀態，保留期可設置，如周，月，年等。

安全性：CynosDB在騰訊雲 VPC 中運行，將資料庫隔離在用戶的虛擬網路中，並使用行業標準加密 IPsec VPN 與用戶本地 IT 基礎設施連接，可以配置防火牆設置並控制對資料庫實例的網路訪問，CynosDB 與訪問管理CAM集成，通過身份管理和策略管理控制資源（例如，資料庫實例、資料庫快照、資料庫參數組、資料庫事件訂閱、資料庫選項組）執行操作。

性能：低抖動高吞吐，使用各種不同的軟硬體技術組合，如將重做日誌寫入存儲，非同步合併數據頁，資料庫備份和重做恢復下推到存儲系統進行非同步化處理，從而確保資料庫引擎充分發揮計算、內存和聯網資源，寫入操作可通過資料庫引擎批量進行，同時存儲系統基於SPDK和RDMA的零拷貝技術，減少操作系統上下文切換引起的性能損耗。

專業性：由專業團隊負責PostgreSQL資料庫內核優化，跟進資料庫最新動態，定期升級補丁。

CynosDB 數據模型

[ 圖3 CynosDB 數據模型 ]

說明：

Pool：資源池，每個Pool對應1個資料庫實例，其由1個或多個Segment Group組成，每個Segment Group 由1個主Segemnt + 多個副本Segment組成。

Segment：數據管理（複製、遷移）的最小單元，每個Segment 大小固定(10GB)。

Block：數據組織的最小單元(8KB)，包含結構PageHeaderData定義的頁頭數據(大小24個位元組) + 行指針數組(行指針長4個位元組，並保存指向每個堆元組的指針）+ 元組Tuples（一條數據記錄，從頁面底部按順序向空閑空間增長）

PageHeaderData 欄位：

pd_lsn： identifies xlog recordforlast change tothispage.pd_checksum:page checksum.pd_flags:flag bits.pd_lower:offset to startoffree space.pd_upper:offset to endoffree space.pd_special:offset to startofspecial space.pd_pagesize_version:sizeinbytes and page layout version number.pd_prune_xid:oldest XID among potentially prunable tuples on page.

CynosDB 存儲模型

在1992年在LFS首次出現日誌結構存儲，通過只寫數據頁的變更來減少寫放大，以REDO日誌方式，跟蹤事務確認回復最大的LSN，而CynosDB 存儲採用日誌寫 + 塊讀方式實現日誌結構的存儲系統，對於寫是日誌流，而讀操作支持MVCC的塊操作。

[ 圖4 CynosDB 存儲IO ]

CynosDB IO 流：

存儲節點接收日誌記錄並添加到內存隊列。

通過CynosDB Raft 同步日誌副本到 Peer 存儲節點，成功後向主實例發送ACK確認，同步日誌走SPDK/RDMA環境。

合併線程定期合併本地日誌到數據，並備份到冷備系統。

定期將新頁面存儲到冷備系統。

周期性地回收舊版本的數據。

定期驗證數據頁面上的CRC碼。

RDMA/SPDK主要用於存儲數據塊傳輸，以及RAFT member 之間數據傳輸。

CynosDB 事務與並發

在RDBMS中採用並發控制保證數據的一致性和隔離性, 三種並發控制機制：Multi-version Concurrency Control(MVCC),Strict Two-Phase Locking (S2PL), 和Optimistic Concurrency Control (OCC), PostgreSql 使用Serializable Snapshot Isolation (SSI)的 MVCC，新數據項將直接插入相關表頁面，在讀數據項時，通過應用可見性檢查規則來選擇合適版本的數據項來響應單個事務，使用SSI 進行DML（數據操作語言，例如SELECT，UPDATE，INSERT，DELETE），使用2PL進行DDL（數據定義語言，例如CREATE TABLE等）。

CynosDB 緩存管理

緩存管理器管理共享內存和對象存儲之間的數據傳輸，包括緩存表(buffer table), 緩存描述符(buffer descriptors), 緩存池(buffer pool)，所有數據文件的每個頁面分配唯一標記，即緩衝標記buffer_tag，buffer_tag包含三個值：RelFileNode，ForkNumber，BlockNumber。如buffer_tag "（201808,0,9）" 表示第9個塊中的頁面，其OID和fork號分別為201808和0。參考 buf_internals.h

CynosDB 載入數據頁

[ 圖5 CynosDB 載入新頁 + 淘汰演算法]

假設訪問的數據頁不在緩存中，且當前緩存滿，需淘汰頁（如是臟頁，則需刷新臟頁），然後載入新頁

根據要讀取的數據頁構造一個buffer_tag, 如（TAG_Q），然後通過內置的哈希函數計算出 bucket slot，獲取 BufMappingLock 中該Slot對應區域的共享鎖，檢查緩存表中是否存在該數據頁，沒有該數據頁，則釋放共享鎖。

使用時鐘掃描演算法（clock-sweep）選擇要淘汰頁所在緩存池的Slot，從緩存表中獲得舊的包含buffer_id的數據項，如「Tag_F，id = 5」，並設置該緩存描述符的狀態為PIN。

如果該數據頁不是臟頁，則進入步驟4，否則需把該頁刷新到對象存儲，從該緩存描述符中獲取 shared content_lock 和 exclusive io_in_progress lock，修改緩存描述符狀態，設置 io_in_progress 位為 "1", 而 valid 位為 0，通過XLogFlush() 把 WAL 緩存中的WAL 數據進行翻譯轉換成 CynosDB 的SLOG（Segemnt LOG），然後並行提交 SLOG 到CynosDB存儲服務，然後修改緩存描述符狀態，設置 io_in_progress 位為 "0", 而 valid 位為 1，釋放 content_lock 和 io_in_progress lock。

獲取包含舊數據條目的 BufMappingLock 的分區，並設置為排他模式。

獲取新數據條目的 BufMappingLock 的分區，並插入新數據條目（TAG_H, id=5）到緩存表。

刪除舊數據條目，並釋放舊BufMappingLock 的分區。

從存儲服務載入數據頁到緩存池中對應的slot中，更新該slot對應的緩存描述符相關標誌信息flags，設置 dirty bit 為0，並初始化其它 bit。

釋放 BufMappingLock 中該Slot對應區域的排它鎖。

後端進程讀取緩存池 buffer_id = 5的數據。

CynosDB 寫流程

[ 圖6 CynosDB 寫入過程 ]

CynosDB寫操作將所有數據頁或索引頁的修改（包括插入，刪除或提交操作）作為歷史數據SLOG寫入持久存儲，以應對故障，當事務提交/中止時，立即寫到存儲系統，以下是寫數據 A 到TABLE_A 的過程:

接收到第一個INSERT語句時，CynosDB 在共享緩衝池創建空白頁，然後在頁面上寫入元組"A"，創建XLOG記錄寫入LSN_1的 WAL緩衝區，同時創建修改數據頁的SLOG 保存在PLOG緩衝區（雙向鏈表數據結構），然後將緩衝池中TABLE_A的數據頁上的LSN從LSN_0更新為LSN_1，同時創建另一條SLOG保存在PLOG緩存區，後期CynosDB 將取消 WAL 緩存。

接收到提交事務命令，CynosDB創建提交操作的XLOG記錄並寫入WAL緩衝區，創建SLOG 寫入PLOG緩衝區，然後將PLOG緩衝區中的所有SLOG記錄根據映射規則分發到 SLOG 緩衝區中指定的SegmentGroup區域，並鎖定等待刷新結果，而刷新線程將 SLOG 批量成組(Batch Group Commit)發送到 Store Node，等待Store Node 發送ACK響應，接收到響應後，取消鎖定等待，完成該事務提交。

說明：關於全頁寫，因後台寫進程刷臟頁時，由於機械盤故障導致數據頁損壞，而且根據XLOG記錄無法在損壞的頁面上重放來恢復（可通過全量XLOG恢復，但代價極大），故PostgreSQL採用全頁寫方式來解決此問題，在每個檢查點後，每個頁面的首次更改時將整個頁面作為XLOG記錄，這種XLOG記錄也稱為備份塊，CynosDB 對此進行優化，移除全頁寫和 Checkpoint.

CynosDB 恢復

傳統的資料庫都依賴於類似ARIES恢復協議來實現故障恢復，而CynosDB 使用狀態機複製技術 State machine replication來避免故障恢復, 不需要REDO恢復，這是因為CynosDB 只會將已經提交的更新寫入到存儲。由於重做日誌應用程序與資料庫實例分離，交給存儲層，在存儲層以並行、非同步、分散式的方式進行REDO操作，所以資料庫可以很快恢復。資料庫實例啟動後，將與存儲服務協同恢復以重建其運行時狀態，首先從資源管理器獲取該資料庫實例所擁有的SG（Segment Group），計算出每個Segment的VDL，產生截斷範圍，消除VDL之後的日誌記錄（SLog的LSN大於VDL的記錄），對該範圍內的日誌進行存儲，產生新的VDL。