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并行發送，進而加快恢複速度。