1 系统设计

Aurora是Amazon基于MySQL为云上业务定制的一款关系型数据库产品，主要面向OLTP场景。

Amazon认为，传统数据库一般采用单点写多点读的主从架构，最大瓶颈不在计算或存储，而在网络IO。

 

Aurora通过架构优化，最小化网络IO，提升了系统扩展性和可用性。

 

计算与存储分离

计算层（包含Primary RW DB和Secondary RO DB），包含了大部分核心功能，比如查询处理，事务，锁，缓存管理，访问接口和undo日志管理等。计算层还是一主多从的架构，最多支持15个从节点。

每个计算节点部署RDS HM Agent监控主从节点状态，故障时实现高可用切换。

存储层是个分布式存储服务，可以轻松应对故障。Aurora将部分核心功能(故障恢复，备份还原)下推到存储层进行后台异步执行，并且不影响前台请求处理。

 

日志即数据库

计算层只往存储层写redo日志，大大减少计算与存储节点之间的网络压力，这为提升数据库性能提供了保障。

下图是一主多从、部署在3 Availability Zone的6副本架构的写入过程。主只将redo日志写入存储服务（获得过半数确认后写入成功），同时主也会将这些日志发送到从。

从应用redo日志更新其缓存。

 

 

    存储节点收到写入的redo日志时的处理流程

 

1）接收日志记录并添加到内存中的队列

2）记录在磁盘上并进行 ack 返回

3）对于批量 Redo log 进行整理，确定没有批次丢失

4）与其它副本存储节点进行对齐，从而保障数据自愈能力。通过 Gossip 协议，它们可以知道集群中有哪些节点，以及这些节点的状态，每一条 Gossip 消息上都有一个版本号，节点可以对接收到的消息进行版本比对，确保二者得到的信息相同。

5）日志记录合并到新的数据页

6）定期将日志和新的页面复制到 S3

7）定期进行过期版本垃圾数据回收

8）定期验证 CRC 码页，如果发现损坏数据块，与相邻节点进行通信获取完好的数据块。这是 Aurora 实现可自主修复损坏数据块的关键技术

注意，只有步骤 1 和 2 完成，前台即完成（commit），其它操作都是异步进行。

 

 

2 性能容量

吞吐量最高可以达到标准 MySQL 的 5 倍、标准 PostgreSQL 的 3 倍，成本只有商用数据库的 1/10。

跨三个可用区添加最多 15 个低延迟读取副本。

每个数据库实例最高 64TB。

 

3 优势缺陷

优势：

1）存储节点，计算节点弹性伸缩，按需配比

2）一份存储，对接多个计算节点，多租户存储服务，成本低。

3）只传递redo日志，巧妙的解决写放大问题。

4）实例快速故障恢复

5）架构简单，通过多副本能快速扩展读能力，单个写副本则巧妙地避免了分布式事务等复杂实现。

6）完全兼容MySQL 5.6、PostgreSQL

 

缺陷：

1）适合于读多写少的应用，写水平扩展依赖于中间件方案。

2）SQL层与社区版MySQL一样，复杂查询能力(比如OLAP场景)较弱。

3）单个写副本，无分区多点写能力(用户维度+时间维度)

4）总容量有上限，64TB