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/