TDSQL-C for PostgreSQL 主从架构详解_tdsql-c 缺点

TDSQL-C PG 版整体架构

在介绍整体架构前，先说一下为什么我们要做 TDSQL-C 这款产品。在传统数据库上，数据库的使用是存在一些问题，主要分为以下四个：

第一是资源利用率低，计算和存储在一台机器上，CPU 和磁盘使用不均衡，例如 CPU 用满，但磁盘很空闲或者 CPU 很空闲但磁盘又满了，这样就会导致资源利用率低。

第二是扩展能力不足，在单排上可能不能满足一些用户要求，无法扩展。

第三是资源规划难，例如用户使用数据库，一开始无法预估这个数据库需要多少次磁盘空间。

第四是备份比较困难，因为每一个实例数据是私有的，所以每个实例都需要单独进行备份。

TDSQL-C 的解决思路：

第一个问题是计算存储分离，计算资源可以弹性调度。例如说可能给用户分配一个 4 核 8G 存储资源，一段时间以后会发现这个无法满足他要求，那可以给它分配一个更高规格实例。比如说 16 核 32G 这样一个实例，这个是做计算资源升配。第二个问题是日志下沉以及异步回放，TDSQL-C 的日志是通过网络，从计算层下放到存储层。第三个问题是共享分布式存储，我们 TDSQL-C 地域的所有实例，在底下是共享一个分布式存储，可以动态向一个实例里添加资源。最后一个是后台持续备份，我们的后台有定期备份任务，将日志和数据备份到地上存储上面。

PG 实例，包括主实例和读实例，主的负责读写，只读是负责数据读取。在 PG 下有一个叫 CynosStore Agent 组件，它主要负责存储层进行通信，包括主的写日志、读页面，从的是读页面。再向下是存储服务或叫 CynosStore，采用的是 RAPS 结构，一主两层。右边是集群管理服务，是对 CynosStore 里存储节点进行管理服务。包括故障迁移是一个节点发生故障然后迁到其它节点功能。

另外一个当需要扩展资源时，也是由这个集群管理服务来实现。下面是对象存储，我们会定期在对象存储备份日志和数据。这里涉及几个核心架构：一个是日志下沉，计算节点产生的日志是通过网络，下沉到存储层。存储层是通过异步方式来回访日志，导出页面上去。另外是我们会提供一个多版本读的能力，PG 上层可能会有多个 Buffer 会话去读这个数据，每个开始时间不一样，可能会读到不同的版本。

介绍一下日志下沉、异步回放这部分。这里边涉及几个概念：

第一个是数据原子修改，我们叫 MTR。当中有很多情况是一个数对应一个数据库要修改多个页面，例如想对数字