MIT 6.824 Lec10 Aurora

文章目录

• 背景介绍
• • Aurora的提出意义
  • 现有的云服务缺陷
  • 传统数据库提交事务流程
• Aurora
• • 设计核心
  • 容错需求
  • Quorum机制
  • 写操作
  • 读操作
  • 分段机制

背景介绍

Aurora的提出意义

• successful recent cloud service, solves serious problems for customers
• big payoff for good design
• shows limits of general-purpose storage abstraction
• many tidbits about what’s important in real-world cloud infrastructure

现有的云服务缺陷

• lots of data sent over network – both log and dirty data pages，the data pages are big even if only a few bytes are changed
• not fault-tolerant enough

传统数据库提交事务流程

假设有一笔银行交易事务如下：

begin
    x = x + 10
    y = y - 10
end
           

为了保证事务的ACID特性，传统数据库MySQL的处理机制如下：

1. 为账户x和账户y加锁，
2. 数据以b-tree的形式存储在磁盘中，MySQL会将某些data page进行缓存。
3. MySQL Server更改缓存中x和y的数据。
4. MySQL Server将更新日志append到WAL文件。
5. WAL文件写入成功后，可以提交事务，释放x和y的锁，回复client。
6. 定期将数据从data page cache刷回到disk上。
7. 当进行crash recovery时，如果该事务已经提交，则将new value进行replay替换(redo)，如果该事务还未提交，则将old value进行replay替换(undo)。

Aurora

设计核心

Aurora的设计核心主要有两点：

• Quorum writes for better fault-tolerance without too much waiting
• Storage servers understand how to apply DB’s log to data pages，so only need to send (small) log entries, not (big) dirty pages

容错需求

Aurora的容错需求如下：

• be able to write even if one AZ entirely dead
• be able to read even if one dead AZ and one more storage server dead
• tolerate temporarily slow replicas smoothly
• repair dead replica very quickly

Quorum机制

Aurora采用了Quorum读写机制，假设总共有N个replicate server，其中write需要写入W个server，read需要读取R个server，并满足

R + W = N + 1

：

• 可以巧妙地解决slow storage server，dead storage server或者network partition的问题。

  – 不需要等待，不需要检测出异常storage server。

  – 不会出现brain split现象

• 可以通过调整read或write需要的投票数目来应对不同的场景

Quorum机制保证了即使在部分storage server出现问题的情况下，Aurora也能正常进行write/read operation。在实际部署中，Aurora采用了

N=6, W=4, R=3

的Quorum规则。

写操作

Aurora的写操作只会向所有的6个storage server发送new log record，写操作并不会直接的改变data page。只有当4个storage server成功写入了log record之后，db server才会将该事务进行提交。storage server会在后台自动的将new log record更改的内容更新到data page中。

读操作

一般情况下，Aurora的读操作并没有遵循Quorum机制，db server在执行读操作时会缓存storage server中所需要的data page。db server追踪记录了每个storage server的SCL信息，当进行读操作时，db server会选择highest committed LSN >= SCL的storage server进行数据读取。

当db server宕机，需要在新的EC2 instance上进行crash recovery的时候，Aurora才会采用Quorum read。 具体过程如下：

1. db server需要访问所有storage server以确定VCL值。
2. db server会告诉storage server删除所有大于VCL的log records。
3. 对于在VCL之前但还没有提交的transaction，storage server需要执行undo操作撤销更改。

在实际的使用中，为了提高Aurora的读操作处理性能，一般会添加很多read replicas，client可以直接向read replicas发送read request，read replicas不一定能够返回最新的提交结果！ read replicas从storage中缓存需要读取的data page，为了保证cache数据的有效性，db server在向stroage server发送log records时，也会向read replicas发送log record，read replicas根据log record来更新cache中的data page。

分段机制

对于超大文件的存储，Aurora将其划分为10GB的segments，6个storage servers上的segments总共构成一个PG。对于不同的PG，其中的segments可能存储在不同的storage servers上。因此当进行故障恢复时，一个storage server中存储的所有segments可以由不同的source storage server并行发送，从而加快恢复速度。