正文
在无共享集群，可以使用基于认证协议避免主动复制更新事务。每个事务直接在副本上执行，而没有任何先验协调。因此，事务仅需要根据本地的并发控制协议在本地进行同步。仅在提交之前，协调的过程才开始。这个时候，发起协调的副本采用全序组通信原语广播更新。这将导致所有节点采用完全相同的更新序列，然后通过测试可能的冲突获取认证。PostgreSQL-R，Group Replication，Garela等属于这类架构的范畴。由于协调发生在PE与SE之间如图1（e），它能够随着更新密集型工作负载的扩展而执行更细粒度的同步。这方法能够接受存储引擎和磁盘层的物理损坏。
Aurora给人眼前一亮的是它的架构。其体系架构更类似SDP，但是它将更新局限在一个DB服务器上，避免了分布式并发控制协议。Aurora设计者们认为，传统的数据库实现可扩展不管是做Sharding、还是分布式、或者共享存储（Oracle RAC），本质上都是在数据库的不同层面耦合（SNA在应用层，分布式是在SQL层，SDP是在缓存层），扩展后的每个实例的程序栈仍然是原来的多层结构。Aurora认为从成本、部署灵活性及可用性等因素考虑，应该考虑把数据库的各层打开，然后在每个层单独做扩展。传统的数据库系统，例如MySQL、PostgreSQL以及Oracle，将所有的功能模块封装成一个整体，而Aurora则是将数据库的缓冲区管理、恢复子系统从这个整体剥离出来，单独定制扩展。
Amazon声称Aurora完全兼容MySQL，具备商业数据库的性能与稳定以及开源项目的低成本和易用性。下面详细介绍Aurora的设计理念。
相比传统的数据库系统架构，Aurora具有以下三个明显的优点。
首先，在跨数据中心环境将存储作为一个独立的、具有容错以及自修复能力的服务模块，使得数据库系统免受性能抖动和存储或者网络故障的干扰。Aurora设计人员观察到持久层的故障可以认为是系统长时间不可用事件，而系统不可用事件又可以建模为长时间的系统性能抖动。一个设计良好的系统可以无差别地处理这些问题。也就是，Aurora通过底层可靠的存储系统保证数据库系统的服务层级（Service Level Agreement, SLA）。
第二，Aurora的设计理念是日志即数据。通过只将重做日志记录写入存储层，系统可以将网络的IOPS减少一个数据量级。一旦移除了网络I/O瓶颈，在MySQL的代码基础上可以针对各种资源竞争进行大量优化，获得大幅的性能提升。
第三，将数据库系统中一度被认为最复杂与关键的功能（例如重做、备份等）委托给底层的分布式存储。存储系统以异步方式持续在后台并行构造最新版本的数据。这使得Aurora可以达到即时恢复的效果。
存储与计算分离，对于Aurora来说，并不是一个选择题。在Amazon生态下，存储本来就是和计算分离的，从逻辑上看，可以认为系统有一个巨大的共享存储（或许使用的共享存储就是计算节点的本地存储）。Aurora能够做的事情，就是尽可能减少计算与存储之间的带宽需求，这是整个架构的关键所在。
Aurora通过只传输重做日志记录以消除不必要的IO操作，降低成本，并确保资源可服务于读/写流量。与传统的数据库引擎不同，Amazon Aurora不会将修改后的数据库页面推送到存储层，进一步节省了IO消耗。
在开始介绍实现细节之前，我们先给出如下术语定义。
表一 Aurora术语定义
|
术语
|
相应解释
|
|
AZ（Availability Zone）
|
可用数据中心，Aurora中所有AZ位于同一个region
|
|
LSN（Log Sequence Number）
|
日志序列号，数据库系统为每个日志记录生成的唯一记录ID。传统的数据库系统采用文件偏移量表示，在Aurora中利用时间戳标记。
|
|
VCL（Volume Complete LSN）
|
存储节点接收到的最大连续日志ID，这些日志可能还未提交成功。
|
|
SCL (Segment Complete LSN)
|
Aurora中数据分片对应的最大连续日志ID，节点利用该变量与其它节点交互，填补丢失的日志记录
|
|
CPL (consistency Point LSN)
|
在数据库层面，事务被分成多个MTRs（Min-Transactions）。每个MTR产生的最后一个LSN为一个CPL
|
|
VDL (Volumn Durable LSN)
|
VDL为最大的CPL，其中CPL ≤ VCL;在系统恢复阶段需要通过多数派读确定VDL
|
下面具体介绍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。
这样的配置使得系统可以容忍：
