本文由 網易雲 發佈。 作者：郭憶 本篇文章僅限內部分享，如需轉載，請聯繫網易獲取授權。 故障恢復 MySQL基於Check point的機制，周期性的建立redo log與數據頁的一致點。一旦資料庫重啟，從記錄的Check point開始，根據redo log，對相應的數據頁進行更新，對於已經提交 ...
本文由 網易雲 發佈。
作者：郭憶
本篇文章僅限內部分享，如需轉載，請聯繫網易獲取授權。
故障恢復
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/
