本文由云 + 社区发表
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 的回档也就完成了。
此文已由作者授权腾讯云 + 社区发布