欢迎来到尧图网

客户服务 关于我们

您的位置:首页 > 文旅 > 艺术 > AWS Aurora存算分离架构

AWS Aurora存算分离架构

2025/4/2 8:27:00 来源:https://blog.csdn.net/Revendell/article/details/146780501  浏览:    关键词:AWS Aurora存算分离架构

 Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases

1 Amazon Aurora的特点

  • 高性能、高可用
  • 简单、成本低
  • 兼容Mysql和PostgreSQL协议
  • 按需付费

2 Aurora的云原生数据库架构

2.1 传统数据库架构瓶颈
  • 存储计算紧耦合:存算分离好处是第一云上可以按需付费,存储和计算分开按需计费,我觉得这是Aurora选择存算分离的核心原因,这是一开始Amazon设计的产品形态,你必须这么做客户才认同客户才不明觉厉,客户才会对你的产品有认同度才会买单;第二​可扩展性好,存储与计算独立扩展,按需分配;第三存储与计算分离资源隔离性更好,可以实现serverless;存算分离的缺点就是更大量的网络和存储流量。
  • ​I/O路径冗长
  • 扩展性受限
2.2 Aurora创新架构
2.2.1 日志即数据库

通过日志流重构数据库页面,任意时间点页面可通过日志流重建。我觉得Aurora之所以提出这个观点是倒果为因,Aurora设计之初就是想到存算分离架构,好处是基于2.1的分析,所以Aurora需要克服最大的问题就是网络数据传输量,所以Aurora核心的理念就是要减少数据的网络传输量,Aurora 为了减少 IO 的数量,所有节点之间的数据传输,只有 redo,而不传输data page,所以Aurora提出log is database,这就变成了Aurora的特性了。因此Aurora 下推到存储的主要功能主要和 redo 相关,包括:日志回放、故障恢复和备份还原。计算层保留了查询处理、事务处理、缓存管理、锁管理、访问控制等大部分功能。Aurora通过分布式存储带来了分布式能力。Aurora选择存算分离架构,同时计算层是基于Mysql的魔改,计算层这一层架构基本上动不了,Aurora又得实现分布式多副本的可靠性,因此只能想办法如何给予分布式存储实现分布式能力,所以这套架构呼之欲出,PolarDB也是类似。

2.2.2 将检查点任务转移至存储设备

问题一:

仅依靠日志流进行页面读取是不切实际的(太慢)。解决方案是使用定期检查点。

问题二:

数据库实例承担检查点任务。解决方案是使用分布式存储集群进行持续检查点。

2.2.3 存算分离

存储和计算分离后,计算和存储具有不同的生命周期。存算分离的好处:计算实例失败并可被替换、随时被关闭以节省成本、根据负载需求进行扩大/缩小/卸载。存储节点必须具有长久的使用寿命。因此存算分离实现可扩展性、可用性和耐用性。

2.3 Aurora的IO流

主实例会异步向副本实例发送 redo log,副本实例收到后开始回放。如果日志对应的 page 不在 本地的 page cache,该 redo log 可以直接丢弃,因为存储节点拥有所有的 page 及 redo log,有需要时直接从存储节点请求即可。

存储节点收到 redo log 后会持久化,而回放日志和回收旧版本数据页的工作,可以一直异步在后台执行。存储节点可以较为灵活的分配资源做前台/后台的工作。同时相较于传统数据库,Aurora 不用后台去推进 checkpoint(这个动作往往会影响前台请求),分离的存储层不断地推进 checkpoint,对数据库实例丝毫没有影响,而且推进的越快,对读请求越有利。

存储层不断推进 checkpoint 也能加快故障恢复的速度,一般情况下,在 10w TPS 压力下,Aurora 可以在 10s 恢复完成。

Amazon Aurora 存储节点中的 I/O 流

(1) 存储节点接收主实例的日志,追加到其内存队列。

(2) 存储节点持久化日志后应答主实例。

(3) 按分片归类日志,确认是否有日志丢失。

(4) 与其它存储节点交互,填充丢失日志。

(5) 回放日志,生成数据页。

(6) 定期备份数据和日志到 S3。

(7) 定期回收过期数据页版本。

(8) 定期 CRC 校验数据页。

• 所有步骤都是异步的

• 只有步骤 1 和 2 属于前台延迟路径

为了保证可用性,Aurora 持久化采用 Quorum 协议。假设复制集合包含 V 个节点,读请求需要得到 Vr 个节点响应,写请求需要得到 Vw 个节点详细,为了保证读写一致性,Quorum 协议主要有两个条件(1)Vr + Vw > V ;(2)Vw > V/2。

主实例的每次写入会发送到位于 3 个 AZ 的 6 个存储节点,收到 4 个持久化成功的回复便认为写入成功。因此 Aurora 的 Quorum 协议中,V = 6,Vw = 4,Vr = 3。当然在实际读请求中,不用真的去 3 个存储节点查询,只需要查询拥有最新数据的那个存储节点就行 。

Quorum 协议可以保证,只要 AZ 级别故障和节点故障不同时发生,数据库的可用性就能得到保证。同时 Aurora 采用分片管理的策略,每个分片 10G,6 个 10G 的副本组成一个 Protected Group,每个分片是一个故障恢复的单位,在 10G/s 网络下,一个分片可以在 10s 内恢复。因此只有当 10s 内同时发生超过2个分片的故障,可用性才会受到影响,这几乎是不可能发生的。

sysbench write only 测试,Aurora是基于镜像MySQL吞吐能力的35倍,每个事务的日志量比基于镜像MySQL日志量要少7.7倍。

总体来讲,Aurora 存储计算分离的架构带来了如下好处:(1)在云上部署,所有节点之间只传输 redo,网络压力小。(2)前后台线程互不干扰,后台任务可以不停歇的异步执行。(3)存储节点跨 AZ 高可用。(4)读副本、存储节点可线性扩展(有上限)。(5)故障恢复时间快。

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com

热搜词