云数据库AWS Aurora最详解读！(2)

首先,在跨数据中心环境将存储作为一个独立的、具有容错以及自修复能力的服务模块,使得数据库系统免受性能抖动和存储或者网络故障的干扰.Aurora设计人员观察到持久层的故障可以认为是系统长时间不可用事件,而系统不可用事件又可以建模为长时间的系统性能抖动.一个设计良好的系统可以无差别地处理这些问题.也就是,Aurora通过底层可靠的存储系统保证数据库系统的服务层级(Service Level Agreement,SLA).

第二,Aurora的设计理念是日志即数据.通过只将重做日志记录写入存储层,系统可以将网络的IOPS减少一个数据量级.一旦移除了网络I/O瓶颈,在MySQL的代码基础上可以针对各种资源竞争进行大量优化,获得大幅的性能提升.

第三,将数据库系统中一度被认为最复杂与关键的功能(例如重做、备份等)委托给底层的分布式存储.存储系统以异步方式持续在后台并行构造最新版本的数据.这使得Aurora可以达到即时恢复的效果.

存储与计算分离,对于Aurora来说,并不是一个选择题.在Amazon生态下,存储本来就是和计算分离的,从逻辑上看,可以认为系统有一个巨大的共享存储(或许使用的共享存储就是计算节点的本地存储).Aurora能够做的事情,就是尽可能减少计算与存储之间的带宽需求,这是整个架构的关键所在.

Aurora通过只传输重做日志记录以消除不必要的IO操作,降低成本,并确保资源可服务于读/写流量.与传统的数据库引擎不同,Amazon Aurora不会将修改后的数据库页面推送到存储层,进一步节省了IO消耗.

在开始介绍实现细节之前,我们先给出如下术语定义.

表一 Aurora术语定义

下面具体介绍Aurora事务的正常读写、提交以及恢复过程.

1、Aurora写流程

图2. Aurora I/O流程

图2所示,系统将数据库文件切分成大小均等的存储块(一个存储块的大小为10GB),这些存储块分布在不同的存储设备上.每个存储块都有专属的redo日志.更新操作只写日志而不写数据页.在适当的时机底层的存储将日志合并成数据页.也就是,计算与存储之间只传递日志,而不传递脏页,页面的合并由存储端来完成(不要把存储端看做是一组单纯的硬盘,它也包含了计算节点,可以把他看成是一组磁盘服务器,类似Oracle ExaData),注意到Aurora的存储格式是基于日志结构的,所以这是一个整体的设计；系统对每个数据块复制六次,分散在三个不同的可用区域AZs.Aurora认为写操作已经持久化,仅当数据(redo日志)至少写入六个备份数据的其中四份.Aurora不支持跨region复制.

系统设计人员采用如此数据副本放置策略的原因主要如下：

在大规模的云计算环境下,底层的磁盘、数据节点以及网络的故障持续发生.每种故障有不同的持续时间以及波及范围,例如,可能节点网络的暂时不可用,重新启动带来的短暂的停机,或磁盘、节点、机架、网络交换机等的永久性故障,甚至是整个数据中心的不可用.在备份系统里面一个常用的容错方法是多数派投票协议.复制的数据项的每个副本都关联一个投票,读写分别对应副本数Vr以及Vw.

为了满足一致性,必须遵循以下两条规则：

1)为了读到最新的数据,必须满足Vr + Vw > V.

这条法则确保写操作涉及的副本与读操作涉及的副本有交集,读操作可以读到最新版本的数据.

2)为了避免冲突,感知最新的写入操作,写操作涉及的副本数Vw 必须满足 Vw > V/2.

通常的做法是容忍一个节点不能正常工作,设置V=3,读多数派为Vr = 2,写多数派为Vw = 2.Aurora的设计人员认为2/3的多数派是不够的.他们将副本数提升为6个.每个AZ上两个数据副本.这样子的话,为了使得读写条件成立,那么Vr = 3,Vw = 4.这样的配置使得系统可以容忍：

• 某个机房垮掉,外加一个副本所在的机器不可用(AZ+1)而不会影响读；
• 损失两个副本,即使这个两个副本位于同一个机房,不会影响写.

那这样子的配置是否足够健壮去容错呢?

Aurora的设计者认为很难去降低两个不相关事件的故障概率(两个副本不可用),于是转而限制平均修复时间,使得在平均修复时间内发生故障的概率几乎不可能.他们将数据库分片限制在10GB大小,在万兆以太网下修复的时间低于10s,而在这个时间段内,一个机房不可用外加一个数据副本不可用的概率几乎为0.这就是他们选择10GB大小的数据分片以及每个分片需要复制6个副本的原因.

在介绍Aurora的更新事务流程之前,我们先看看传统的数据库系统的更新步骤.在类似MySQL的系统中需要将脏数据页写回堆文件或者b树等对象中(延迟写).此外,还需要将WAL日志写入持久层存储.通过重放WAL日志可以产生数据页修改后镜像.实际上,需要写回的数据远不止这些.Aurora设计人员给出了一个MySQL同步镜像的例子.在这个例子中,写回的数据除了数据页、redo日志还包括binlog、避免数据页损坏的双写文件以及元数据文件.写回这些数据会带来的巨大网络I/O,还有就是同步这些文件带来的延迟太大了.

Aurora另辟蹊径,采用并行写多个副本保证可靠性,以及利用“log is database”的思想减少传输的数据.在Aurora中,一个更新事务的完整操作流程如下：

• 同时写多个副本,执行更新操作,但不修改缓冲区中的数据页,仅仅是构造对应的redo日志.
• 存储节点收到主实例发送的redo日志,负责持久化工作.

（编辑：ASP站长网）