Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases
设计想法：
- 针对云上数据库网络所存在的瓶颈，基于一套存储计算分离架构，将日志处理下推到分布式存储层，通过架构上的优化来解决网络瓶颈。
主要贡献：
- Aurora如何做到不仅减少了网络资源消耗，同时还能快速故障恢复且不丢失数据，接着会介绍Aurora如何做到异步模式下分布式存储节点的一致性，最后会介绍Aurora在生产环境使用的经验。
背景：
- 磁盘I/O是瓶颈
- 同步操作，如缓存miss、事物提交操作（先刷日志，返回给工作线程成功了，事务提交是串行的，需要一直等待）
- 分布式事务提交 (分布式事务很消耗性能)，如2PC对故障容忍程度低，但在大规模分布式云环境中，软件和硬件故障时常态。
挑战&解决：
复制和容错处理：
- 基于Quorum [V_r + V_w > V , V_w > V/2] 将写冲突在存储层解决，后一条保证了能选到最新的副本进行写操作
- 6个副本均匀分布在3个AZ（Activarting Zone）上，W=4,R=3 （Aurora是写死的）
- 提高故障的修复时间，减少故障同时发生，采用分片策略。
- 软件升级：挂掉AZ分开升级&系统补丁，对于用户完全透明。
日志级数据库（redo log）
- 传统数据库写放大问题：double-write每个数据页要写两遍
- 所有的写类型就只是redo日志（只存改了些什么），任何时候都不会写数据页，定期物化数据页版本
- Aurora回放日志的工作可以一直在后台做，由于存储计算分离了，因此不像传统数据库停止服务后才能做。
- 所有工作线程不会因为事务提交而阻塞
- Aurora针对淘汰的页面，不会写回去，直接通过redo log改存储层。而且每次淘汰的页面的page-lsm都小于当前的VDL
- 架构（副实例也与基础层有交流[图中没显示出来]）
特性：
- NewSQL , 兼容MYSQL,Postgres，云上数据库，OLTP，基于MySQL改造
基础概念：
- 存储计算分离：任何数据库，底下文件系统挂一个分布式存储
- Quorum无法保证强一致性，仅仅通过Quorum机制无法确定最新已经成功提交的版本号。Vw是写多少个副本数，Vr是最多只需要读多少个副本，就一定能够读到数据。
- MySQL日志：
- Redo log:物理日志，记录偏移量
- binlog: 逻辑日志，Server层自己的归档日志。有两种模型，statement模式是记sql语句；row模式记录
- WAL（Write Ahead Logging）日志模型：每条redo日志拥有一个全局唯一的Log SEUENCE Number（LSN）
- 页断裂：为了防止页断裂，缓冲池中修改的数据页也会写入double-write区域。Double-write相当于 写入一个缓冲区中（也是有物理存储空间的）
- Simple Storage Service(S3)：简单存储服务，通俗一点就是大网盘。其概念类似于分布式文家系统
- gossip协议：一致性协议,使用Gossip协议的有：Redis Cluster、Consul、Apache Cassandra等。主要用途就是信息传播和扩散。
- shared-disk：shared-disk的所有数据都可以访问所有的存储节点。任何机器都可以读取或写入希望的任何数据部分。
- shared-nothing： 数据以某种方式分区并分布在一组机器上，这意味着每台机器对其拥有的数据具有唯一的访问权限，也是有唯一的责任。因此数据时完全隔离的，每个节点对其特定子集具有完全权限。
相关文章：