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

本文由  网易云 发布。

 

做者：郭忆

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

 

 

故障恢复

 

MySQL基于Check point的机制，周期性的创建redo log与数据页的一致点。一旦数据库重启，从记录的Check point开始，根据redo log，对相应的数据页进行更新，对于已经提交的事务则确保事务更新持久化到硬盘的数据页中，对于未提交事务，利用数据页对应的roll pointer指针找到对应的undo log，进行回滚。MySQL 通常5分钟一个check point，在故障恢复过程当中，由一个线程负责redo log的回放，整个过程数据库实例彻底是停服的。

 

与MySQL 相同的是Aurora 在故障恢复过程时，首先也必需要找到一个一致性点，可是与MySQL不一样的时，这个一致不要求全部的数据页是一致的，Aurora只要求找到VDL，确保日志的一致性。

 

基于read quorum机制，Aurora能够确保对于每个PG，读到知足writer quorum的redo log record，从而创建VDL。对于每一个存储节点，大于VDL的redo log记录将被删除。另外，虽然论文中并无提，可是因为Aurora的Cache是独立于数据库进程的，因此当仅是数据库实例重启时，Cache内Page LSN大于VDL的数据页一样也须要被清理掉，由于这部分数据页对应的redo log并无持久化到存储系统中。

 

创建VDL后，数据库便可以开始进行正常的读写访问。对于没有被提交的事务，因为undo写入的同时也会写redo，而且存在在同一个MTR中，因此undo也是完整的，根据undo能够完成对事务的回滚。可是与MySQL不一样的是未提交事务的回滚是后台异步在存储节点完成的。同时，Aurora的redo log的更新是根据page待修改记录的多少来按需进行合并的，而且因为底层存储系统redo log和数据页分散在多个存储节点的segment上，因此能够并行进行数据页的合并。

 

通过AWS 官方的测试，Aurora在10W 写QPS的压力下，故障恢复只须要10秒。另外值得一提的是，与MySQL Buffer Cache是进程内分配的内存空间不一样，Aurora的Buffer Cache是独立于数据库进程的，这样作的一个好处就是数据库宕机之后，不会丢失热点，固然这也仅限于数据库实例宕机，若是是系统宕机，就没用了。

 

 

性 能

 

测试对象为Aurora，MySQL 5.6，MySQL5.7,分别在5种规格下（最大规格为32 vcpus，244G内存，最小的规格为2 vcpu，15G 内存，每种规格为前一个规格的一半vcpu和内存）的sysbench 纯读和纯写的压测。测试数据量为1G，因此是全内存的测试。

 

 

 

性能对比仍是很明显的，得益于大幅减小的跨网络IO以及基于log-structured storage的数据结构，Aurora在r3.8xlarge规格下写能够达到每秒12W。因为Aurora能够建立多个只读实例，因此Aurora在r3.8xlarge规格下读能够达到60W（文章中并无说起是否 使用了Aurora，可是在全内存场景下，笔者猜想，应该是基于多个replica达到的）

 

更多高级特性

 

在线修改表结构

 Aurora的Online DDL相较于MySQL在实现上也很是有特点，Aurora目前仅支持在线加列（列容许为空），MySQL 5.6开始，加列操做也支持在线，可是体验较差，咱们首先来看一下MySQL 5.6的在线加列过程：

 

MySQL 5.6 的在线加列分为3个过程：

Prepare: 持有MDL(MetaDataLock)排它锁，建立新的frm文件，更新内存数据字典，生成临时idb文件（记录增量），释放排它锁；

Execute:逐行遍历每一条记录，按照新的表结构构造记录，全部的更新操做都被记录在idb文件中；

Commit: 从新持有排它锁，将临时idb文件中的更新回放到表中，若是更新频率很是高，这个时间可能会比较长，最后临时文件被删除，rename新表。

 

这样一个流程实际让咱们想到了利用Percona的Xtrabackup对数据库在线备份和恢复的过程，容许拷贝期间数据的短暂不一致，而后利用拷贝数据期间的row_log日志最终确保全部数据的一致性。

 

这样的设计知足了在线修改表结构的需求，可是因为存在全表拷贝，耗时每每很是长，同时最后阶段的加锁时间也不肯定，在DBA 使用过程当中，每每提心吊胆。

 

Aurora的设计则显得更为巧妙，很容易让人联想到LVM的Copy-on-write在线snapshot设计，修改过程仅仅只是修改原数据，并不涉及具体的数据拷贝，数据的拷贝是在该数据被修改时才完成的。

 

在Aurora中执行一条在线加列的DDL操做很是快，这是由于处理该请求系统只是在一个Schema Version Table的系统表中增长一行记录。接下来的DML，Aurora采用了modify-on-write的策略，以Page为单位，若是一个page的LSN大于加列DDL的LSN，则说明，该page已经被修改了schema，因此在DML发生前，就须要将该数据页按照新的schema格式进行存储。对于读操做，若是这个数据页还没被修改过，则直接在内存里面加一个空列进行返回给客户端。

 

因为Aurora的Online DDL只是增长一条数据库记录，因此速度相比MySQL快了不少个数量级。

 

 

地理位置空间索引

Aurora 与MySQL 5.6一致，支持空间数据类型（Point、POLYGON...）和空间关系函数（ST_Contains、ST_Distance...）， MySQL 5.7 InnoDB也开始支持空间地理索引，对大数据集下的查询性能有很大的提高。Aurora 也支持空间地理索引，可是与MySQL 5.7 R Tree的实现方式不一样，他是经过空间填充曲线对多维数据进行降维，基于B Tree实现的，这个与MongoDB更为相似。

 

 

MySQL 5.7的Spatial Index实际是根据最小边界矩形来构建的R Tree。树顶端的两个节点表明的分别是最外层的两个矩形，每个子树就是该矩形内的全部的节点。而后再根据最小边界矩形规则，构建子节点。当咱们要查询某个范围内的全部节点时，能够经过这个范围跟各个矩形是否有重叠来确认查询范围，从最顶端的两个节点表明的矩形开始查找。若是有重叠，就须要查询该子树内的节点。基于R-tree实现的空间地理索引的缺点在于构建成本比较高昂。

Aurora的实现则是将多维数据首先利用必定的算法（时间空间曲线Z-index）进行降维，转换成字符串，而后利用B-Tree方式进行存储。

 

在线Point-in-time Restore

MySQL 企业版有一个对DBA颇有用的功能就是Flash back，能够实现将数据库在线回滚到指定的时间点，对于误操做或者新上线BUG致使的数据修复很是有用，原理上他是基于Row格式的Binlog(会保存修改的前项和后项)进行逆向执行到指定位置实现的。

Aurora提供了两种针对上述场景的修复功能，在线PITR（Point-in-time restore）和离线PITR，前者是在原实例的基础上直接进行数据回滚，恢复期间数据库是可用的，后者是经过备份恢复出一个新的实例，恢复期间新的实例是不可用的。

与MySQL 基于binlog的逆向执行不一样，Aurora是基于redo log record来实现的。Aurora底层每一个存储节点都会按期对存储节点上全部segment进行快照，与LVM相似，只备份元数据，若是某个segment中的某个block数据被从新写，则须要首先将数据拷贝到指定的区域（purchased rewind storage）,而后更新该block。

当咱们要进行数据恢复时，首先咱们找到要恢复的时间点之前最近的全部存储节点上segement快照，而后根据该快照对应的lsn以后的redo log record就能够完成数据的修复。（rewind window 内的redo log record是不会被清理的）

在不少场景下，咱们一次是没法精肯定位到咱们须要的时间点的，这时候，Aurora会根据redo log recod的可见性来快速实现时间点的前进和后退。如图所示，当咱们从t2时间点恢复到t1时间点时，咱们只须要将t1-t2之间的redo log record不可见便可。当咱们但愿从t4回滚到t3时，咱们只须要将t3-t4和t1-t2之间的redo log record设置不可见便可，固然这必须知足MTR的原子性要求。

 

总  结

 

作架构设计的人有一个共识，没有最完美的架构设计，只有最适合的架构设计。Aurora 应该说就是这种理念最完美的诠释。在计算与存储分离的云基础设施之上，经过仅传输redo log，大幅减小跨网络的IO数据传输，将产生大量IO的数据页合并和持久化交由本地存储来解决，大幅减缓了网络延迟对数据库性能的影响。

另外，基于log-structured storage的数据页合并，相比Check point，能够更加高效的合并针对同一个数据页的更新，这些无疑提升了数据库的写入性能。多个replica共享同一个storage volume，多副本并发读取，大幅提升了数据库的读性能。整体来讲，

Aurora 对于云端数据库的架构设计具备划时代的意义，充分利用了云基础设施的架构特性，将数据库性能作到极致。

 

参考文档

1. Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases SIGMOD’17, May 14 – 19, 2017, Chicago, IL, USA.

2. AWS 2016 re:Invent Amazon Aurora Deep Dive

3. AWS Aurora blog: https://aws.amazon.com/tw/blogs/database/category/aurora/?nc1=h_ls

4. Percona live 2016 Amazon Aurora Deep Dive

5. https://dev.mysql.com/

 

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

 

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