Amazon Aurora解讀(SIGMOD 2017)

Amazon在SIGMOD 2017發表了論文《Amazon Aurora: DesignConsiderations for High Throughput Cloud-Native Relational Databases》，第一次公開介紹了Aurora的設計理念和內部實現，下文是我對論文的解讀，若有理解不許確的地方，歡迎你們批評指正。

>>摘要

Aurora是亞馬遜雲服務AWS中的關係型數據庫服務，主要面向OLTP場景。本文會詳細介紹Aurora的架構以及設計背後的理念。 Aurora基本設計理念是在雲上環境下，數據庫的最大瓶頸再也不是計算或者存儲資源，而是網絡，所以基於一套存儲計算分離架構，將日誌處理下推到分佈式存儲層，經過架構上的優化來解決網絡瓶頸。 下文首先會介紹Aurora如何作到不只減小了網絡資源消耗，同時還能快速故障恢復且不丟失數據，接着會介紹Aurora如何作到異步模式下分佈式存儲節點的一致性，最後會介紹Aurora在生產環境使用的經驗。

>>1. 概述

在雲上環境下，存儲計算分離做爲解決系統彈性和伸縮性的方案愈來愈廣泛。廣義來講，任何數據庫，底下文件系統掛一個分佈式存儲，便可以認爲作到了存儲計算分離。經過存儲計算分離，能夠透明添加存儲節點，剔除故障節點，進行故障切換，擴展存儲空間等。在這個背景下，IO再也不成爲數據庫的瓶頸，由於IO壓力能夠打散在多個存儲節點上，反而是網絡成爲瓶頸，由於數據庫實例與全部存儲節點的交互都須要經過網絡，尤爲是爲了提高數據庫性能，數據庫實例與存儲節點多是並行交互的，這進一步加劇了網絡壓力。傳統數據庫中的IO操做是須要同步執行的，當須要進行IO等待時，這每每會致使線程上下文切換，影響數據庫性能。好比IO讀操做，當須要訪問一個數據頁時，若是在緩衝池沒有命中，則須要進行磁盤IO，那麼讀線程須要等待IO完成才能繼續其它操做，同時這種動做可能會進一步引起刷髒頁等。另一個咱們熟悉場景是事務提交操做(IO寫操做)，事務提交成功返回前必定要等待事務對應日誌刷盤才能返回，因爲事務是串行提交，所以其它事務也必須同步等待這個事務提交。 傳統數據庫中的兩階段事務尤爲不適合與分佈式雲環境，由於二階段提交協議對系統中參與的節點和網絡要求很高，自身容錯能力有限，這點與大規模分佈式雲環境中，軟件和硬件故障是常態的特徵是矛盾的。

本文介紹的Aurora是一個雲上環境全新的數據庫服務能夠很好的解決上述傳統數據庫遇到的問題。 它基於存儲計算分離的架構，並將回放日誌部分下推到分佈式存儲層，存儲節點與數據庫實例(計算節點)鬆耦合，幷包含部分計算功能。 Aurora體系下的數據庫實例仍然包含了大部分核心功能，好比查詢處理，事務，鎖，緩存管理，訪問接口和undo日誌管理等；但redo日誌相關的功能已經下推到存儲層，包括日誌處理，故障恢復，備份還原等。Aurora相對於傳統數據庫有三大優點，首先，底層數據庫存儲是一個分佈式存儲服務，能夠輕鬆應對故障；其次，數據庫實例往底層存儲層只寫redo日誌，所以數據庫實例與存儲節點之間的網絡壓力大大減少，這爲提高數據庫性能提供了保障；第三，將部分核心功能(故障恢復，備份還原)下推到存儲層，這些任務能夠在後臺不間歇地異步執行，而且不影響前臺用戶任務。下文會詳細介紹Aurora如何實現這些功能，主要包括三大塊：
1.如何基於Quorum模型保證底層存儲的一致性
2.如何將redo日誌相關的功能下推到存儲層
3.如何消除同步點，分佈式存儲下如何作檢查點和故障恢復

>> 2. 可擴展高可用存儲

2.1複製和容錯處理

Aurora存儲層的複製基於Quorum協議，假設複製拓撲中有V個節點，每一個節點有一個投票權，讀 或 寫 必須拿到Vr 或 Vw個投票才能返回。爲了知足一致性，須要知足兩個條件，首先Vr + Vw > V，這個保證了每次讀都能讀到擁有最新數據的節點；第二，Vw > V/2，每次寫都要保證能獲取到上次寫的最新數據，避免寫衝突。好比V=3，那麼爲了知足上述兩個條件，Vr=2，Vw=2。爲了保證各類異常狀況下的系統高可用，Aurora的數據庫實例部署在3個不一樣AZ(AvailablityZone)，每一個AZ包含了2個副本，總共6個副本，每一個AZ至關於一個機房，是一個獨立的容錯單元，包含獨立的電源系統，網絡，軟件部署等。結合Quorum模型以及前面提到的兩條規則， V=6，Vw=4，Vr=3，Aurora能夠容忍任何一個AZ出現故障，不會影響寫服務；任何一個AZ出現故障，以及另一個AZ中的一個節點出現故障，不會影響讀服務且不會丟失數據。

2.2分片管理

經過Quorum協議，Aurora能夠保證只要AZ級別的故障(火災，洪水，網絡故障)和節點故障(磁盤故障，掉電，機器損壞)不一樣時發生，就不會破壞協議自己，數據庫可用性和正確性就能獲得保證。那麼，若是想要數據庫「永久可用」，問題變成如何下降兩類故障同時發生的機率。因爲特定故障發生的頻率(MTTF, Mean Time to Fail)是必定的，爲了減小故障同時發生的機率，能夠想辦法提升故障的修復時間(MTTR,Mean Time To Repair)。Aurora將存儲進行分片管理，每一個分片10G，6個10G副本構成一個PGs(Protection Groups)。Aurora存儲由若干個PGs構成，這些PGs其實是EC2(AmazonElastic Compute Cloud)服務器+本地SSD磁盤組成的存儲節點構成，目前Aurora最多支持64T的存儲空間。分片後，每一個分片做爲一個故障單位，在10Gbps網絡下，一個10G的分片能夠在10s內恢復，所以當前僅當10s內同時出現大於2個的分片同時故障，纔會影響數據庫服務的可用性，實際上這種狀況基本不會出現。 經過分片管理，巧妙提升了數據庫服務的可用性。

2.3輕量級運維

基於分片管理，系統能夠靈活應對故障和運維。好比，某個存儲節點的磁盤IO壓力比較大，能夠人爲將這個節點剔除，並快速新加一個節點到系統。另外，在進行軟件升級時，一樣能夠臨時將存儲節點剔除，待升級完畢後再將節點加入到系統。全部這些故障和運維管理都是分片粒度滾動進行的，對於用戶徹底透明。

>> 3. 存儲計算分離

3.1傳統數據庫寫放大問題

咱們看看在傳統數據庫中寫的流程。以單機MySQL爲例，執行寫操做會致使日誌落盤，同時後臺線程也會異步將髒頁刷盤，另外爲了不頁斷裂，進行刷髒頁的過程還須要將數據頁寫入double-write區域。若是考慮生產環境中的主備複製，如圖2所示，AZ1和AZ2分別部署一個MySQL實例作同步鏡像複製，底層存儲採用Elastic Block Store(EBS)，而且每一個EBS還有本身的一份鏡像，另外部署Simple Storage Service(S3)進行redo日誌和binlog日誌歸檔，以支持基於時間點的恢復。從流程上來看，每一個步驟都須要傳遞5種類型的數據，包括redo，binlog，data-page，double-write和frm元數據。因爲是基於鏡像的同步複製，這裏我理解是Distributed Replicated Block Device(DRBD)，所以圖中的1，3，5步驟是順序的，這種模型響應時間很是糟糕，由於要進行4次網絡IO，且其中3次是同步串行的。從存儲角度來看，數據在EBS上存了4份，須要4份都寫成功才能返回。 因此在這種架構下，不管是IO量仍是串行化模型都會致使性能很是糟糕。

 

3.2日誌處理下放到存儲層

傳統數據庫中，修改一個數據頁，會同步產生對應的redo日誌，基於數據頁的前鏡像回放redo日誌能夠獲得數據頁的後鏡像。事務提交時，須要事務對應的redo日誌都寫盤成功後才能返回。在Aurora中，全部的寫類型只有一種，那就是redo日誌，任什麼時候候都不會寫數據頁。存儲節點接收redo日誌，基於舊版本數據頁回放日誌，能夠獲得新版本的數據頁。爲了不每次都從頭開始回放數據頁變動產生的redo日誌，存儲節點會按期物化數據頁版本。如圖3所示， Aurora由跨AZ的一個主實例和多個副本實例組成，主實例與副本實例或者存儲節點間只傳遞redo日誌和元信息。主實例併發向6個存儲節點和副本實例發送日誌，當4/6的存儲節點應答後，則認爲日誌已經持久化，對於副本實例，則不依賴其應答時間點。 從sysbench測試(100G規模，只寫場景，壓測30分鐘)的數據來看，Aurora是基於鏡像MySQL吞吐能力的35倍，每一個事務的日誌量比基於鏡像MySQL日誌量要少7.7倍。再來看看故障恢復速度，傳統數據庫宕機重啓後，恢復從最近的一個檢查點開始，讀取檢查點後的全部redo日誌進行回放，確保已經提交的事務對應的數據頁獲得更新。在Aurora中，redo日誌相關的功能下推到存儲層，回放日誌的工做能夠一直在後臺作。任何一次讀磁盤IO操做，若是數據頁不是最新版本，都會觸發存儲節點回放日誌，獲得新版本的數據頁。所以相似傳統數據庫的故障恢復操做實質在後臺一直不斷地進行，而真正進行故障恢復時，須要作的事情不多，因此故障恢復的速度很是快。

3.3存儲服務設計關鍵點

Aurora存儲服務設計的一個關鍵原則是減小前臺用戶寫的響應時間，所以將盡量多的操做移到後臺異步執行，而且存儲節點會根據前臺的請求壓力，自適應分配資源作不一樣的工做。好比，當前臺請求很繁忙時，存儲節點會減緩對舊版本數據頁的回收。傳統數據庫中，後臺線程須要不斷地推動檢查點，避免故障恢復時間消耗的時間過長，但會影響前臺用戶請求處理能力； 對於Aurora而言，分離的存儲服務層使得後臺線程推動檢查點動做徹底不影響數據庫實例，而且是推動地越快，越有利於前臺的磁盤IO讀操做(減小了回放日誌過程)。 Aurora寫基於Quorum模型，存儲分片後，按片達成多數派便可返回，因爲分佈足夠離散，少數的磁盤IO壓力大也不會影響到總體的寫性能。如圖4所示，圖中詳細介紹了主要的寫流程，1).存儲節點接收數據庫實例的日誌，並追加到內存隊列；2).將日誌在本地持久化成功後，給實例應答；3).按分片歸類日誌，並確認丟失了哪些日誌；4).與其它存儲節點交互，填充丟失的日誌；5).回放日誌生成新的數據頁；6).週期性地備份數據頁和日誌到S3系統；7).週期性地回收過時的數據頁版本；8).週期性地對數據頁進行CRC校驗。上述全部寫相關的操做，只有第1)和第2)步是串行同步的，會直接影響前臺請求的響應時間，其它操做都是異步的。

 

>> 4.一致性原理

這節主要介紹Aurora如何在不利用2PC協議的狀況下，如何經過在讀副本，存儲節點間傳遞redo日誌保證數據一致性。首先，咱們會介紹如何作到在故障恢復時不須要回放redo日誌；其次，咱們會介紹常見的操做，好比讀，寫和事務提交操做，而後會介紹Aurora如何保證從數據庫副本實例讀取的數據處於一致的狀態；最後會詳細介紹故障恢復的流程。

4.1日誌處理

目前市面上幾乎全部的數據庫都採用WAL(Write Ahead Logging)日誌模型，任何數據頁的變動，都須要先寫修改數據頁對應的redo日誌，Aurora基於MySQL改造固然也不例外。在實現中，每條redo日誌擁有一個全局惟一的Log Sequence Number(LSN)。爲了保證多節點數據的一致性，咱們並無採用2PC協議，由於2PC對錯誤的容忍度過低，取而代之的是，咱們基於Quorum協議來保證存儲節點的一致性。因爲在生產環境中，各個節點可能會缺乏部分日誌，各個存儲節點利用gossip協議補全本地的redo日誌。 在正常狀況下，數據庫實例處於一致的狀態，進行磁盤IO讀時，只須要訪問redo日誌全的存儲節點便可；但在故障恢復過程當中，須要基於Quorum協議進行讀操做，重建數據庫運行時的一致狀態。 數據庫實例中活躍着不少事務，事務的開始順序與提交順序也不盡相同。當數據庫異常宕機重啓時，數據庫實例須要肯定每一個事務最終要提交仍是回滾。這裏介紹下Aurora中存儲服務層redo日誌相關幾個關鍵的概念。Volumn Complete LSN(VCL)，表示存儲服務擁有VCL以前的全部完整的日誌。在故障恢復時，全部LSN大於VCL的日誌都要被截斷。ConsistencyPoint LSNs(CPLs)，對於MySQL(InnoDB)而言，以下圖所示， 每一個事務在物理上由多個mini-transaction組成，而每一個mini-transaction是最小原子操做單位，好比B樹分裂可能涉及到多個數據頁的修改，那麼這些頁修改對應的對應一組日誌就是原子的，重作日誌時，也須要以mini-transaction爲單位。 CPL表示一組日誌中最後的一條日誌的LSN，一個事務由多個CPL組成，因此稱之爲CPLs。Volumn Durable LSN(VDL)表示已持久化的最大LSN，是全部CPLs中最大的LSN，VDL<=VCL，爲了保證不破壞mini-transaction原子性，全部大於VDL的日誌，都須要被截斷。好比，VCL是1007，LSN爲900，1000，1100是CPLs，那麼咱們須要截斷1000之前的日誌。 VDL表示了數據庫處於一致狀態的最新位點，在故障恢復時，數據庫實例以PG爲單位確認VDL，截斷全部大於VDL的日誌。 

4.2基本操做

1).Writes

在Aurora中，數據庫實例向存儲節點傳遞redo日誌，達成多數派後將事務標記爲提交狀態，而後推動VDL，使數據庫進入一個新的一致狀態。 在任什麼時候刻，數據庫中都會併發運行着成千上萬個事務，每一個事務的每條redo日誌都會分配一個惟一的LSN，這個LSN必定大於當前最新的VDL，爲了不前臺事務併發執行太快，而存儲服務的VDL推動不及時，咱們定義了LSN Allocation Limit(LAL)，目前定義的是10,000,000，這個值表示新分配LSN與VDL的差值的最大閥值，設置這個值的目的是避免存儲服務成爲瓶頸，進而影響後續的寫操做。因爲底層存儲按segment分片，每一個分片管理一部分頁面，當一個事務涉及的修改跨多個分片時，事務對應的日誌被打散，每一個分片只能看到這個事務的部分日誌。 爲了確保各個分片日誌的完整性，每條日誌都記錄前一條日誌的連接，經過前向連接確保分片擁有了完整的日誌。Segment Complete LSN(SCL)表示分片擁有完整日誌的位點，存儲節點相互間經過gossip協議來彌補本地日誌空洞，推動SCL 。

2).Commits

在Aurora中，事務提交是徹底異步的。每一個事務由若干個日誌組成，幷包含有一個惟一的「commit LSN」，工做線程處理事務提交請求時，將事務相關的日誌提交到持久化隊列並將事務掛起，並繼續處理其它數據庫請求。 當VDL的位點大於事務的commit LSN時，表示這個事務redo日誌都已經持久化，能夠向客戶端回包，通知事務已經成功執行。在Aurora中，有一個獨立的線程處理事務成功執行的回包工做，所以，從整個提交流程來看，全部工做線程不會由於事務提交等待日誌推動而堵塞 ，他們會繼續處理新的請求，經過這種異步提交方式，大大提升了系統的吞吐。這種異步化提交思想目前比較廣泛，AliSQL也採用相似的方式。

3).Reads

在Aurora中，與大多數數據庫同樣，數據頁的請求通常都從緩衝池中得到，當緩衝池中對應的數據頁不存在時，纔會從磁盤中獲取。若是緩衝池滿了，根據特定的淘汰算法(好比LRU)，系統會選擇將一個數據頁淘汰置換出去，若是被置換的數據頁被修改過，則首先須要將這個數據頁刷盤，確保下次訪問這個頁時，能讀到最新的數據。可是Aurora不同，淘汰出去的數據頁並不會刷盤寫出，而是直接丟棄。 這就要求Aurora緩衝池中的數據頁必定有最新數據，被淘汰的數據頁的page-LSN須要小於或等於VDL。(注意，這裏論文中描述有問題，page-LSN<=VDL才能被淘汰，而不是大於等於) 這個約束保證了兩點：1.這個數據頁全部的修改都已經在日誌中持久化，2.當緩存不命中時，經過數據頁和VDL總能獲得最新的數據頁版本。

在正常狀況下，進行讀操做時並不須要達成Quorum。當數據庫實例須要讀磁盤IO時，將當前最新的VDL做爲一致性位點read-point，並選擇一個擁有全部VDL位點的日誌的節點做爲請求節點，這樣只須要訪問這一個節點便可獲得數據頁的最新版本。 從實現上來看，由於全部數據頁經過分片管理，數據庫實例記錄了存儲節點管理的分片以及SCL信息，所以進行IO操做時，經過元信息能夠知道具體哪一個存儲節點有須要訪問的數據頁，而且SCL>read-point。數據庫實例接收客戶端的請求，以PG爲單位計算Minimum Read Point LSN，在有讀副本實例的狀況下，每一個實例都均可以做相似的計算獲得位點，實例之間經過gossip協議獲得全局的per-Group MRPL，稱之爲PGMRPL。PGMRPL是全局read-point的低水位，每一個存儲節點根據PGMRPL，不斷推動數據頁版本，並回收再也不使用的日誌。

4).Replicas

在Aurora中，寫副本實例和至多15個讀副本實例共享一套分佈式存儲服務，所以增長讀副本實例並不會消耗更多的磁盤IO寫資源和磁盤空間。這也是共享存儲的優點，零存儲成本增長新的讀副本。讀副本和寫副本實例間經過日誌同步。寫副本實例往存儲節點發送日誌的同時向讀副本發送日誌，讀副本按日誌順序回放， 若是回放日誌時，對應數據頁不在緩衝池中，則直接丟棄。能夠丟棄的緣由在於，存儲節點擁有全部日誌，當下次須要訪問這個數據頁時，存儲節點根據read-point，能夠構造出特定的數據頁版本 須要說明的是，寫副本實例向讀副本發送日誌是異步的，寫副本執行提交操做並不受讀副本的影響。副本回放日誌時須要遵照兩個基本原則，1).回放日誌的LSN須要小於或等於VDL，2).回放日誌時須要以MTR爲單位，確保副本能看到一致性視圖。在實際場景下，讀副本與寫副本的延時不超過20ms。

4.3 故障恢復

大多數數據庫基於經典的ARIES協議處理故障恢復，經過WAL機制確保故障時已經提交的事務持久化，並回滾未提交的事務。這類系統一般會週期性地作檢查點，並將檢查點信息計入日誌。故障時，數據頁中同時可能包含了提交和未提交的數據，所以，在故障恢復時，系統首先須要從上一個檢查點開始回放日誌，將數據頁恢復到故障時的狀態，而後根據undo日誌回滾未交事務。從故障恢復的過程來看， 故障恢復是一個比較耗時的操做，而且與檢查點操做頻率強相關。經過提升檢查點頻率，能夠減小故障恢復時間，可是這直接會影響系統處理前臺請求吞吐，因此須要在檢查點頻率和故障恢復時間作一個權衡，而在Aurora中不須要作這種權衡。

傳統數據庫中，故障恢復過程經過回放日誌推動數據庫狀態，重作日誌時整個數據庫處於離線狀態。Aurora也採用相似的方法，區別在於將回放日誌邏輯下推到存儲節點，而且在數據庫在線提供服務時在後臺常態運行。 所以，當出現故障重啓時，存儲服務能快速恢復，即便在10wTPS的壓力下，也能在10s之內恢復。數據庫實例宕機重啓後，須要故障恢復來得到運行時的一致狀態，實例與Read Quorum個存儲節點通訊，這樣確保能讀到最新的數據，並從新計算新的VDL，超過VDL部分的日誌均可以被截斷丟棄。在Aurora中，對於新分配的LSN範圍作了限制，LSN與VDL差值的範圍不能超過10,000,000，這個主要是爲了不數據庫實例上堆積過多的未提交事務，由於數據庫回放完redo日誌後還須要作undo recovery，將未提交的事務進行回滾。在Aurora中，收集完全部活躍事務後便可提供服務，整個undo recovery過程能夠在數據庫online後再進行。

>> 5. 雲上Aurora體系

在社區InnoDB中，一個寫操做會修改緩衝池中數據頁內容，並將對應的redo日誌按順序寫入WAL。事務提交時，WAL協議約定對應事務的日誌須要持久化後才能返回。實際上，爲了防止頁斷裂，緩衝池中修改的數據頁也會寫入double-write區域。數據頁的寫操做在後臺進行，通常是在頁面置換或是作檢查點過程當中發生。InnoDB除了IO子系統，還包括事務子系統，鎖管理系統，B+Tress實現以及MTR等。MTR約定了最小事務，MTR中的日誌必需以原子的方式執行(好比B+Tree分裂或合併相關的數據頁)。
數據庫引擎基於社區版InnoDB引擎改進，將磁盤IO讀寫分離到存儲服務層。redo日誌按照PG劃分，每一個MTR的最後一條日誌是一致性位點。與社區的MySQL版本同樣，支持標準的隔離級別和快照讀。Aurora數副本實例不斷從寫副本實例獲取事務開始和提交信息，並利用該信息提供快照讀功能。 數據庫實例與存儲服務層相互獨立，存儲服務層向上爲數據庫實例提供統一的數據視圖，數據庫實例從存儲服務層獲取數據與從本地讀取數據同樣。 下圖展現了雲上Aurora的部署架構，Aurora利用AmazonRelational Database Service (RDS)來管理元數據。RDS在每一個實例部署一個agent，稱之爲Host Manager(HM)。HM監控集羣的健康情況並肯定是否須要作異常切換，或者是一個實例是否須要重建。每一個集羣由一個寫副本，0個或多個讀副本組成。全部實例在都一個物理Region(好比美國東部，美國西部)，通常是跨AZ部署，而且分佈式存儲服務層也在同一個Region。爲了保證安全，咱們在數據庫層，應用層和存儲層作了隔離。實際上，數據庫實例經過3類Amazon Virtual Private Cloud (VPC)網絡能夠相互通訊。經過應用層VPC，應用程序能夠訪問數據庫；經過RDS VPC，數據庫能夠和管控節點交互；經過存儲層VPC，數據庫能夠和存儲服務節點交互。
存儲服務其實是由一組EC2集羣構成，這個集羣橫跨至少3個AZ，對多個用戶提供存儲，讀寫IO，備份恢復等服務。存儲節點管理本地SSD並與數據庫實例和其它存儲節點交互，備份/還原服務不斷備份新數據到S3，在必要時從S3還原數據。存儲服務的管控系統藉助Amazon DynamoDB服務做爲持久化存儲，存儲內容包括配置，元數據信息，備份到S3數據的信息等。爲了保證存儲服務高可用，整個系統須要在異常影響到用戶以前，主動快速發現問題。系統中的全部關鍵操做都被監控，一旦性能或者可用性方面出現問題，則當即會產生報警。

 

>> 6. 性能數據

性能數據我這裏不一一展開了，具體數據你們能夠參考原論文。

>> 7. 實踐經驗

咱們發現愈來愈多的應用遷移到Aurora集羣，他們有一些共通點，咱們但願抽象出一些典型的場景，並總結經驗。

7.1多租戶

Aurora不少用戶都在作Software-as-a-Service(SaaS)服務，這些服務底層存儲模型通常比較穩定，經過多個用戶共享一個數據庫實例來減小成本。這種模式下，數據庫實例上會有大量的表，致使元數據暴增，這加大了字典管理的負擔。這種架構下，用戶通常會面臨解決三類問題：1).維持實例上較高的吞吐和併發，2).可以靈活應對磁盤空間問題，提早評估磁盤空間並具有快速的擴展能力，3）不一樣租戶間的影響要控制在最小。Aurora能完美解決這三類問題。

7.2高併發處理能力

互聯網應用一般會由於各類緣由致使壓力驟增，這須要系統有良好的擴展能力和處理高併發的能力。在Aurora中，因爲底層的存儲服務和上層的計算節點能夠方便地自動擴容，所以Aurora具有快速擴展能力，而且實際上Aurora有不少用戶鏈接數長期維持在8000以上。

7.3表結構升級

因爲表結構升級每每伴隨着鎖表和拷表，持續時間也比較長，而DDL是一個平常操做，所以須要有一套高效的online DDL機制。主要包括2點，1).schema多版本，每一個數據頁都存儲當時的schema信息，頁內數據能夠經過schema信息解析，2).對於修改的page採用modify-on-write機制來減小影響。

7.4軟件升級

因爲用戶使用Aurora實例一般只有一個主實例，所以發生任何問題都特別嚴重。Aurora中，全部的持久化數據都在存儲層，數據庫實例的狀態信息能夠藉助存儲層和元數據得到，所以能夠很方便的構造一個新的數據庫實例，爲了提升軟件升級效率，咱們經過Zero-Downtime Patch (ZDP)來滾動升級

>> 8. 總結

Aurora誕生的緣由是在彈性伸縮的雲環境下，傳統的高吞吐OLTP數據庫既不能保證可用性，又不能保證持久性。 Aurora的關鍵點在於將傳統數據庫中的存儲與計算分離，具體而言，將日誌部分下推到一個獨立的分佈式存儲服務層。因爲這種分離架構下，全部IO操做都是經過網絡，網絡將成爲最大的瓶頸，所以Aurora集中精力優化網絡以便提升系統吞吐能力。Aurora依靠Quorum模型，在性能影響可控的前提下，解決雲環境下的各類異常錯誤。在Aurora中，日誌處理技術減小了I/O寫放大，異步提交協議避免了同步等待，同時分離的存儲服務層還避免了離線故障恢復和檢查點操做。 Aurora的存儲計算分離方案使得系統總體架構很是簡單，並且方便將來的演進。

Q&A

1.通常瞭解到的Quorum算法只須要知足Vr + Vw > N便可，爲啥Aurora還須要知足第2個條件？ 
從文中瞭解到Aurora中Quorum算法須要知足兩個條件：
a).Vr + Vw > N，NWR算法，確保讀和寫有交集，能讀到最新寫入的數據。
b).Vw > N/2，避免更新衝突。
Quorum算法的基本含義是確保讀副本數與寫副本數有交集，能讀到最新寫入的數據。Aurora加入第二條約束主要是爲了保證每次寫入集合都與上次寫入的節點集合有交集，確保能讀到最近一次的更新，這樣日誌可以以自增的方式追加，確保不會丟失更新。從另一個角度來講，寫副本數設置爲Vw > N/2也間接在讀寫性能作了均衡。假設N=5，W=1，R=5，知足第一個條件，每次寫入一個節點便可返回成功，那麼讀取時則須要讀取5個副本，才能拿到最新的數據。

2.每一個segment分片是10G，若是事務跨多個segment分片如何處理？ 
每一個事務實際是有若干個MTR(mini-transaction)構成，MTR是InnoDB中修改物理塊的最小原子操做單位，MTR的redo日誌做爲一個總體寫入到全局redo日誌區。在Aurora中存儲按照segment分片管理，發送日誌時，也按分片歸類後發送，那麼就存在一種狀況，一個MTR跨多個segement分片，MTR日誌被打散的狀況。本質上來講，這種狀況也不存在問題，由於 事務提交時，若是事務跨多個segment分片，則會須要多個PG都知足Quorum協議才返回，進而推動VDL。因此若是VDL超過了事務的commit-LSN，則表示事務涉及到的日誌已經所有持久化，不會存在部分segment日誌丟失的問題，因此可以保證事務持久性。

3.Aurora讀副本如何實現MVCC？ 
在Aurora中，寫副本實例往存儲節點發送日誌的同時會傳遞日誌到讀副本實例，讀副本以MTR爲單位回放日誌；與此同時，寫副本還會將事務開始和提交的信息傳遞給讀副本，這樣在讀副本實例上也能構造出活躍的事務視圖。在讀副本上執行讀操做時，會依據活躍事務視圖做爲記錄可見習判斷依據，進而能讀到合適版本的數據。固然，Aurora讀副本與寫副本之間是異步複製，至多有20ms的延遲，所以在Aurora讀副本上可能不能讀到最新的提交數據。

4.爲何Aurora有成本優點？ 
Aurora中，多個數據庫實例(寫副本+多個讀副本)共享一個分佈式存儲層。對於數據庫引擎而言，整個存儲服務一個大的資源池，用戶根據需求申請存儲空間，最小粒度是10G，相對於單個實例的本地存儲，存儲空間利用率大大提高，並且很是方便擴展。另外一方面，全部數據庫引擎公用一份存儲，零存儲成本增長數據庫引擎，能大幅下降成本。

5.Aurora的優點和缺陷？ 
優點：
1). 存儲節點，計算節點彈性伸縮，按需配比
2). 一份存儲，對接多個計算節點，多租戶存儲服務，成本低。
3). 只傳遞日誌，巧妙的解決寫放大問題。
4). 實例快速故障恢復
5). 架構簡單，經過多副本能快速擴展讀能力，單個寫副本則巧妙地避免了分佈式事務等複雜實現。

缺陷：
1). 適合於讀多寫少的應用，寫水平擴展依賴於中間件方案。
2). SQL層與社區版MySQL同樣，複雜查詢能力(好比OLAP場景)較弱。
3). 單個寫副本，無分區多點寫能力(用戶維度+時間維度)
4). 總容量有上限，64TB

6.Aurora與Spanner的異同點？ 

從對比來看，Aurora與Spanner走的兩條不一樣的路線，Aurora以市場用戶爲導向，因此選擇全面兼容MySQL/PostgreSQL,用戶能夠無縫遷移到Aurora。另外就是，Aurora基於MySQL修改，並經過共享存儲方案避免了二階段提交，分佈式事務等複雜的實現，所以開發週期相對較短，也更容易出成果。反觀Spanner，是一個從新設計的數據庫，不管是基於Paxos的強同步仍是分佈式事務的支持，以及利用TrueTime機制實現全局一致性讀等都是比較複雜的實現，功能很是強大，可是在SQL兼容性這塊確作地不夠好，這也能夠解釋爲何Aurora普遍用於雲上業務，而Spanner則更多地是在Google內部使用，相信即便Spanner如今開放了雲版本，其SQL兼容性也是一個很大的挑戰。固然Aurora自己的數據庫引擎就是MySQL，其對於複雜查詢的短板還須要持續改進和優化。

 

備註：本文在微信公衆號已經同步發佈，感興趣的同窗能夠關注咱們團隊的公衆號。

https://mp.weixin.qq.com/s?__biz=MzIxNTQ0MDQxNg==&mid=2247484007&idx=1&sn=5b85170bf46c5e54edc1e8b8a1c211e1&chksm=97990f28a0ee863e161b2277a5d63a10396823d8d9a8c6cce38109b48939d5c24aae6cea26e0#rd