自研数据库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的回档也就完成了。

此文已由做者受权腾讯云+社区发布