什么是 TDSQL-C MySQL版 ---- 数据库开发者视角-CSDN博客

本文链接：https://blog.csdn.net/maray/article/details/130394547

TDSQL-CMySQL版本从单机MySQL演进，实现存算分离，通过云存储的多副本策略进行读扩展，保证服务平滑扩展。读写分离和Serverless架构提供了快速读扩展和计算弹性。主节点的redolog用于只读节点更新数据，当主节点不实时刷脏页时，只读节点可能面临资源压力。

摘要由CSDN通过智能技术生成

我们从设计演化的角度来讲什么是 TDSQL-C MySQL 版本。

首先，我们有了一个纯净版 MySQL。它是一个单机数据库。
存算分离：然后，我们把 MySQL 的存储引擎拿掉，换成云存储。这就成了存算分离。这时，在用户看来它还是一个单机版 MySQL 数据库。
读扩展：接下来，把云存储做成 M 份，其中一份作主，其余作备。上层启动 N 个 MySQL 实例，不同实例读取不同的云存储：只有一个 MySQL 实例读写主云存储，其余 MySQL 实例读取备云存储。M 可以不等于 N。
平滑扩展：由于 M 可以不等于 N，所以云存储和计算节点都可以平滑扩展。所谓平滑的意思是，扩展阶段，原有服务不受损，扩展完成，服务能力提升。
快速读扩展：由于有了读写分离，读节点可以快速扩展和回收，具备良好的计算弹性。
Serverless 架构：由于存算分离，计算节点可以快速启停，所以可以给用户提供 Serverless 体验，无需关心计算节点位置。

在这里插入图片描述

存疑点：

TDSQL-C MySQL 的存储用的是三副本强一致。那么，是说最多三个副本吗？不可以扩展成三个以上？
计算节点之间是会传递 redo log 的，那么，各个只读节点是如何使用这些 redo log 的？

Update:

第二个疑问没有了。计算节点传递 redo log 是因为：主节点不会实时刷脏页到存储层。那么只读节点为了读到新数据，就只能依靠 redo log 更新本地脏页了。这里还可以展开：如果主节点每次隔非常久才刷脏页，那么只读节点可能会面临非常大的资源压力，因为他们也必须保持脏页缓存很久很久。能丢弃脏页吗？不能，因为一旦丢了，就没办法拿到比较新的数据了。

参考文献：