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

图4. Aurora成组提交细节

4、恢复

大多数据库系统的恢复协议采用类ARIES算法,依赖WAL日志将数据库系统向前滚动到最新状态.系统周期性地建立检查点,将脏页写回磁盘,同时将检查点记录写入日志.系统重启的时候,页面遇到丢失提交数据或者包含未提交数据.此时,恢复子系统将最新检查点以后的redo日志进行重放,然后利用undo日志撤销未提交事务的修改.通过这两个步骤就可以将数据库恢复到最新一致性状态.灾难恢复是一个很昂贵的操作,增加系统建立检查点的频率可以减少恢复时间.但是,建立检查点会干扰正常执行的事务.Aurora并不需要做这样子折中.

Aurora将恢复子系统的功能完全从事务的执行路径上剥离出来,交给下面的存储层.存储节点持续以并行、异步、分布式的方式进行redo操作无需在性能与恢复时间上进行权衡.图5给出了传统DBMS与Aurora的恢复方式对比.

Aurora将数据库文件切分成10GB大小的块,每个块都有专属的日志记录.在崩溃恢复的时候,系统利用多数派读,确定运行时的一致性状态.恢复模块首先确定最大VCL(最大的顺序LSN),截断此后日志.进一步,可以将需要重放的日志限制在其LSN ≤ CPL.VDL取最大的CPL,LSN大于VDL的日志记录都可以安全地截断.例如,最大已完成的日志记录的LSN为1007(尚未提交),但是系统的CPL为990,1000,1100.系统可以确定LSN大于1000的日志记录都可以忽略.确定完重放日志的LSN最大值以后,redo操作就可以并行在不同segment上执行了.

根据官方记载,Aurora完成崩溃恢复所耗费的时间大概是60S~120S左右.如果有其它副本存在,用户可以指定主实例发生故障以后各副本提升为主实例的优先级,不会出现单点故障的情况.对比MySQL,重放操作只是单线程的模式进行,在系统更新负载较大的情况下,MySQL的故障恢复时间通常会比较长.为了及时更新备机上的数据,主实例需要将redo日志发送备机.备机收到redo日志以后,查找数据缓冲区.如果存在对应的数据块,则将根据redo日志描述的操作应用在该数据块上(日志LSN需要满足小于等于VDL).否则,简单地抛弃对应的日志记录即可.数据页的读入操作要等到对该数据页的请求到来的时候.

图5. 传统DBMS与Aurora的恢复方式对比

三、总结

Aurora的设计让我想起PBXT DBMS.PBXT作为MySQL的可插拔存储引擎,定位在支持高并发场景.它没有采用update-in-place的做法,而是利用append的方式进行更新,这减少了维护高速缓存一致性的开销.同时,最近的工业界与学术界也都大致认同append更新方式对于Flash比较友好.最主要的是PBXT的设计哲学也是“log is database,write-once”,可以看见Aurora的影子.有兴趣的同学可以看看研究下PBXT的源码,或许更能加深对Aurora的理解.

总而言之,Aurora是针对云将MySQL进行深层定制的数据库.Amazon通过紧密集成数据库引擎和基于SSD的虚拟化存储层(专为数据库工作负载而开发),其性能和可用性相较于MySQL有大幅提升.通过降低了存储系统的写入次数使之更好的适应云环境的特点.Aurora在自动拓展存储容量、自动修复数据、服务宕掉或者重启时对缓存持久化的处理方式都是很有创新性的.最后是Aurora在RPO,RTO,兼容性以及扩展性方面的总结.

根据amazon官方文档提供的参数[1],Aurora支持Point-In-Time?Recovery将数据库还原到指定时间点,通常能够在60s左右的时间完成故障恢复,不会高于120s.在2017年数据库顶级会议SIGMOD上[2],Amazon公布了Aurora与MySQL5.6&5.7的性能对比：r3.8xlarge实例规格,sysbench压测,Aurora的性能要比MySQL5.6与5.7优10倍以上.

表二 Aurora特性描述

参考文献：

[1]?http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/UserGuide/Aurora.Managing.html
[2]?Amazon?Aurora:?Design?Considerations?for?High?Throughput Cloud-Native?Relational?Databases

文章来自微信公众号：DBAplus社群

（编辑：ASP站长网）