Amazon新一代云端关系数据库Aurora（上）

本文由  网易云 发布。

做者：郭忆

本篇文章仅限内部分享，如需转载，请联系网易获取受权。

 

在2017年5月芝加哥举办的世界顶级数据库会议SIGMOD/PODS上，做为全球最大的公有云服务提供商，Amazon首次系统的总结了新一代云端关系数据库Aurora的设计实现。Aurora是Amazon在2014 AWS re:Invent大会上推出的一款全新关系数据库，提供商业级的服务可用性和数据可靠性，相比MySQL有5倍的性能提高，并基于RDS 提供自动化运维和管理；

 

通过2年时间发展，Aurora已经成长为AWS 客户增加最快的云服务之一，包括全球知名的在线游戏网站Expedia、社交游戏公司

Zynga都在使用Aurora。Aurora的推出一时引发了国内数据库研究人员的热烈讨论，你们关注的一个焦点就是Aurora是不是基于MySQL推出的一个新的存储引擎？下面咱们就根据会议发布的论文，一块儿走进Aurora。

 

为何要有Aurora？

 

 在理解Aurora设计的初衷以前，咱们首先来了解一下AWS RDS MySQL的高可用部署架构设计。与咱们以前的猜想是一致的， AWS RDS是基于EC二、EBS这样的云基础设施构建的，数据库实例部署在EC2内，数据盘由一组经过镜像实现的两副本EBS提供。

 

为了实现跨数据中心的高可用，Primary和Replica分别部署在两个可用域内，数据同步采用相似DRBD的方式在操做系统内核经过块设备级别的同步复制实现，因此AWS RDS的Replica平时是不能被读取的，只能用于跨可用域的故障恢复。Replica与Primary是彻底对称的，经过内核复制到replica的数据一样存放在一组镜像实现的两副本EBS中。从图中能够看到，这样的一个部署架构，数据库发起的一次写IO须要同步复制5次，其中3次仍是串行的，网络延迟对数据库的性能影响很是严重。

 

MySQL的InnoDB存储引擎听从WAL协议，全部对数据页的更新都必须首先记录事务日志。此外，MySQL在事务提交时，还会生 成binlog；为了保证被修改的数据页在刷新到硬盘的过程当中保证原子性，Innodb设计了double-write的机制，每一个数据页会在硬盘上写两遍。此外，MySQL还有元数据文件（frm）。在AWS RDS的高可用架构中，全部的这些日志文件、数据文件都要通过网络的传输5次，对网络带宽也是巨大的考验。

 

这样的一个架构因为不涉及具体数据库内核的改动，知足了AWS发展初期能够快速支持多种类型的关系数据库的需求，可是显然随着规模的增加，这样的架构的缺陷也愈来愈明显。当咱们还在考虑如何优化咱们的网络性能和IO路径时，AWS的注意力已经转移到如何来减小数据在网络上的传输，这就有了后来Aurora的架构。

 Aurora的系统架构

 

Aurora与传统关系数据库相比，最大的一个架构上的创新就是将数据和日志的管理交由底层的存储系统来完成，数据库实例只负责向存储系统中写入redo log。因为底层存储节点挂载的是本地硬盘，日志的持久化和数据页的更新并不须要跨网络完成，因此只有redo log须要经过网络传输。因为MySQL的redo log中包含了对某个数据页的某行记录的更新，经过redo log以及先前的数据页能够构造出更新后的完整页面，因此Aurora选择经过redo log创建起数据库实例和底层存储系统之间的关系。

 

在Aurora中，数据库实例负责处理SQL查询，事务管理，缓冲池管理，锁管理，权限管理，undo管理，对用户而言，Aurora与MySQL 5.6彻底兼容。底层的存储系统负责redo log持久化，数据页的更新和垃圾日志记录的回收，同时底层存储系统会对数据进行按期备份，上传到S3中。底层存储系统的元数据存储在Amazon DynamoDB中，基于Amazon SWF提供的工做流实现对Aurora 的自动化管理。

 

存储系统的设计

 

Amazon为Aurora实现了一个高可用、高可靠、可扩展、多租户共享的存储系统。

 

多副本

为了实现数据的可靠性，Aurora在多个可用域内部署了多个数据副本，基于Quorum原则确保多个副本数据的最终一致性。

Quorum原则要求V个数据副本，一次读操做必需要读取Vr个数据副本，一次写操做必需要同时写入Vw个数据副本，Vw和Vr须要知足:Vw + Vr > V，且 Vw > V/2。Quorum原则能够确保一份数据不能被同时读写，同时也确保了两个写操做必须串行化，后一个写操做能够基于前一个的结果进行更新。

 

通常最小的Quorum要求最少3个数据副本，Vr = 2 ，Vw =2，在云环境中，就是3个可用域，每一个可用域一个数据副本，一个可用域不可用，不影响数据的读写。可是在真实的场景中，一个可用域不可用的同时，另一个可用域颇有可能也出现故障，为了解决上述问题，Aurora采用了6副本数据，每一个可用域2个数据副本，一次写操做须要4个数据副本，一次读操做须要3个数据副本。这 样的设计能够实现：

1. 在一个可用域内两个数据副本同时失效，同时另一个可用域内的一个数据副本失效，不影响整个系统的读；

2. 任意两个数据副本同时失效，不影响系统的写；

 

分段存储系统设计

任何一个高可用系统设计的前提假设都是在一段时间内，连续两次发生故障的几率足够的低。对于Aurora基于Quorum的多副本设计而言，若是一个AZ的副本失效，在修复过程当中，同时再有一个副本失效，则整个系统将不可写；若是在AZ+1的副本失效的同时，又有一个副本再失效，则系统将不可读。咱们没有办法去阻止连续故障的发生，可是咱们能够经过缩短前一次故障的修复时间，从而下降连续两次故障出现的几率，这就是分段存储设计的思想来源。

 

Aurora将一个数据库实例的数据卷划分为10G固定大小的存储单元，这样能够确保每一个单元数据能够快速的恢复。每一个存储单元有6个副本，每一个可用域内2个副本，6个副本组成了一个PG（Protection Groups）。物理上，由一组挂载本地SSD的EC2云主机充当存储节点，每一个存储节点上分布了不少存储单元。一组PG构成了一个Aurora实例的数据卷，经过分配更多的PG，能够线性扩展数据卷的容量，最大支持64TB。

Segment是存储系统故障恢复的最小单元，之因此选择10G大小，若是过小，可能形成元数据过于庞大，若是太大，又可能形成单个Segment的修复时间过长，通过Aurora测试，10G大小的Segment数据恢复时间在10Gbps的网络传输速度下，只须要10秒时间，这样就确保了存储系统能够在较短的时间内完成故障修复。Segment的元数据由一个DynamoDB来负责存储。

 

 基于Segment和Quorum的设计，Aurora能够经过人工标记一些Segment下线，来完成数据迁移，对于热点均衡、存储节点操做系统升级更新都很是有帮助。

 

 以日志核心的数据库

 

事务日志的写入

在MySQL数据库InnoDB存储引擎中，全部数据记录都存储在16K大小的数据页中，全部对行记录的修改操做，都首先必须对数据页进行加锁，而后在内存中完成对数据页行记录修改操做，同时生成redo log和undo log，在事务提交时，确保修改操做对应的redo log持久化到硬盘中，最终被更新的数据页经过异步方式刷新到硬盘中。redo log确保了数据页更新的持久化，每一个redo logrecord都有一个惟一标识，LSN（log sequence number）,标识该记录在redo log文件中的相对位置。为了确保一个更新操做对多个数据页，或者一个数据页内部多条记录的修改原子性，一个事务会被切分红多个Mini-transaction(MTR)，MTR是MySQL内部最小执行单元，在Aurora中，MTR的最后一个redo log record对应的LSN，称为CPL(Consistency Point LSN)，是redo log中一致点。

 

在每一个MTR提交时，会将MTR生成的redo log 刷新到公共的log buffer中，在MySQL内部，通常log buffer空间满，或者wait 超时，再或者事务提交时，log buffer中的redo log会被刷新到硬盘中。在Aurora中，每一个PG都保存了一部分数据页，每一个redo logrecord在被刷新到硬盘以前，会按照redo log record更新的数据页所在的PG，划分红多个batch，而后将batch发送到PG涉及的6 个存储节点，只有等到6个节点中的4个的ACK，这个batch内的redo log record才算写入成功。最新写入成功的MTR的最后一个记录对应的LSN，咱们成为VDL（ Volume Durable LSN ），这个点以前的MTR对数据页的修改，都至关于已经持久化到存储系统中。

 

存储节点对事务日志的处理

每一个存储节点在接收到redo log record batch以后，首先会将其加入到一个内存队列中，而后将redo log record持久化到硬盘后，返回ACK 给写入实例（Primary）。接下来，因为每一个存储节点可能保存的batch不完整（因为Quorum 4/6机制），因此须要经过与同一个PG下的其余存储节点进行询问，索要缺失的batch。

 

Aurora中存储节点对数据的管理采用了log-structured storage方式，每一个PG的redo log record首先按照page进行归类，同一个page的redo log record在写入时，直接append在该页面以后，页面中的已有记录会有一个链接指针，指向最新的记录版本。

 

除此以外，每一个PG内的每一个segment上的redo log record都包含一个指针，指向他的前一个log record，经过这个指针，咱们很容易判断每一个Segment上的log record完整性，若是缺失，则可已经过与其余的存储节点进行询问，补齐缺失redo log record。

 

数据页的合并和旧版本记录的回收

相似HBase、Cassandra采用LSM Tree的NoSQL系统，Aurora也须要有一个垃圾回收和数据页合并的过程。在MySQL中，脏页的刷新是经过Check point的机制来完成的，redo log的空间是有限的，必需要将redo log涉及的数据页持久化到硬盘中，redo log 空间才能释放，新的redo log 才能写入，因此MySQL的脏页刷新与客户端的事务提交是密切相关的，若是脏页刷新过慢，可能致使系统必须等待脏页刷新，事务没法提交。另外，Check point机制也决定了脏页是否刷新是根据整个redo log大小来决定的，即便一个页面只是偶尔一次更新，整个数据页在check point推动过程当中，都必须从新写入，同时为了确保一个数据页的完整性， MySQL还有double write机制，页面被写两次，代价很是昂贵，显然是不合理的。

 

Aurora的设计更加巧妙，由于数据是有热点的，不一样的数据页的更新频率是不同的，根据每一个Page待更新的redo log record数量，来决定page是否进行合并。

 

纵观Aurora的设计，一个核心的设计原则就是将数据页当作是日志的一个缓存，经过牺牲必定的读，换取了很好的写性能，这是全部基于log-structured system 共性。

对数据库的操做

 

写操做

在Aurora中，同时会存在不少写事务，这些事务会产生大量的redo log record，由于全部的事务在提交时，都必须确保该事务产生的redo log已经写入到底层至少4个存储节点中，考虑到网络和存储节点的IO性能，Aurora中会对写事务进行限制，若是当前分配的LSN大于VDL加上LAL（LSN Allocation limit），则再也不分配新的LSN。

 

提交事务

在MySQL中，虽然在事务执行过程当中，各个事务是并发执行的，可是在提交时，都是串行的，虽然MySQL 5.6推出了Group Commit，能够批量提交，可是在前一个group提交过程当中，其余线程也不得不sleep等待唤醒，这样无疑形成了资源浪费。

在Aurora中，事务的提交彻底是异步的，每一个事务执行完成之后，提交的过程只是将该事务加入到一个内部维护的列表中，而后该线程就被释放了。当VDL大于该列表中等待提交事务commit对应的lsn时，则由一个线程，向各个客户端发送事务提交确认。

 

读操做

在MySQL中，全部的读请求都是首先读buffer cache的，只有当buffer cache未命中的状况下，才会读取硬盘。Buffer cache的空间是有限的，在MySQL中，经过LRU的机制，会将一些长时间没有被访问的数据页占用的buffer空间释放。若是这些页面中包含脏页，则必需要等到脏页刷新到硬盘之后才能释放。这样就确保了下次读取该数据，必定可以读取到最新的版本。

在Aurora中，并不存在脏页刷新的过程，全部数据页的合并都是由底层存储节点来完成的。因此与MySQL实例脏页刷新向上看不一样，Aurora须要向下看，经过将Page LSN大于VDL的数据页释放，能够确保，全部Buffer中Page涉及的更新都已经持久化到硬盘中，同时在cache未命中的状况下，能够读取到截止到当前VDL的最新版本的数据页。

因此在Aurora中，Buffer Cache更像是一个纯粹的Cache。

在Aurora平常读取中，并不须要达到3/6的Quorum，由于有VDL的存在，咱们能够根据读请求发起时的VDL创建一个readpoint，找到包含小于VDL的全部完整log  record的存储节点，直接进行读取。经过同一个PG内部的Segment之间的相互询问，能够创建一个PG的最小的read point，该read point如下的log record实际上才能够被回收合并。

 

 

只读节点

在Aurora中，最多能够为一个writer实例建立15个只读实例，这15个只读实例挂载的是相同的存储卷，只读实例不会额外增长存储的开销。为了减小延迟，Writer实例会将写入到存储系统的redo log日志一样发送给只读实例，只读实例接收到redo log日志后，若是要更新的数据页命中了buffer cache，直接在buffer cache中进行更新，可是须要注意的是，若是是同一个mini-transaction的redo log record，必须确保mini-transaction的原子性。若是buffer cache没有命中，则该记录被丢弃。另外，若是被执行的log record的lsn大于当前的VDL，也不会被执行，直接丢弃。

这样的设计确保Aurora只读实例相较于Writer实例延迟不超过20ms。

本文未结束，敬请期待下篇。

 

网易有数：企业级大数据可视化分析平台。面向业务人员的自助式敏捷分析平台，采用PPT模式的报告制做，更加易学易用，具有强大的探索分析功能，真正帮助用户洞察数据发现价值。可点击这里免费试用。

 

了解 网易云 ：
网易云官网：https://www.163yun.com/
新用户大礼包：https://www.163yun.com/gift
网易云社区：https://sq.163yun.com/