Amazon Aurora：高吞吐量云原生关系数据库的设计考虑
目錄
? ? ? ??1.?簡介
? ? ? ??2. 規模耐久性
? ? ? ??3.?日志就是數據庫
? ? ? ??4. THE LOG MARCHES FORWARD
? ? ? ??5.?將一切整合
? ? ? ??6.?性能結果
? ? ? ??7.?吸取的教訓
? ? ? ??8.?相關工作
? ? ? ??9.?結論
Amazon Aurora：高吞吐量云原生關系數據庫的設計考慮
摘要：亞馬遜的?Aurora 是一種關系數據庫服務，用于作為亞馬遜網絡服務（AWS）的一部分提供的?OLTP?工作負載。在本文中，我們描述了?Aurora 的架構和導致該架構的設計考慮。我們認為，高吞吐量數據處理的核心限制已經從計算和存儲轉移到網絡。Aurora 為關系數據庫帶來了一種新的體系結構來解決這一限制，最顯著的是通過將重做處理（redo processing）推送到為?Aurora 專門構建的多租戶橫向擴展（multi-tenant scale-out）存儲服務。我們描述了這樣做不僅可以減少網絡流量，還可以實現快速故障恢復、故障轉移到副本而不丟失數據，以及容錯、自修復存儲。然后，我們描述了?Aurora 如何使用高效的異步方案在多個存儲節點之間就持久狀態達成共識，從而避免昂貴的恢復協議。最后，在將?Aurora 作為生產服務運營了18個月之后，我們分享了從客戶那里學到的關于現代云應用對其數據庫層的期望的經驗。
關鍵詞：數據庫；分布式系統；日志處理；法定人數模型；復制；恢復；性能；OLTP
?
?
1.?簡介
信息技術工作負載越來越多地轉向公共云提供商。這種全行業范圍的轉型的重要原因包括能夠在靈活的按需基礎上提供容量，并使用運營費用而不是資本費用模型來支付容量。許多信息技術工作負載需要一個關系型?OLTP?數據庫；為內部數據庫提供同等或更高的功能對于支持這種長期過渡至關重要。
在現代分布式云服務中，通過將計算從存儲中分離出來，并通過在多個節點上復制存儲，彈性和可擴展性日益增強。這樣做可以讓我們處理一些操作，例如替換行為不良或無法訪問的主機、添加副本、從寫入程序故障切換到副本、向上或向下擴展數據庫實例的大小等。
傳統數據庫系統面臨的輸入/輸出瓶頸在這種環境下發生了變化。由于輸入/輸出可以分布在多租戶集群中的許多節點和許多磁盤上，因此單個磁盤和節點不再是熱點。相反，瓶頸轉移到請求輸入/輸出的數據庫層和執行這些輸入/輸出的存儲層之間的網絡上。除了每秒數據包（PPS）和帶寬的基本瓶頸之外，還有流量的放大，因為高性能數據庫會并行向存儲機群發出寫操作。異常存儲節點、磁盤或網絡路徑的性能會影響響應時間。
雖然數據庫中的大多數操作可能會相互重疊，但有幾種情況需要同步操作。這會導致停頓和上下文切換。一種這樣的情況是由于數據庫緩沖區緩存中的缺失而導致的磁盤讀取。讀取線程在讀取完成之前無法繼續。緩存未命中還可能導致置換和刷新臟緩存頁面以容納新頁面的額外代價。后臺處理（如檢查點和臟頁寫入）可以減少這種損失的發生，但也會導致停頓、上下文切換和資源爭用。
事務提交是另一個干擾來源；提交一個事務時的停頓會阻止其他事務的進行。在云級分布式系統中，使用多階段同步協議（如兩階段提交，2PC）處理提交是一項挑戰。這些協議不能容忍故障，并且大規模分布式系統有連續的硬故障和軟故障的?"背景噪聲"。它們也是高延遲的，因為大規模系統分布在多個數據中心。
在本文中，我們描述了亞馬遜的 ?Aurora ，這是一種新的數據庫服務，通過在高度分布式的云環境中更積極地利用重做日志來解決上述問題。我們使用一種新穎的面向服務的體系結構（見圖1），該體系結構帶有一個多租戶橫向擴展存儲服務，該服務抽象出一個虛擬化的分段重做日志，并松散地耦合到一組數據庫實例。雖然每個實例仍然包括傳統內核的大部分組件（查詢處理器、事務、鎖定、緩沖區緩存、訪問方法和撤消管理），但是幾個功能（重做日志記錄、持久存儲、崩潰恢復和備份/恢復）被下放（off-loaded）到存儲服務中。
與傳統方法相比，我們的體系結構有三大優勢。首先，通過將存儲構建為跨多個數據中心的獨立容錯和自我修復服務，我們可以保護數據庫免受網絡或存儲層的性能差異以及暫時或永久故障的影響。我們觀察到，持久性的失敗可以被建模為長期的可用性事件，可用性事件可以被建模為長期的性能變化——一個設計良好的系統可以統一處理這些問題。其次，通過僅將重做日志記錄寫入存儲，我們能夠將網絡?IOPS?減少一個數量級。一旦我們消除了這個瓶頸，我們就能夠積極地優化許多其他的爭用點，在我們開始的?MySQL?代碼基礎上獲得了顯著的吞吐量改進。第三，我們將一些最復雜和最關鍵的功能（備份和重做恢復）從數據庫引擎中的一次性昂貴操作轉移到在大型分布式機群中攤銷的連續異步操作。這產生了沒有檢查點的近乎即時的崩潰恢復，以及不干擾前臺處理的廉價備份。在本文中，我們描述了三個貢獻：
(1) 如何推斷云規模的持久性，以及如何設計能夠應對相關故障的法定系統。（第?2?節）。
(2) 如何通過將傳統數據庫的較低部分轉移到這一層來利用智能存儲。（第?3?節）。
(3) 如何消除分布式存儲中的多階段同步、崩潰恢復和檢查點（第?4?節）。
然后，我們在第?5?節展示了如何將這三個想法結合起來設計?Aurora 的整體架構，然后在第?6?節回顧了我們的性能結果，并在第??7??節總結了我們的經驗教訓。最后，我們在第?8?節簡要介紹了相關工作，并在第?9?節給出了結論。
?
?
2. 規模耐久性
如果數據庫系統不做其他事情，它必須滿足數據一旦被寫入就可以被讀取的約定。不是所有系統都這樣。在本節中，我們將討論我們的法定模型背后的基本原理、我們對存儲進行細分的原因，以及這兩者如何結合起來，不僅提供耐用性、可用性和減少抖動，還幫助我們解決大規模管理存儲集群的運營問題。
?
2.1?復制和相關故障
實例生存期與存儲生存期不太相關（Instance lifetime does not correlate well with storage lifetime）。實例失敗?？蛻絷P閉了它們。他們根據負載上下調整它們的大小。出于這些原因，它有助于將存儲層與計算層分離。一旦這樣做，這些存儲節點和磁盤也不能避免出現故障。因此，必須以某種形式復制它們，以提供故障恢復能力。在大規模云環境中，存在節點、磁盤和網絡路徑故障。每個故障可能有不同的持續時間和不同的影響范圍。例如，一個節點可能會暫時缺乏網絡可用性，重新啟動時會暫時停機，或者磁盤、節點、機架、葉或主干網絡交換機甚至數據中心會永久出現故障。
在復制系統中容忍故障的一種方法是使用基于法定人數的投票協議（quorum-based voting protocol）。如果復制數據項的每一個?V?副本都被分配了一個投票，則讀或寫操作必須分別獲得?Vr?投票的讀法定人數或?Vw?投票的寫法定人數。為了實現一致性，法定人數必須遵守兩個規則。首先，每次讀取必須知道最近的寫入，公式為?Vr + Vw > V。此規則確保用于讀取的節點集與用于寫入的節點集相交，并且讀取仲裁包含至少一個具有最新版本的位置。其次，每次寫操作必須知道最近的寫操作，以避免寫沖突操作，公式為?Vw > V/2。容忍單個節點丟失的常見方法是將數據復制到（V = 3）個節點，并依賴?2/3 （Vw = 2）的寫入法定人數和?2/3 （Vr = 2）的讀取法定人數。
我們認為?2/3?的法定人數是不夠的。為了說明為什么，讓我們首先解釋?AWS?中可用性區域（Availability Zone，AZ）的概念。接入點是一個區域的子集，它通過低延遲鏈路連接到該區域的其他接入點，但針對大多數故障（包括電源、網絡、軟件部署、泛洪等）進行隔離。跨?AZs?分布數據副本可確保典型的大規模故障模式僅影響一個數據副本。這意味著人們可以簡單地將三個副本中的每一個放在不同的?AZ?中，并且除了較小的單個故障之外，還可以容忍大規模事件。
然而，在大型存儲設備群中，故障意味著，在任何給定的時刻，磁盤或節點的某個子集可能已經發生故障，并且正在被修復。這些故障可能獨立地分布在?AZ A、B?和?C?中的每個節點上。但是，由于火災、屋頂故障、洪水等原因，AZ C?的故障將破壞?AZ A?或?AZ B?中同時發生故障的任何副本的法定人數。此時，在?2/3?讀取法定人數模型中，我們將丟失兩個副本，并且無法確定第三個副本是否是最新的。換句話說，雖然每個?AZ?中副本的單個故障是不相關的，但?AZ?的故障是該?AZ?中所有磁盤和節點的相關故障。Quorums?需要容忍?AZ?故障以及同時發生的故障。
在?Aurora，我們選擇了一個設計點，該設計點允許?(a) 丟失一個完整的?AZ?和一個額外的節點（AZ+1）而不丟失數據，以及?(b) 丟失一個完整的?AZ?而不影響寫入數據的能力。我們通過在?3?個?AZ?中以?6?次復制每個數據項來實現這一點，每個?AZ?中每個數據項有?2?個副本。我們使用的法定人數模型是?6?票（V = 6），寫法定人數是?4/6 （Vw = 4），讀法定人數是?3/6 （Vr = 3）。利用這樣的模型，我們可以?(a) 丟失單個?AZ?和一個額外的節點（3?個節點的故障）而不丟失讀可用性，以及?(b) 丟失任何兩個節點，包括單個?AZ?故障并保持寫可用性。確保讀取仲裁使我們能夠通過添加額外的復制副本來重建寫入仲裁。
?
?
2.2?分段存儲（Segmented Storage）
我們來考慮一下?AZ+1?是否提供了足夠的耐久性這個問題。為了在該模型中提供足夠的耐用性，必須確保在修復其中一個故障（Mean Time to Repair，MTTR）所需的時間內，不相關故障的雙故障概率（Mean Time to Failure，MTTF）足夠低。如果雙重故障的概率足夠高，我們可能會在?AZ?故障上看到這些，從而打破法定人數。超越一個點，很難降低?MTTF?獨立失敗的概率。相反，我們專注于減少?MTTR，以縮小雙重失誤的脆弱性。為此，我們將數據庫卷劃分為固定大小的小段，目前大小為?10GB。這些數據以?6?次復制到保護組（Protection Groups，PGs）中，因此每個保護組由?6?個?10GB?的數據段組成，跨三個保護組組織，每個保護組中有兩個數據段。存儲卷（storage volume）是一組串聯的?PGs，使用大量存儲節點進行物理實施，這些存儲節點使用亞馬遜彈性計算云（EC2）作為虛擬主機進行配置，并連接固態硬盤。構成卷的?PGs?是隨著卷的增長而分配的。我們目前支持在未復制的基礎上增長到?64TB?的卷。
分段（Segments）現在是我們獨立的故障和修復單元。作為我們服務的一部分，我們監控并自動修復故障。在?10Gbps?網絡鏈路上，10GB?的段可以在?10?秒內修復。我們需要在相同的?10?秒窗口中看到兩個這樣的故障，再加上一個不包含這兩個獨立故障中的任何一個的?AZ?故障，以失去法定人數。以我們觀察到的失敗率來看，這是完全不可能的，即使對于我們為客戶管理的大量數據庫來說也是如此。
?
?
2.3?彈性的運營優勢
一旦一個人設計了一個對長期失敗有天然彈性的系統，它自然也會對短期失敗有彈性。能夠處理?AZ?長期丟失的存儲系統也可以處理因電源事件或需要回滾的壞軟件部署而導致的短暫停機。一個可以處理仲裁成員的多秒可用性損失的節點可以處理存儲節點上短暫的網絡擁塞或負載（One that can handle a multisecond loss of availability of a member of a quorum can hand）。
由于我們的系統對故障有很高的容忍度，因此我們可以利用這一點來進行維護操作，以免造成數據段不可用。例如，熱數據管理（heat management）很簡單。我們可以將熱磁盤或節點上的某個段標記為壞段，通過遷移到機群中其他較冷的節點，可以快速修復仲裁。操作系統和安全修補（OS and security patching）是正在修補的存儲節點的短暫不可用事件。甚至我們存儲設備的軟件升級也是這樣管理的。我們一次執行一個?AZ，并確保一個?PG?中不超過一個成員同時被修補。這使我們能夠在存儲服務中使用靈活的方法和快速部署。
?
?
3.?日志就是數據庫
在本節中，我們將解釋為什么在第?2?節中描述的分段復制存儲系統上使用傳統數據庫會在網絡?IOs?和同步停頓方面帶來難以承受的性能負擔。然后，我們解釋了我們將日志處理下放到存儲服務的方法，并通過實驗演示了我們的方法如何顯著減少網絡?IOs。最后，我們描述了我們在存儲服務中使用的各種技術，以最大限度地減少同步停頓和不必要的寫入。
?
3.1?放大的寫的負擔（The Burden of Amplified Writes）
我們對存儲卷進行分段并以?4/6?寫入法定量以?6?次復制每個分段的模型為我們提供了高彈性。不幸的是，對于?MySQL?這樣的傳統數據庫來說，這種模型導致了難以維持的性能，因為?MySQL?為每個應用程序編寫生成許多不同的實際?I/O。高?I/O?卷被復制放大，造成每秒數據包數（packets per second，PPS）沉重的負擔。此外，輸入/輸出操作系統會導致同步點，從而導致流水線停滯和延遲擴大。盡管鏈復制（chain replication）及其替代方案可以降低網絡成本，但它們仍會遭受同步停滯和附加延遲的困擾。
讓我們來看看寫操作在傳統數據庫中是如何工作的。像?MySQL?這樣的系統將數據頁寫入它公開的對象（例如堆文件、B?樹等）。以及重做日志記錄寫入預寫日志（WAL）。每個重做日志記錄都由被修改頁面的后映像和前映像之間的差異組成（Each redo log record consists of the difference?between the?after-image?and the before-image?of the?page that was?modified）。日志記錄可以應用于頁面的前圖像，以產生其后圖像。
實際上，還必須寫入其他數據。例如，考慮一個同步鏡像?MySQL?（mirrored MySQL）配置，它實現了跨數據中心的高可用性，并在主備配置下運行，如圖?2?所示。AZ1?中有一個活躍的?MySQL?實例，在亞馬遜彈性塊存儲（EBS）上有網絡存儲。AZ2?中還有一個備用?MySQL?實例，EBS?上也有網絡存儲。對主?EBS?卷的寫入使用軟件鏡像與備用?EBS?卷同步（The writes made to the?primary EBS volume are synchronized with the standby EBS?volume using software mirroring）。
圖?2?顯示了引擎需要寫入的各種類型的數據：重做日志、歸檔到亞馬遜簡單存儲服務（S3）以支持即時恢復的二進制（表單）日志、修改的數據頁面、數據頁的第二次臨時寫入（雙寫）以防止頁面損壞（the modified data pages, a second temporary write?of the data page (double-write) to prevent torn pages）以及最后的元數據（FRM）文件。該圖還顯示了實際輸入輸出流的順序，如下所示。在步驟?1?和?2?中，寫入被發送到?EBS，EBS?又將其發送到?AZ?本地鏡像，當兩者都完成時，接收到確認。接下來，在步驟?3?中，使用同步數據塊級軟件鏡像將寫入轉移到備用實例。最后，在步驟?4?和?5?中，寫操作被寫入備用?EBS?卷和相關鏡像。
上面描述的鏡像?MySQL?模型是不受歡迎的，這不僅是因為數據是如何寫入的，也是因為寫入了什么數據。首先，步驟?1、3?和?5?是順序的和同步的。延遲是附加的，因為許多寫入是順序的。抖動會被放大，因為即使是異步寫入，也必須等待最慢的操作，使系統任由異常值擺布。從分布式系統的角度來看，該模型可以被視為具有?4/4?寫入仲裁，并且容易受到故障和異常性能的影響。其次，由?OLTP?應用程序導致的用戶操作會導致許多不同類型的寫入，這些寫入通常以多種方式表示相同的信息，例如，為了防止存儲基礎架構中的頁面損壞而寫入雙寫緩沖區（the writes to the double write buffer in order to prevent?torn pages?in the storage infrastructure）。
?
?
3.2?將?Redo?處理下放到存儲層
當傳統數據庫修改數據頁面時，它會生成重做日志記錄，并調用日志應用程序，將重做日志記錄應用到頁面的內存前映像，以生成其后映像。事務提交要求寫入日志，但數據頁寫入可能會被推遲。
在?Aurora 中，唯一跨越網絡的寫入是重做日志記錄。從未有頁面是從數據庫層被寫入的，不用于后臺寫入，不用于檢查點，也不用于緩存回收。相反，日志應用程序被推送到存儲層，在那里它可以用于在后臺或按需生成數據庫頁面。當然，從一開始就從完整的修改鏈中生成每個頁面是非常昂貴的。因此，我們不斷在后臺物化數據庫頁面，以避免每次按需從頭開始重新生成它們。請注意，從正確性的角度來看，后臺物化完全是可選的：就引擎而言，日志是數據庫，存儲系統物化的任何頁面都只是日志應用程序的緩存。還要注意，與檢查點不同，只有具有長串修改的頁面才需要重新具體化。檢查點由整個重做日志鏈的長度決定。Aurora 頁面具體化是由給定頁面的鏈長度決定的。
我們的方法顯著降低了網絡負載，盡管增加了復制寫入，并提供了性能和耐用性。存儲服務可以以令人尷尬的并行方式擴展輸入/輸出，而不會影響數據庫引擎的寫吞吐量（The storage service can scale out I/Os in an?embarrassingly parallel fashion without impacting write?throughput of the database engine）。例如，圖?3?顯示了一個?Aurora 集群，其中一個主實例和多個副本實例跨多個?AZ 部署。在此模型中，主服務器僅將日志記錄寫入存儲服務，并將這些日志記錄以及元數據更新流式傳輸到復制副本實例。輸入輸出流根據一個公共目標（一個邏輯段，即一個?PG）對日志記錄進行完全排序，并將每一批傳送到所有?6?個副本，其中該批保存在磁盤上，數據庫引擎等待?6?個副本中的?4?個的確認，以滿足寫仲裁，并認為有問題的日志記錄是持久的或加固的。副本使用重做日志記錄將更改應用到它們的buffer caches（The replicas use the?redo log records to apply changes to their buffer caches）。
為了測量網絡輸入/輸出，我們使用?SysBench?只寫工作負載運行了一個測試，其中包含上述兩種配置的?100GB?數據集：一個是跨多個?AZ?的同步鏡像?MySQL?配置，另一個是?RDS Aurora（replicas across multiple AZs，跨多個?AZ?的副本）。在這兩個實例中，測試針對運行在?r3.8xlarge EC2?實例上的數據庫引擎運行了?30?分鐘。
我們實驗的結果總結在表?1?中。在?30?分鐘的時間里，Aurora 能夠維持比鏡像?MySQL多?35?倍的事務。盡管使用?Aurora?將寫入放大了?6?倍，并且不包括?EBS?中的鏈式復制和?MySQL?中的跨?AZ?寫入，但?Aurora?中數據庫節點上每個事務的?I/O?數量比鏡像?MySQL?中的少?7.7?倍。每個存儲節點都可以看到未復制的寫入，因為它只是六個拷貝中的一個，導致該層需要處理的輸入/輸出減少了?46?倍。通過向網絡寫入更少的數據，我們節省了成本，這使我們能夠積極復制數據以提高耐用性和可用性，同時，并行發出請求以最大限度地減少抖動的影響。
將處理轉移到存儲服務還可以通過最大限度地減少崩潰恢復時間來提高可用性，并消除后臺進程（如檢查點、后臺數據頁面寫入和備份）引起的抖動。
來檢查崩潰恢復。在傳統數據庫中，崩潰后，系統必須從最近的檢查點開始，并重放日志，以確保所有持久的重做記錄都已應用。在?Aurora 中，持久化重做記錄的應用程序在存儲層連續、異步地發生，并分布在整個車隊中。如果數據頁不是最新的，對該頁的任何讀請求可能需要應用一些重做記錄。因此，崩潰恢復的過程分散在所有正常的前臺處理中。數據庫啟動時不需要任何東西。
?
?
3.3?存儲服務設計要點
我們存儲服務的核心設計宗旨是最大限度地減少前臺寫請求的延遲。我們將大部分存儲處理轉移到后臺。鑒于存儲層的峰值和平均前臺請求之間的自然可變性，我們有足夠的時間在前臺路徑之外執行這些任務（we have ample time to perform these tasks outside the foreground path）。我們也有機會用?CPU?換磁盤。例如，當存儲節點忙于處理前臺寫請求時，沒有必要運行舊頁面版本的垃圾回收，除非磁盤接近容量。在?Aurora 中，后臺處理與前臺處理負相關。這不同于傳統數據庫，在傳統數據庫中，頁面的后臺寫入和檢查點與系統的前臺負載呈正相關。如果我們在系統上建立了一個?backlog，我們將抑制前臺活動，以防止長隊列的建立。由于數據段以高熵分布在系統中的各個存儲節點上，一個存儲節點上的節流很容易由我們的?4/6?仲裁寫入處理，所以表現為一個慢速節點。
讓我們更詳細地回顧一下存儲節點上的各種活動。如圖?4?所示，它包括以下步驟：(1) 接收日志記錄并添加到內存隊列中，(2) 將記錄保存在磁盤上并進行確認，(3) 組織記錄并識別日志中的空白，因為一些批次可能會丟失，(4) 與對等方利用?gossip?以填補空缺，(5) 將日志記錄合并到新的數據頁面中，(6) 定期將日志和新頁面轉移到?S3，(7) 定期垃圾回收舊版本，最后?(8) 定期驗證頁面上的循環冗余校驗代碼。
請注意，不僅上述每個步驟是異步的，而且只有步驟?(1) 和?(2) 在前臺路徑中，這可能會影響延遲。
?
?
4. THE LOG MARCHES FORWARD
在本節中，我們將描述如何從數據庫引擎生成日志，以便持久狀態、運行時狀態和副本狀態始終保持一致。特別是，我們將描述如何在沒有昂貴的?2PC?協議的情況下高效地實現一致性。首先，我們展示了如何在崩潰恢復時避免昂貴的重做處理。接下來，我們解釋正常操作以及如何維護運行時間和副本狀態。最后，我們提供恢復過程的詳細信息。
?
4.1?解決方案梗概：異步處理
因為我們將數據庫建模為重做日志流（如第?3?節所述），所以我們可以利用日志作為有序的變更序列向前推進的事實。實際上，每個日志記錄都有一個關聯的日志序列號（Log Sequence Number，LSN），它是由數據庫生成的單調遞增的值。
這讓我們通過以異步方式處理問題來簡化維護狀態的一致性協議，而不是使用像?2PC?這樣喋喋不休、不能容忍故障（chatty and intolerant）的協議。在高層次上，我們保持一致性和持久性，并在收到未完成存儲請求的確認時不斷提高這些點。由于任何單個存儲節點可能會丟失一個或多個日志記錄，因此它們會與?PG?的其他成員?gossip，尋找差距并填補漏洞。由數據庫維護的運行時狀態允許我們使用單個段讀取，而不是仲裁讀取，除非在狀態丟失且必須重建時進行恢復。
數據庫可能有多個未完成的獨立事務，這些事務可以以不同于啟動的順序完成（達到已完成和持久的狀態）。假設數據庫崩潰或重新啟動，是否回滾的決定對于每個事務都是獨立的。跟蹤部分完成的事務和撤銷它們的這一邏輯是保存在數據庫的引擎中，就像它正在向簡單磁盤寫入一樣（The logic for tracking?partially completed transactions and undoing them is kept in the?database engine, just as if it were writing to simple disks）。但是，在重新啟動時，在允許數據庫訪問存儲卷之前，存儲服務會進行自己的恢復，恢復的重點不是用戶級事務，而是確保數據庫看到統一的存儲視圖，盡管它是分布式的。
存儲服務確定最高的?LSN，這樣它可以保證所有先前的日志記錄可用性（這稱為?VCL?或?Volume Complete?LSN）。在存儲恢復期間，LSN?大于?VCL?的每個日志記錄都必須被截斷。然而，數據庫可以進一步約束點的子集，這可以通過標記日志記錄來截斷，并將它們標識為?CPLs 或一致性點?LSNs（The database can, however, further constrain a subset of points that are allowable for truncation by tagging log records and identifying them as CPLs or Consistency Point LSNs）。因此，我們將?VDL?（卷耐用的?LSN?，Volume Durable LSN）定義為最高的?CPL，它小于或等于?VCL，并截斷所有?LSN?大于?VDL?的日志記錄。例如，即使我們有?LSN 1007?之前的完整數據，數據庫也可能已經聲明只有?900、1000?和?1100?是?CPLs，在這種情況下，我們必須在?1000?截斷。我們完成到?1007，但只耐用到?1000（We are complete to 1007, but?only?durable to 1000）。
因此，完整性和持久性是不同的，并且可以認為一個?CPL 描述了某種必須有序接受的存儲系統事務的有限形式。如果客戶端不需要這種區分，它可以簡單地將每個日志記錄標記為一個公共對象。實際上，數據庫和存儲的交互方式如下：
(1) 每個數據庫級事務被分解成多個有序的、必須原子執行的小型事務。
(2) 每個小型事務由多個連續的日志記錄組成（需要多少就有多少）。
(3) 小型事務中的最終日志記錄是一個?CPL。
在恢復時，數據庫與存儲服務對話以建立每個?PG?的持久點，并使用該持久點來建立?VDL，然后發出命令來截斷?VDL?上的日志記錄。
?
?
4.2?正常運行
我們現在描述數據庫引擎的?"正常操作"，并依次關注寫、讀、提交和副本。
4.2.1?寫入
在Aurora中，數據庫不斷與存儲服務交互，并保持狀態以建立仲裁、提高卷持久性，并將事務注冊為已提交。例如，在正常/轉發路徑中，當數據庫收到確認以建立每批日志記錄的寫入仲裁時，它會推進當前的?VDL。在任何給定時刻，數據庫中可能有大量并發事務處于活動狀態，每個事務都生成自己的重做日志記錄。數據庫為每個日志記錄分配一個唯一的有序?LSN，但有一個限制條件，即分配給?LSN?的值不能大于當前?VDL?值和一個稱為?LSN?分配限制（LSN Allocation Limit，LAL）的常數之和（當前設置為?1000?萬）。此限制可確保數據庫不會遠遠領先于存儲系統，并在存儲或網絡跟不上的情況下引入?back-pressure，從而抑制傳入的寫入。
請注意，每個?PG?的每個段只看到卷中影響駐留在該段上的頁面的日志記錄的子集。每個日志記錄都包含一個反向鏈接，用于標識該?PG?的前一個日志記錄。這些反向鏈接可用于跟蹤到達每個段的日志記錄的完整點，以建立段完整?LSN（Segment Complete LSN，SCL），該?LSN?標識接收到?PG?的所有日志記錄的最大?LSN。存儲節點在相互?gossip 時會使用?SCL，以便找到并交換丟失的日志記錄。
?
4.2.2?提交
在?Aurora 中，事務提交是異步完成的。當客戶端提交事務時，處理提交請求的線程通過將其?"提交?LSN"?記錄為等待提交的單獨事務列表的一部分來擱置事務，并繼續執行其他工作。等價的?WAL?協議是基于完成一個提交，當且僅當，最新的?VDL?大于或等于事務的提交?LSN（The equivalent to the WAL?protocol is based on completing a commit, if and only if, the latest?VDL is greater than or equal to the transaction’s commit LSN）。隨著?VDL?進程的推進，數據庫識別出符合條件的等待提交的事務，并使用專用線程向等待的客戶端發送提交確認。工作線程不會暫停提交，它們只是拉取其他掛起的請求并繼續處理。
?
4.2.3 Reads
在?Aurora?中，與大多數數據庫一樣，頁面是從緩沖區緩存（buffer cache）中提供的，只有當緩存中不存在有問題的頁面時，才會產生存儲輸入輸出請求。
如果緩沖區緩存已滿，系統會找到一個要從緩存中替換的頁面。在傳統系統中，如果被替換的頁面是一個?"臟頁"，那么在替換它之前會被刷新到磁盤。這是為了確保頁面的后續提取的總是最新的數據。雖然?Aurora?數據庫在替換頁面時（或在任何其他地方）不會寫出頁面，但它會強制執行類似的保證：緩沖區緩存中的頁面必須始終是最新版本。只有當頁面的?"頁面?LSN"（標識與頁面的最新更改相關聯的日志記錄）大于或等于?VDL?時，才會通過從緩存中逐出頁面來實現該保證。該協議確保：(a) 頁面中的所有更改都已在日志中得到強化，以及?(b) 緩存未命中時，請求當前?VDL?的頁面版本以獲得其最新的持久版本就足夠了。
在正常情況下，數據庫不需要使用讀取法定人數來建立共識。從磁盤讀取頁面時，數據庫會建立一個讀取點，代表發出請求時的?VDL。然后，數據庫可以選擇相對于讀取點（read-point）完整的存儲節點，知道它將因此接收最新版本。存儲節點返回的頁面必須與數據庫中小型事務的預期語義一致（A?page that is returned by the storage node must be consistent with?the expected semantics of a mini-transaction (MTR) in the?database）。由于數據庫直接管理向存儲節點輸送日志記錄和跟蹤進度（即每個段的?SCL），所以它通常知道哪個段能夠滿足讀取（SCL?大于讀取點的段），因此可以直接向具有足夠數據的段發出讀取請求。
假設數據庫知道所有未完成的讀取，它可以在任何時候基于每個?PG?計算最小讀取點?LSN。如果存在讀取副本，寫者會使用 gossip?協議，以在所有節點上建立每點最小讀取點?LSN（If there are read replicas the writer gossips with them to?establish the per-PG Minimum Read Point LSN across all nodes）。該值稱為保護組最小讀取點?LSN （PGMRPL），代表?"低水位線"，低于該值時，保護組的所有日志記錄都是不必要的（This value is called the Protection Group Min Read Point LSN?(PGMRPL) and represents the "low water mark"?below which all?the log records of the PG are unnecessary）。換句話說，存儲節點段保證不會有讀取點低于?PGMRPL?的讀取頁面請求。每個存儲節點都知道數據庫中的?PGMRPL，因此可以通過合并舊的日志記錄并安全地垃圾回收它們來推進磁盤上的物化頁面。
實際的并發控制協議是在數據庫引擎中執行的，就像傳統的?MySQL?一樣，數據庫頁面和撤消段是在本地存儲中組織的。
?
4.2.4?副本
在?Aurora 中，單個寫者和多達?15?個讀取副本都可以裝載一個共享存儲卷。因此，讀取副本不會增加存儲消耗或磁盤寫入操作的額外成本。為了最大限度地減少延遲，由寫入程序生成并發送到存儲節點的日志流也會發送到所有讀取的副本。在讀者中，數據庫通過依次考慮每個日志記錄來消耗這個日志流。如果日志記錄引用了讀者緩沖區緩存中的頁面，它將使用日志應用程序對緩存中的頁面應用指定的重做操作。否則，它只會丟棄日志記錄。請注意，從寫者的角度來看，副本異步地使用日志記錄，這表明用戶提交獨立于副本。復制副本在應用日志記錄時遵循以下兩個重要規則：(a) 將應用的唯一日志記錄是?LSN?小于或等于?VDL?的日志記錄，以及?(b) 作為單個小型事務一部分的日志記錄被自動應用到復制副本的緩存中，以確保復制副本看到所有數據庫對象的一致的視圖。實際上，每個副本通常比寫者落后一小段時間（?20?毫秒或更短）。
?
?
4.3?恢復
大多數傳統數據庫使用諸如?ARIES?之類的恢復協議，該協議依賴于可以表示所有提交事務的精確內容的預寫日志（write-ahead log，WAL）的存在。這些系統還定期檢查數據庫，通過將臟頁刷新到磁盤并將檢查點記錄寫入日志，以粗粒度的方式建立持久性點。重新啟動時，任何給定的頁面都可能會丟失一些已提交的數據或包含未提交的數據。因此，在崩潰恢復時，系統通過使用日志應用程序將每個日志記錄應用到相關的數據庫頁面來處理自上一個檢查點以來的重做日志記錄。這個過程使數據庫頁面在故障點達到一致的狀態，之后可以通過執行相關的撤消日志記錄來回滾崩潰期間正在進行的事務。崩潰恢復可能是一項昂貴的操作。減少檢查點間隔有所幫助，但代價是干擾前臺事務。Aurora 不需要這樣的權衡。
傳統數據庫的一個非常簡單的原則是，在正向處理路徑和恢復中使用相同的重做日志應用程序，當數據庫脫機時，它在前臺同步操作。我們在?Aurora?中也依賴于相同的原則，除了重做日志應用程序從數據庫中分離出來，并在存儲節點上并行運行，并且一直在后臺運行。一旦數據庫啟動，它就會與存儲服務協作執行卷恢復，因此，即使?Aurora 數據庫在每秒處理超過?100,000?條寫語句時崩潰，它也可以非常快地恢復（通常不到?10?秒）。
崩潰后，數據庫確實需要重新建立其運行時狀態。在這種情況下，它為每個?PG?聯系一個段的讀取法定人數，該法定人數足以保證發現任何可能已經達到寫入法定人數的數據。一旦數據庫為每個?PG?建立了一個讀定額，它就可以重新計算?VDL，在這個?VDL?之上的數據將被截斷，生成一個截斷范圍，該范圍將使新?VDL?之后的每個日志記錄失效，直到并包括一個終端?LSN，數據庫可以證明它至少是有史以來最高的未完成日志記錄的最高值。數據庫推斷這個上限是因為它分配了?LSNs，并限制了分配在?VDL?以上的距離（前面描述的?1000?萬的限制）。截斷范圍用?epoch 號進行版本控制，并持久地寫入存儲服務，以便在恢復中斷和重新啟動的情況下不會混淆截斷的持久性。
數據庫仍然需要執行撤消恢復，以便在崩潰時解除運行中事務的操作。但是，在系統根據撤消段（undo segments）建立這些正在進行的事務的列表之后，當數據庫聯機時，撤消恢復可能會發生。
?
?
5.?將一切整合
在本節中，我們將描述?Aurora 的構建模塊，如圖?5?中的鳥瞰圖所示。
數據庫引擎是?MySQL/InnoDB?"社區"?的一個分支，主要在?InnoDB?如何讀寫磁盤數據方面有所不同。在社區?InnoDB?中，寫操作導致數據在緩沖區頁面中被修改，相關的重做日志記錄按?LSN?順序寫入?WAL?的緩沖區。在事務提交時，WAL?協議只要求事務的重做日志記錄持久地寫入磁盤。實際修改后的緩沖區頁面最終也會通過雙寫技術寫入磁盤，以避免部分頁面寫入。這些頁面寫入在后臺進行，或者在從緩存中替換的過程中進行，或者在執行檢查點時進行。除了輸入輸出子系統，InnoDB?還包括事務子系統、鎖管理器、B+?樹實現和相關的?"小型事務"?概念。中期審查是僅在?InnoDB?內部使用的構造，它對必須以原子方式執行的操作組進行建模（例如，B+樹頁面的拆分/合并）。
在?Aurora InnoDB?變體中，表示必須在每個?MTR?中自動執行的更改的重做日志記錄被組織成由每個日志記錄所屬的?PGs?分片的批數據，并且這些批數據被寫入存儲服務。每個中期審查的最終日志記錄被標記為一致性點。Aurora?支持與社區?MySQL?在寫者中支持的完全相同的隔離級別（標準?ANSI?級別和快照隔離或一致性讀取）。Aurora?讀取副本在寫入程序中獲取有關事務啟動和提交的連續信息，并使用這些信息來支持本地事務的快照隔離，這些事務當然是只讀的。請注意，并發控制完全是在數據庫引擎中實現的，不會影響存儲服務。存儲服務提供了底層數據的統一視圖，該視圖在邏輯上與你將數據寫入社區?InnoDB?中的本地存儲所獲得的視圖相同。
Aurora 利用亞馬遜關系數據庫服務作為其控制平面。RDS（Relational Database Service）在數據庫實例上包括一個稱為主機管理器（Host Manager，HM）的代理，它監控集群的運行狀況，并確定集群是否需要故障轉移，或者是否需要替換實例。每個數據庫實例都是一個集群的一部分，該集群由一個寫者和零個或多個讀者組成。集群的實例位于單個地理區域中（例如，us-east-1、us-west-1等），通常放置在不同的自動倉庫中，并連接到同一地區的存儲集群。為了安全起見，我們隔離了數據庫、應用程序和存儲之間的通信。實際上，每個數據庫實例都可以在三個亞馬遜虛擬私有云（VPC）網絡上進行通信：客戶應用程序通過其與引擎交互的客戶?VPC、數據庫引擎和控制平面通過其相互交互的?RDS VPC?以及數據庫通過其與存儲服務交互的存儲?VPC。
存儲服務部署在?EC2?虛擬機群集上，這些虛擬機在每個區域至少有?3?個自動存儲區進行資源調配，并共同負責資源調配多個客戶存儲卷，在這些卷之間讀寫數據，以及在這些卷之間備份和恢復數據。存儲節點操作本地固態硬盤，并與數據庫引擎實例、其他對等存儲節點和備份/恢復服務交互，這些服務可根據需要將更改的數據連續備份到?S3，并從?S3?恢復數據。存儲控制平面使用亞馬遜動態數據庫服務來持久存儲集群和存儲卷配置、卷元數據以及備份到?S3?的數據的詳細描述。對于編排長期運行的操作，例如存儲節點故障后的數據庫卷恢復操作或修復（重新復制）操作，存儲控制平面使用亞馬遜簡單工作流服務。保持高水平的可用性要求在最終用戶受到影響之前，對真實和潛在的問題進行主動的、自動化的早期檢測。使用指標收集服務不斷監控存儲操作的所有關鍵方面，如果關鍵性能或可用性指標表明存在問題，就會發出警報。
?
?
6.?性能結果
在本節中，我們將分享我們在將?Aurora 作為生產服務運行方面的經驗，該服務于?2015年?7?月推出。我們首先總結運行行業標準基準測試的結果，然后展示我們客戶的一些性能結果。
?
6.1?標準基準的結果
在這里，我們展示了不同實驗的結果，這些實驗使用行業標準基準（如?SysBench?和?TPC-C?變體）比較了?Aurora?和?MySQL?的性能。我們在連接到具有?30K?預配?IOPS?的?EBS?卷的實例上運行?MySQL。除非另有說明，這些都是?r3.8X?大型?EC2?實例，具有?32?個vCPU和?244GB?內存，采用?Intel Xeon E5-2670 v2（Ivy Bridge）處理器。r3.8XL?上的緩沖緩存設置為?170GB。
?
6.1.1?根據實例大小進行擴展
在這個實驗中，我們報告了?Aurora 中的吞吐量可以隨著實例大小線性擴展，最高實例大小可以是?MySQL 5.6?和?MySQL 5.7?的?5?倍。請注意，Aurora 目前基于?MySQL 5.6?代碼庫。我們在?r3?系列的?5?個?EC2?實例（large、xlarge、2xlarge、4xlarge、8xlarge）上運行了?1GB?數據集（250?個表）的?SysBench?只讀和只寫基準測試。每個實例的大小正好是緊隨其后的較大實例?vCPUs 和內存的一半。
結果如圖?7?和圖?6?所示，分別用每秒寫和讀語句來衡量性能。Aurora?的性能在每個更高的實例大小下加倍，對于?r3.8xlarge，達到?121,000?次寫入/秒和?600,000?次讀取/秒，是?MySQL 5.7?的?5?倍，MySQL 5.7?的最高讀取/秒和?125,000?次寫入/秒。
?
6.1.2?不同數據大小的吞吐量
在這個實驗中，我們報告說，Aurora 的吞吐量明顯超過?MySQL，即使有更大的數據大小，包括具有緩存外工作集的工作負載。表?2?顯示，對于?SysBench?只寫工作負載，Aurora?比?MySQL?快?67?倍，數據庫大小為?100GB。即使對于?1TB?的數據庫大小和緩存外的工作負載，Aurora?仍然比?MySQL?快?34?倍。
?
6.1.3?通過用戶連接進行擴展
在這個實驗中，我們報告了?Aurora 中的吞吐量可以隨著客戶端連接的數量而擴展。表?3 顯示了當連接數從?50?增長到?500?再增長到?5000?時，以每秒寫入數計算的?SysBench OLTP?基準測試的運行結果。雖然?Aurora 從每秒?40,000?次寫入擴展到每秒?110,000?次寫入，但?MySQL?的吞吐量在大約?500?個連接時達到峰值，然后隨著連接數量增長到?5000?個而急劇下降。
?
6.1.4?使用副本擴展
在這個實驗中，我們報告說?Aurora 讀取副本的延遲明顯低于?MySQL?副本，即使工作負載更高。表?4?顯示，隨著工作負載在每秒?1000?到?10000?次寫入之間變化，Aurora 中的復制延遲從?2.62?毫秒增加到?5.38?毫秒。相比之下，MySQL?中的副本延遲從不到一秒鐘增長到?300?秒鐘。在每秒?10,000?次寫入時，Aurora 的復制延遲比?MySQL?小幾個數量級。副本延遲是根據提交的事務在副本中可見所需的時間來衡量的。
?
6.1.5?熱行爭用時的吞吐量
在這個實驗中，我們報告說，相對于?MySQL，Aurora?在具有熱行爭用（hot row contention）工作負載上表現非常好，例如基于?TPC-C?基準的工作負載。我們針對亞馬遜?Aurora 和?MySQL 5.6?和?5.7?運行了Percona TPC-C變體，在?3.8xlarge?上，?MySQL?使用了一個配備了?30K?的?EBS?卷。表?5?顯示，Aurora?的吞吐量是?MySQL 5.7?的?2.3?到?16.3?倍，因為工作負載從?500?個連接和?10GB?的數據大小到?5000?個連接和?100GB?的數據大小不等。
?
?
6.2?真實客戶工作負載的結果
在本節中，我們將分享一些客戶報告的結果，這些客戶將生產工作負載從?MySQL?遷移到?Aurora。
?
6.2.1?Aurora 應用響應時間
一家互聯網游戲公司將其生產服務從?MySQL?遷移到?Aurora?的?3.4x?大型實例上。他們的網絡事務在遷移前的平均響應時間為?15?毫秒。相比之下，遷移后的平均響應時間為?5.5?毫秒，提高了?3?倍，如圖?8?所示。
?
6.2.2?Aurora 的延遲
一家教育技術公司，其服務幫助學校管理學生筆記本電腦，將他們的生產工作負載從MySQL?遷移到?Aurora。遷移前后（14：00時）選擇和每條記錄插入操作的中值（P50）和?95% 延遲如圖?9?和圖?10?所示。在遷移之前，P95的延遲在?40?毫秒到?80?毫秒之間，比?P50?的大約?1?毫秒的延遲差得多。該應用程序遇到了我們在本文前面描述的那種糟糕的異常性能。然而，遷移后，兩種操作的?P95?延遲顯著改善，接近?P50?延遲。
?
6.2.3?具有多個副本的副本延遲
據?Pinterest?的?Weiner?報道，MySQL?副本通常遠遠落后于它們的寫者，并且可能?"導致奇怪的錯誤"。對于前面描述的教育技術公司來說，副本延遲通常會增加到?12?分鐘，影響應用程序的正確性，因此副本僅作為支持服務。相比之下，遷移到?Aurora 后，4?個副本的最大副本延遲從未超過?20?毫秒，如圖?11?所示。Aurora 提供的改進的副本延遲讓該公司將應用程序負載的很大一部分轉移到副本上，從而節省了成本并提高了可用性。
?
?
7.?吸取的教訓
我們現在已經看到客戶運行的各種各樣的應用程序，從小型互聯網公司一直到運行大量?Aurora 集群的高度復雜的組織。雖然他們的許多用例都是標準的，但我們關注的是云環境中常見的場景和期望，這些場景和期望引領我們走向新的方向。
?
7.1?多租戶和數據庫整合
我們的許多客戶都在運營軟件即服務（SaaS）業務，或者獨家運營，或者與一些剩余的內部客戶一起運營，他們正試圖轉向他們的?SaaS?模式。我們發現，這些客戶通常依賴于他們無法輕易更改的應用程序。因此，他們通常通過使用模式/數據庫（schema/database）作為租賃單位，將不同的客戶整合到一個實例上。這個習慣用法降低了成本：當不可能所有的客戶同時活躍時，他們避免為每個客戶的專用實例付費。例如，我們的一些?SaaS?客戶報告說，他們自己有超過?50,000?名客戶。
該模型與眾所周知的多租戶應用程序（如?Salesforce.com）明顯不同，后者使用多租戶數據模型，將多個客戶的數據打包到單個模式的統一表中，并按行識別租賃。因此，我們看到許多客戶的統一數據庫包含大量表。小型數據庫中超過?150,000?個表的生產實例非常常見。這給管理元數據的組件（如字典緩存）帶來了壓力。更重要的是，此類客戶需要?(a) 維持高水平的吞吐量和許多并發用戶連接，(b) 一種模型，在該模型中，數據僅在使用時提供并付費，因為很難預先預測需要多少存儲空間，以及?(c) 減少抖動，以便單個租戶的峰值對其他租戶的影響最小。Aurora 支持這些屬性，非常適合?SaaS?的應用。
?
7.2?高度并發的自動擴展工作負載
互聯網工作負載通常需要處理基于突發事件的流量峰值。我們的一個主要客戶在一個非常受歡迎的全國電視節目中有一個特殊的場景出現，并經歷了一個這樣的高峰，大大超過了他們的正常峰值吞吐量，而沒有給數據庫帶來壓力。為了支持這種峰值，數據庫處理許多并發連接是很重要的。這種方法在?Aurora 中是可行的，因為底層存儲系統可擴展性很好。我們有幾個客戶每秒運行超過?8000?個連接。
?
7.3?模式演變
現代?Web?應用程序框架，如?Ruby on Rails，深入集成了對象關系映射工具。因此，應用程序開發人員很容易對他們的數據庫進行許多模式更改，這使得數據庫管理員很難管理模式的發展。在?Rails?應用程序中，這些被稱為?"數據庫遷移"，我們已經聽到了數據庫管理員的第一手描述，他們要么必須處理?"每周幾十次遷移"，要么制定對沖策略以確保未來的遷移不會帶來痛苦。MySQL?提供了自由的模式演化語義，并使用完整的表副本實現了大多數更改，這加劇了這種情況（The situation is exacerbated with MySQL?offering liberal schema evolution semantics and implementing?most changes using a full table copy）。由于頻繁的?DDL?是一個實用的現實，我們已經實現了一個高效的在線?DDL?實現，它?(a) 基于每頁版本化模式，并根據需要使用模式歷史對單個頁面進行解碼，以及?(b) 使用寫時修改原語（modify-on-write primitive）將單個頁面緩慢升級到最新的模式。
?
7.4?可用性和軟件升級
我們的客戶對云原生數據庫有著苛刻的期望，這可能與我們如何運營集群以及我們修補服務器的頻率相沖突。由于我們的客戶主要將?Aurora 作為支持生產應用程序的?OLTP?服務，任何中斷都可能造成創傷。因此，我們的許多客戶對我們的數據庫軟件更新的容忍度非常低，即使這相當于每?6?周左右計劃停機?30?秒。因此，我們最近發布了一個新的零停機補丁（Zero-Downtime Patch ，ZDP）功能，允許我們在不影響運行中數據庫連接的情況下為客戶打補丁。
如圖?12?所示，ZDP?的工作方式是尋找一個沒有活動事務的瞬間，并在那個瞬間將應用程序狀態假脫機到本地臨時存儲，修補引擎，然后重新加載應用程序狀態。在此過程中，用戶會話保持活躍，并且忘記了引擎在幕后發生了變化。
?
?
8.?相關工作
在這一節中，我們將討論其他的貢獻，以及它們與?Aurora 所采取的方法之間的關系。
將存儲與計算分離。雖然傳統系統通常被構建為龐大的守護進程，但是最近有一些關于數據庫的工作，這些工作將內核分解成不同的組件。例如，Deuteronomy?就是這樣一個系統，它將提供并發控制和恢復的事務組件（Transaction Component，TC）與在?LLAMA?之上提供訪問方法的數據組件（Data Component，DC）分開，LLAMA?是一個無閂鎖（latch-free）的日志結構緩存和存儲管理器。Sinfonia?和?Hyder?是在橫向擴展服務上抽象事務訪問方法的系統，數據庫系統可以使用這些抽象來實現。Yesqell?系統實現了多版本分布式平衡樹，并將并發控制與查詢處理器分開。Aurora 將存儲分離到比?Deuteronomy、Hyder、Sinfonia?和?Yesquel?更低的級別。在?Aurora?中，查詢處理、事務、并發、緩沖區緩存和訪問方法與作為橫向擴展服務實現的日志記錄、存儲和恢復是分離的。
分布式系統。面對分區時正確性和可用性之間的權衡早已為人所知，其主要結果是在面對網絡分區時單拷貝可串行化（one-copy serializability）是不可能的。最近，在有的文章中證明的?Brewer?的?CAP 定理指出，在存在網絡分區的情況下，高可用性系統不能提供?"強"?一致性保證。這些結果以及我們在云級別的（cloud-scale）復雜的和相關的故障方面的經驗激發了我們的一致性目標，即使存在由?AZ?故障導致的分區。
Bailis?等人研究了提供高可用性事務（Highly Available?Transactions，HATs）的問題，這種事務既不會在分區期間不可用，也不會導致高網絡延遲。它們表明，可序列化性、快照隔離和可重復讀取隔離不兼容 HAT，而大多數其他隔離級別可通過高可用性實現。Aurora?提供了所有這些隔離級別，方法是做出一個簡化的假設，即在任何時候都只有一個寫者使用從單個有序域分配的?LSN?生成日志更新。
谷歌的?Spanner?提供外部一致的讀寫，以及在一個時間戳上跨數據庫的全局一致的讀取。這些特性使?Spanner 能夠支持一致的備份、一致的分布式查詢處理和原子模式更新，所有這些都是在全球范圍內進行的，甚至在正在進行的事務中也是如此。正如?Bailis?所解釋的，Spanner 高度專用于谷歌的讀重（讀多寫少）工作負載，并依賴于讀/寫事務的兩階段提交和兩階段鎖定。
并發控制。較弱的一致性（PACELC）和隔離模型在分布式數據庫中是眾所周知的，并導致了樂觀的復制技術以及最終一致性的系統。集中式系統中的其他方法包括基于鎖定的經典悲觀方案、像?Hekaton?中的多版本并發控制這樣的樂觀方案、像?HyPer?和?Deuteronomy?中的?VoltDB?和時間戳排序這樣的分片方法。?Aurora 的存儲服務為數據庫引擎提供了持久保存的本地磁盤的抽象，并允許引擎確定隔離和并發控制。
日志結構存儲。日志結構存儲系統是由?LFS?在?1992?年提出的。最近，Deuteronomy?和相關的?LLAMA?和?Bw-Tree?在存儲引擎堆棧中以多種方式使用日志結構技術，并且像?Aurora 一樣，通過寫入增量而不是整頁來減少寫入放大。Deuteronomy和?Aurora 都實現了純粹的重做日志，并跟蹤最高穩定的?LSN?來確認提交。
恢復。雖然傳統數據庫依賴于基于?ARIES?的恢復協議，但最近的一些系統選擇了其他性能途徑。例如，Hekaton?和?VoltDB?在崩潰后使用某種形式的更新日志重建它們的內存狀態。像?Sinfonia?這樣的系統通過使用像進程對和狀態機復制這樣的技術來避免恢復。Graefe?描述了一種具有每頁日志記錄鏈的系統，該系統支持按需逐頁重做，從而可以快速恢復。像?Aurora 一樣，Deuteronomy?不需要重做恢復。這是因為?Deuteronomy?延遲了事務，因此只有提交的更新才會發布到持久存儲中。因此，與?Aurora 不同，事務的規模可以在?Deuteronomy?中得到約束。
?
?
9.?結論
我們將?Aurora 設計為一個高吞吐量的?OLTP?數據庫，它在云規模的環境中既不犧牲可用性也不犧牲持久性。最大的想法是擺脫傳統數據庫的單一架構，將存儲與計算分離開來。特別是，我們將數據庫內核的下半部分轉移到一個獨立的、可擴展的分布式服務中，該服務管理日志記錄和存儲。由于所有的輸入/輸出都是通過網絡編寫的，我們現在的基本限制是網絡。因此，我們需要專注于減輕網絡負擔和提高吞吐量的技術。我們依靠仲裁模型來處理大規模云環境中發生的復雜和相關聯的故障，并避免異常性能損失，依靠日志處理來減少總的輸入/輸出負擔，以及異步一致性來消除分布式存儲中昂貴的多階段同步協議、離線崩潰恢復和檢查點。我們的方法簡化了架構，降低了復雜性，易于擴展，并為未來的發展奠定了基礎。
超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生總結
以上是生活随笔為你收集整理的Amazon Aurora：高吞吐量云原生关系数据库的设计考虑的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Dynamo：亚马逊的高可用键值存储
- 下一篇： Paxos Made Simple 中文