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

具体来讲存储节点执行如下工作：

1. ?存储节点将主实例发送的redo日志放入内存队列,然后将日志从队列移出,持久化到磁盘(这个过程是批量操作).
2. 存储节点给主节点发送一个ACK,告诉主节点数据持久化过程已经完成.这个步骤完成以后,主实例与存储节点的交互就已经完成.从Aurora的角度看来,这两个步骤是执行路径上的关键路径,影响系统的吞吐量以及相应时间.此后的步骤与主实例的通信可以独立,异步的方式进行.
3. 一旦存储节点生成日志文件,它就立刻开始整理这些日志记录以便发现它遗漏了某些日志记录.
4. 运行点对点的Gossip协议,将遗漏的日志记录补上.(通过Gossip协议,它们可以知道集群中有哪些节点,以及这些节点的状态如何?每一条Gossip消息上都有一个版本号,节点可以对接收到的消息进行版本比对,确保二者得到的信息相同).这个阶段过后,每个节点上的数据是相同的拷贝.
5. 将日志记录合并,生成最新的版本的数据,转换成数据库需要的数据块.
6. 以很高的频率将生成的数据块备份到S3.这个Point-in-time快照技术保证故障恢复的时候可以将数据库恢复到之前特定时间点的一致性状态.通常有两种方法保证Point-in-time快照捕捉到最近的更新.一种方法是指针重定位.当最新版本的Point-in-time快照被创建的时候,它维护一个指针指向原来的快照.另外一种方法是增量维护,只是拷贝被更改的数据.
7. 运行垃圾回收机制,清理过时的数据块与日志文件.
8. 定期扫描数据块,进行校验.如果发现损坏数据块,与相邻节点进行通信获取完好的数据块.这是Aurora实现可自主修复损坏数据块的关键技术.

以上8个步骤具体见图3.

图3 主实例与存储节点的交互

当主实例收到4个以上的日志持久化ACK以后就完成事务提交,可以将执行结果返回给客户端.

从Aurora的写步骤看来,系统只需要等待写入存储节点的日志返回ACK即可,这是写操作的唯一需要同步执行的地方.系统将大部分计算下推到底层的存储层.因为只需写入redo日志,Aurora也可以极大地减少网络IO.从这个角度看来,评价Aurora是一款优秀的专为云计算而设计的DBMS,一点都不为过.

2、Aurora读操作

虽然Aurora对写操作进行了优化,仅仅写入delta更新(redo日志)；但是系统的读操作还是以块为单位.如同传统的数据库系统的做法,读事务首先在缓冲区里查找所需的数据块.如果存在,直接读取即可；否则将请求下发到存储系统.如果系统缓冲区已满,那么需要淘汰一个页面来装下新读入的数据页.在已有的系统中,如果被淘汰的数据页是脏页,那么需要写回磁盘.这可以确保随后的事务都可以读到最新版本的数据.

上面我们已经介绍了,Aurora并没有将数据页写回存储系统,只是简单地将相应内存空间标记为free.但是,Aurora满足类似的条件：缓冲区里的数据都是最新的.这个条件的保证通过将缓冲区里页面LSN(关联该页面最新修改操作的日志记录的LSN)大于文件持久化位点VDL的数据页置换掉.

这个协议确保了：

1)页面的所有改动都已经持久化到日志

2)在缓冲没有该数据页的情况下,可以构造出当前VDL的页面.

随着系统提交事务的不断确定,VDL会不断往前推移.最终VDL会大于修改页面的PageLSN.此时,为了让读操作能够读到最新的数据,系统有两种选择：

• 其一是,重放操作组件将LSN ≤ VDL的日志记录应用到相应的数据页产生最新版本的数据；
• 其二是,在读操作的时候将旧版本数据页与delta更新(日志记录)进行合并(amazon采用何种方式将缓冲区中的页面变成最新版本的数据并没有说明,但是Log structure结构的数据组织方式决定了Aurora只能采用上述两种处理方式).

系统只有在故障恢复重启的时候会采用多数派读的方式来确定系统的VDL.正常情况下,读操作并没有采用多数派读的方法.Aurora给读操作指派一个读位点(read point),代表着读请求产生时刻的VDL.系统维护着对应存储节点的SCL,知道哪些节点可以满足当前的读操作.

3、事务提交

Aurora采用的是异步成组提交技术.在传统的数据库中,例如MySQL,为了减少磁盘IO采用成组提交技术.第一个写日志缓冲区的线程需要等待预先设定的时间,然后再执行磁盘IO操作；或者等到日志缓冲区页写满以后再执行IO操作.这样子做的结果是第一个写日志缓冲区的线程需要挂起等待,耗费时间.这是一个同步操作,在持久层存储的ACK返回之前不能进行其它工作.

在Aurora中,写操作不仅仅依赖Linux文件系统,还需要跟网络交互.第一个写日志缓冲区的线程可以马上开始执行IO操作.每个提交事务都无需等待.线程将事务移动到提交列表,写下该事务的commit LSN,转而执行其他工作.在某个时刻,后台进程负责将这些日志记录收集起来,批量发送到存储节点.当主实例收到对应某批次的日志记录的4个ACK,VDL向前推移.系统有一个专门的线程不断检查提交事务队列中commit LSN ≤ VDL的事务,然后回复客户端.这等价于WAL协议.

在图3中,提交队列里面有3个挂起的提交请求,分别是Pending commit group1,Pending commit group2,以及Pending commit group3.主实例收到针对Pending group commit1的4个以上的日志持久化ACK以后,将系统VDL前移至22,第一组的状态从pending变成committed.此时后台线程检查提交队列,然后成批提交LSN小于等于22的事务T1,T2,T3.

注意,即使后面Pending commit group3先于Pending commit group2收集4个以上的存储节点返回的持久化ACK,那么也不能移动数据库持久化位点.因为,这个数据库持久化位点是Aurora崩溃恢复以后决定开始重做的位点.跳过前面的成组提交的LSN会导致数据库丢失某些数据.在系统崩溃恢复的时候,系统检索最新的数据快照与相应的日志记录(其LSN大于数据库持久化位点),即可将数据库恢复到最新的一致性状态.

（编辑：ASP站长网）