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）故障恢复时间快。
