Amazon新一代雲端關係數據庫Aurora（上）

本文由  網易雲 發佈。

做者：郭憶

本篇文章僅限內部分享，如需轉載，請聯繫網易獲取受權。

 

在2017年5月芝加哥舉辦的世界頂級數據庫會議SIGMOD/PODS上，做爲全球最大的公有云服務提供商，Amazon首次系統的總結了新一代雲端關係數據庫Aurora的設計實現。Aurora是Amazon在2014 AWS re:Invent大會上推出的一款全新關係數據庫，提供商業級的服務可用性和數據可靠性，相比MySQL有5倍的性能提高，並基於RDS 提供自動化運維和管理；

 

通過2年時間發展，Aurora已經成長爲AWS 客戶增加最快的雲服務之一，包括全球知名的在線遊戲網站Expedia、社交遊戲公司

Zynga都在使用Aurora。Aurora的推出一時引發了國內數據庫研究人員的熱烈討論，你們關注的一個焦點就是Aurora是不是基於MySQL推出的一個新的存儲引擎？下面咱們就根據會議發佈的論文，一塊兒走進Aurora。

 

爲何要有Aurora？

 

 在理解Aurora設計的初衷以前，咱們首先來了解一下AWS RDS MySQL的高可用部署架構設計。與咱們以前的猜想是一致的， AWS RDS是基於EC二、EBS這樣的雲基礎設施構建的，數據庫實例部署在EC2內，數據盤由一組經過鏡像實現的兩副本EBS提供。

 

爲了實現跨數據中心的高可用，Primary和Replica分別部署在兩個可用域內，數據同步採用相似DRBD的方式在操做系統內核經過塊設備級別的同步複製實現，因此AWS RDS的Replica平時是不能被讀取的，只能用於跨可用域的故障恢復。Replica與Primary是徹底對稱的，經過內核複製到replica的數據一樣存放在一組鏡像實現的兩副本EBS中。從圖中能夠看到，這樣的一個部署架構，數據庫發起的一次寫IO須要同步複製5次，其中3次仍是串行的，網絡延遲對數據庫的性能影響很是嚴重。

 

MySQL的InnoDB存儲引擎聽從WAL協議，全部對數據頁的更新都必須首先記錄事務日誌。此外，MySQL在事務提交時，還會生 成binlog；爲了保證被修改的數據頁在刷新到硬盤的過程當中保證原子性，Innodb設計了double-write的機制，每一個數據頁會在硬盤上寫兩遍。此外，MySQL還有元數據文件（frm）。在AWS RDS的高可用架構中，全部的這些日誌文件、數據文件都要通過網絡的傳輸5次，對網絡帶寬也是巨大的考驗。

 

這樣的一個架構因爲不涉及具體數據庫內核的改動，知足了AWS發展初期能夠快速支持多種類型的關係數據庫的需求，可是顯然隨着規模的增加，這樣的架構的缺陷也愈來愈明顯。當咱們還在考慮如何優化咱們的網絡性能和IO路徑時，AWS的注意力已經轉移到如何來減小數據在網絡上的傳輸，這就有了後來Aurora的架構。

 Aurora的系統架構

 

Aurora與傳統關係數據庫相比，最大的一個架構上的創新就是將數據和日誌的管理交由底層的存儲系統來完成，數據庫實例只負責向存儲系統中寫入redo log。因爲底層存儲節點掛載的是本地硬盤，日誌的持久化和數據頁的更新並不須要跨網絡完成，因此只有redo log須要經過網絡傳輸。因爲MySQL的redo log中包含了對某個數據頁的某行記錄的更新，經過redo log以及先前的數據頁能夠構造出更新後的完整頁面，因此Aurora選擇經過redo log創建起數據庫實例和底層存儲系統之間的關係。

 

在Aurora中，數據庫實例負責處理SQL查詢，事務管理，緩衝池管理，鎖管理，權限管理，undo管理，對用戶而言，Aurora與MySQL 5.6徹底兼容。底層的存儲系統負責redo log持久化，數據頁的更新和垃圾日誌記錄的回收，同時底層存儲系統會對數據進行按期備份，上傳到S3中。底層存儲系統的元數據存儲在Amazon DynamoDB中，基於Amazon SWF提供的工做流實現對Aurora 的自動化管理。

 

存儲系統的設計

 

Amazon爲Aurora實現了一個高可用、高可靠、可擴展、多租戶共享的存儲系統。

 

多副本

爲了實現數據的可靠性，Aurora在多個可用域內部署了多個數據副本，基於Quorum原則確保多個副本數據的最終一致性。

Quorum原則要求V個數據副本，一次讀操做必需要讀取Vr個數據副本，一次寫操做必需要同時寫入Vw個數據副本，Vw和Vr須要知足:Vw + Vr > V，且 Vw > V/2。Quorum原則能夠確保一份數據不能被同時讀寫，同時也確保了兩個寫操做必須串行化，後一個寫操做能夠基於前一個的結果進行更新。

 

通常最小的Quorum要求最少3個數據副本，Vr = 2 ，Vw =2，在雲環境中，就是3個可用域，每一個可用域一個數據副本，一個可用域不可用，不影響數據的讀寫。可是在真實的場景中，一個可用域不可用的同時，另一個可用域頗有可能也出現故障，爲了解決上述問題，Aurora採用了6副本數據，每一個可用域2個數據副本，一次寫操做須要4個數據副本，一次讀操做須要3個數據副本。這 樣的設計能夠實現：

1. 在一個可用域內兩個數據副本同時失效，同時另一個可用域內的一個數據副本失效，不影響整個系統的讀；

2. 任意兩個數據副本同時失效，不影響系統的寫；

 

分段存儲系統設計

任何一個高可用系統設計的前提假設都是在一段時間內，連續兩次發生故障的機率足夠的低。對於Aurora基於Quorum的多副本設計而言，若是一個AZ的副本失效，在修復過程當中，同時再有一個副本失效，則整個系統將不可寫；若是在AZ+1的副本失效的同時，又有一個副本再失效，則系統將不可讀。咱們沒有辦法去阻止連續故障的發生，可是咱們能夠經過縮短前一次故障的修復時間，從而下降連續兩次故障出現的機率，這就是分段存儲設計的思想來源。

 

Aurora將一個數據庫實例的數據卷劃分爲10G固定大小的存儲單元，這樣能夠確保每一個單元數據能夠快速的恢復。每一個存儲單元有6個副本，每一個可用域內2個副本，6個副本組成了一個PG（Protection Groups）。物理上，由一組掛載本地SSD的EC2雲主機充當存儲節點，每一個存儲節點上分佈了不少存儲單元。一組PG構成了一個Aurora實例的數據卷，經過分配更多的PG，能夠線性擴展數據卷的容量，最大支持64TB。

Segment是存儲系統故障恢復的最小單元，之因此選擇10G大小，若是過小，可能形成元數據過於龐大，若是太大，又可能形成單個Segment的修復時間過長，通過Aurora測試，10G大小的Segment數據恢復時間在10Gbps的網絡傳輸速度下，只須要10秒時間，這樣就確保了存儲系統能夠在較短的時間內完成故障修復。Segment的元數據由一個DynamoDB來負責存儲。

 

 基於Segment和Quorum的設計，Aurora能夠經過人工標記一些Segment下線，來完成數據遷移，對於熱點均衡、存儲節點操做系統升級更新都很是有幫助。

 

 以日誌核心的數據庫

 

事務日誌的寫入

在MySQL數據庫InnoDB存儲引擎中，全部數據記錄都存儲在16K大小的數據頁中，全部對行記錄的修改操做，都首先必須對數據頁進行加鎖，而後在內存中完成對數據頁行記錄修改操做，同時生成redo log和undo log，在事務提交時，確保修改操做對應的redo log持久化到硬盤中，最終被更新的數據頁經過異步方式刷新到硬盤中。redo log確保了數據頁更新的持久化，每一個redo logrecord都有一個惟一標識，LSN（log sequence number）,標識該記錄在redo log文件中的相對位置。爲了確保一個更新操做對多個數據頁，或者一個數據頁內部多條記錄的修改原子性，一個事務會被切分紅多個Mini-transaction(MTR)，MTR是MySQL內部最小執行單元，在Aurora中，MTR的最後一個redo log record對應的LSN，稱爲CPL(Consistency Point LSN)，是redo log中一致點。

 

在每一個MTR提交時，會將MTR生成的redo log 刷新到公共的log buffer中，在MySQL內部，通常log buffer空間滿，或者wait 超時，再或者事務提交時，log buffer中的redo log會被刷新到硬盤中。在Aurora中，每一個PG都保存了一部分數據頁，每一個redo logrecord在被刷新到硬盤以前，會按照redo log record更新的數據頁所在的PG，劃分紅多個batch，而後將batch發送到PG涉及的6 個存儲節點，只有等到6個節點中的4個的ACK，這個batch內的redo log record纔算寫入成功。最新寫入成功的MTR的最後一個記錄對應的LSN，咱們成爲VDL（ Volume Durable LSN ），這個點以前的MTR對數據頁的修改，都至關於已經持久化到存儲系統中。

 

存儲節點對事務日誌的處理

每一個存儲節點在接收到redo log record batch以後，首先會將其加入到一個內存隊列中，而後將redo log record持久化到硬盤後，返回ACK 給寫入實例（Primary）。接下來，因爲每一個存儲節點可能保存的batch不完整（因爲Quorum 4/6機制），因此須要經過與同一個PG下的其餘存儲節點進行詢問，索要缺失的batch。

 

Aurora中存儲節點對數據的管理採用了log-structured storage方式，每一個PG的redo log record首先按照page進行歸類，同一個page的redo log record在寫入時，直接append在該頁面以後，頁面中的已有記錄會有一個鏈接指針，指向最新的記錄版本。

 

除此以外，每一個PG內的每一個segment上的redo log record都包含一個指針，指向他的前一個log record，經過這個指針，咱們很容易判斷每一個Segment上的log record完整性，若是缺失，則可已經過與其餘的存儲節點進行詢問，補齊缺失redo log record。

 

數據頁的合併和舊版本記錄的回收

相似HBase、Cassandra採用LSM Tree的NoSQL系統，Aurora也須要有一個垃圾回收和數據頁合併的過程。在MySQL中，髒頁的刷新是經過Check point的機制來完成的，redo log的空間是有限的，必需要將redo log涉及的數據頁持久化到硬盤中，redo log 空間才能釋放，新的redo log 才能寫入，因此MySQL的髒頁刷新與客戶端的事務提交是密切相關的，若是髒頁刷新過慢，可能致使系統必須等待髒頁刷新，事務沒法提交。另外，Check point機制也決定了髒頁是否刷新是根據整個redo log大小來決定的，即便一個頁面只是偶爾一次更新，整個數據頁在check point推動過程當中，都必須從新寫入，同時爲了確保一個數據頁的完整性， MySQL還有double write機制，頁面被寫兩次，代價很是昂貴，顯然是不合理的。

 

Aurora的設計更加巧妙，由於數據是有熱點的，不一樣的數據頁的更新頻率是不同的，根據每一個Page待更新的redo log record數量，來決定page是否進行合併。

 

縱觀Aurora的設計，一個核心的設計原則就是將數據頁當作是日誌的一個緩存，經過犧牲必定的讀，換取了很好的寫性能，這是全部基於log-structured system 共性。

對數據庫的操做

 

寫操做

在Aurora中，同時會存在不少寫事務，這些事務會產生大量的redo log record，由於全部的事務在提交時，都必須確保該事務產生的redo log已經寫入到底層至少4個存儲節點中，考慮到網絡和存儲節點的IO性能，Aurora中會對寫事務進行限制，若是當前分配的LSN大於VDL加上LAL（LSN Allocation limit），則再也不分配新的LSN。

 

提交事務

在MySQL中，雖然在事務執行過程當中，各個事務是併發執行的，可是在提交時，都是串行的，雖然MySQL 5.6推出了Group Commit，能夠批量提交，可是在前一個group提交過程當中，其餘線程也不得不sleep等待喚醒，這樣無疑形成了資源浪費。

在Aurora中，事務的提交徹底是異步的，每一個事務執行完成之後，提交的過程只是將該事務加入到一個內部維護的列表中，而後該線程就被釋放了。當VDL大於該列表中等待提交事務commit對應的lsn時，則由一個線程，向各個客戶端發送事務提交確認。

 

讀操做

在MySQL中，全部的讀請求都是首先讀buffer cache的，只有當buffer cache未命中的狀況下，纔會讀取硬盤。Buffer cache的空間是有限的，在MySQL中，經過LRU的機制，會將一些長時間沒有被訪問的數據頁佔用的buffer空間釋放。若是這些頁面中包含髒頁，則必需要等到髒頁刷新到硬盤之後才能釋放。這樣就確保了下次讀取該數據，必定可以讀取到最新的版本。

在Aurora中，並不存在髒頁刷新的過程，全部數據頁的合併都是由底層存儲節點來完成的。因此與MySQL實例髒頁刷新向上看不一樣，Aurora須要向下看，經過將Page LSN大於VDL的數據頁釋放，能夠確保，全部Buffer中Page涉及的更新都已經持久化到硬盤中，同時在cache未命中的狀況下，能夠讀取到截止到當前VDL的最新版本的數據頁。

因此在Aurora中，Buffer Cache更像是一個純粹的Cache。

在Aurora平常讀取中，並不須要達到3/6的Quorum，由於有VDL的存在，咱們能夠根據讀請求發起時的VDL創建一個readpoint，找到包含小於VDL的全部完整log  record的存儲節點，直接進行讀取。經過同一個PG內部的Segment之間的相互詢問，能夠創建一個PG的最小的read point，該read point如下的log record實際上才能夠被回收合併。

 

 

只讀節點

在Aurora中，最多能夠爲一個writer實例建立15個只讀實例，這15個只讀實例掛載的是相同的存儲卷，只讀實例不會額外增長存儲的開銷。爲了減小延遲，Writer實例會將寫入到存儲系統的redo log日誌一樣發送給只讀實例，只讀實例接收到redo log日誌後，若是要更新的數據頁命中了buffer cache，直接在buffer cache中進行更新，可是須要注意的是，若是是同一個mini-transaction的redo log record，必須確保mini-transaction的原子性。若是buffer cache沒有命中，則該記錄被丟棄。另外，若是被執行的log record的lsn大於當前的VDL，也不會被執行，直接丟棄。

這樣的設計確保Aurora只讀實例相較於Writer實例延遲不超過20ms。

本文未結束，敬請期待下篇。

 

網易有數：企業級大數據可視化分析平臺。面向業務人員的自助式敏捷分析平臺，採用PPT模式的報告製做，更加易學易用，具有強大的探索分析功能，真正幫助用戶洞察數據發現價值。可點擊這裏免費試用。

 

瞭解 網易雲 ：
網易雲官網：https://www.163yun.com/
新用戶大禮包：https://www.163yun.com/gift
網易雲社區：https://sq.163yun.com/