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

此文已由作者授权腾讯云+社区发布

---