資料庫的新選擇 Amazon Aurora

Amazon Aurora

文章目錄

• Amazon Aurora
• • 雲計算時代 關系型資料庫如何實作進化？
  • Amazon Aurora 是 MySQL 的五倍性能
  • 細看PolarDB
  • • • PolarDB 與 Aurora 設計理念如出一轍
      • PolarDB 性能真的比 Aurora 高嗎？
  • 資料庫的重新構想
  • 解除安裝REDO日志：日志即資料庫
  • 基于單元的架構
  • 仲裁之美
  • 快速修複和追趕
  • 創新的基礎
  • • 1 使用mysqldump實用程式建立資料庫的轉儲，然後将該資料導入現有aurora mysql資料庫叢集
    • • 1.1 安裝并配置好mysql資料庫
      • 1.2 建立mysql資料庫的副本
      • • 1.2.1 設定複制選項
        • 1.2.2 建立現有資料庫的備份副本
      • 1.3 建立aurora mysql資料庫
      • 1.4 使用mysql指令遠端連接配接到aurora mysql資料庫并導入此前的sql檔案
    • 2 将完整備份檔案和增量檔案從資料庫複制到S3存儲桶，然後從這些檔案還原aurora mysql資料庫叢集
    • • 2.1 準備工作
      • • 2.1.1 在本地伺服器上安裝percona
        • 2.1.2 準許aurora mysql通路S3存儲桶
      • 2.2 備份要還原為aurora mysql的資料庫的檔案
      • • 2.2.1 準備工作
        • 2.2.2 使用percona xtrabackup建立備份
      • 2.3 從S3存儲桶還原aurora mysql資料庫
  • 資料庫免費試用連結及上手教程

雲計算時代 關系型資料庫如何實作進化？

談及資料庫，在 08 年以前基本上是以單機型資料庫為主，比如大家耳熟能詳的 Oracle，MySQL，PostgreSQL 等這樣的單機資料庫來支撐資料存儲業務。但是随着網際網路的蓬勃發展，接入到網際網路的裝置越來越多，資料量越來越大，并發處理需求越來越多，大家漸漸發現這種單機關系型資料庫已經沒有辦法滿足在網際網路遇到的比如大資料存儲、高并發等問題。于是，以 Google 為代表的一些網際網路公司開始轉向 NoSQL 這種分布式的資料庫，這是一個犧牲掉關系的模型去追求可擴充性的方向。在過去的近十年來，是 NoSQL 蓬勃發展的一段時期。但是近幾年來，大家發現我們很多的業務并沒有辦法直接以 NoSQL 的模型來生搬硬套。很多已有的業務 ,特别是對于一些傳統行業，還有在座的各位遇到的通信領域的場景來說，曆史遺留下來的程式都是以關系型資料庫為基礎的，是以大家發現很難把這些 Old-SQL 的東西放在一個分布式的場景來使用。那有沒有辦法把單機型的 SQL 的關系模型跟 NoSQL 所帶來的分布式的能力結合在一起呢？其實這就是這兩年來整個資料庫行業的一個大的革命性方向—— NewSQL。

NewSQL 是指這樣一類新式的關系型資料庫管理系統，它針對 OLTP 實作讀-寫工作負載，追求提供和 NoSQL 系統相同的擴充性能，且仍然保持傳統資料庫支援的 ACID 特性。

NewSQL 資料庫其典型代表有 Google Spanner , VoltDB , Clustrix , NuoDB 等， NewSQL 是既擁有傳統 SQL 資料庫血統，又能夠适應雲計算時代分布式擴充的産品，主要包括兩類：擁有關系型資料庫産品和服務，并将關系模型的好處帶到分布式架構上；或者提高關系資料庫的性能，使之達到不用考慮水準擴充問題的程度。前一類 NewSQL 包括 Clustrix 、 GenieDB 、 ScalArc 、 ScaleBase 、 NimbusDB ，也包括帶有 NDB 的 MySQL 叢集、Drizzle 等。後一類 NewSQL 包括 Tokutek 、 JustOne DB 。還有一些" NewSQL即服務"，包括Amazon的關系資料庫服務、 Microsoft 的 SQL Azure、FathomDB 等。

Amazon Aurora 是 MySQL 的五倍性能

不過，NewSQL就一定是關系型資料庫的發展方向嗎？亞馬遜AWS用自己的産品給出了不一樣的答案，那就是Aurora。

Amazon Aurora通過将資料庫引擎與為資料庫工作負載建構的基于 SSD 的虛拟化存儲層緊密內建，使性能大幅超過 MySQL，進而減少至存儲系統的寫入操作，最大程度降低鎖競争并消除資料庫程序線程所産生的延遲。根據 SysBench 對 r3.8xlarge 執行個體進行的測試表明，Amazon Aurora 每秒提供超過 500,000 次選擇和 100,000 次更新，是在同一硬體上運作相同基準的 MySQL 的 5 倍。

為什麼阿裡雲要研發新一代的關系型資料庫PolarDB ?

今年阿裡雲緊随亞馬遜的步伐，自主研發了新一代關系型資料庫 PoalrDB。PolarDB作為國内首個自主研發的通用雲資料庫，它擁有商業資料庫一樣的性能，但價格僅為前者的1/10，進一步降低使用者的上雲成本。作為雲托管的關系型資料庫，除了關系型資料庫的核心特征之外，PoalrDB 更多的關注于如何提供滿足使用者業務需求的雲服務，并且通過技術革新，不斷進化，在提供更好的資料庫計算力的同時，滿足使用者以下業務需求：上雲成本、OLTP 性能、業務連續性、線上業務擴充、資料安全。

據悉，9月21日，PolarDB将推出的公測版本，和MySQL完全相容，即現有 MySQL 應用程式和工具無需修改即可運作，

解決了存儲擴充和qps擴充的問題，性能高，成本很低，同時是高可用三副本，共享存儲架構。

細看PolarDB

今天不隻是阿裡雲要做這樣一款關系型資料庫，而是所有的雲計算廠商都不可避免的要經曆這樣一個階段。那就是雲計算時代傳統IT計算力的重建和進化。PolarDB 并不是重複 Oracle， IBM 等的腳步，而是一種創新和技術的提升。

PolarDB 與 Aurora 設計理念如出一轍

産品架構上，阿裡雲 PolarDB 采用了與 Amazon Aurora 相同的設計哲學。都放棄了通用分布式資料庫 OLTP 多路并發寫的支援，采用一寫多讀的架構設計，簡化了分布式系統難以兼顧的理論模型，又能滿足絕大多數 OLTP 的應用場景和性能要求。

PolarDB 采用存儲與計算分離的技術架構，同時可以支援更多的隻讀節點。主節點和隻讀節點之間是 Active-Active 的 Failover 方式，計算節點資源得到充分利用，由于使用共享存儲，共享同一份資料，進一步降低了使用者的使用成本，滿足公有雲計算環境下使用者業務彈性擴充的剛性需求。

PolarDB 的設計思想有幾個大的革新。一是通過重新設計特定的檔案系統來存取 Redo log 這種特定的 WAL I/O 資料，二是通過高速網絡和高效協定将資料庫檔案和 Redo log 檔案放在共享儲存設備上，避免了多次長路徑I/O的重複操作，相比較 Binlog 這種方式更加巧妙。另外在 DB Server 設計上，采用 MySQL 完全相容的思路，完全擁抱開源生态，從 SQL 的編譯、性能優化器和執行計劃等等都保留了傳統關系型資料庫的特色。并且針對 Redolog 的 I/O 路徑，專門設計了多副本共享存儲塊裝置。

我們知道，分布式資料庫一直是資料庫領域的熱點，具有非常大的實作難度。不管是遵循 CAP 理論，還是 BASE 思想，通用的分布式關系型資料庫基本上很難做到技術和商用的完美平衡。與 SQL 标準以及主流資料庫相容， OLTP ACID 事務 100% 支援， 99.99% 的高可用，高性能低延遲并發處理能力，彈性 Scale Up ， Scale out 可擴充性，備份容災和低成本遷移等等，能夠完美兼顧所有這些特點的商用關系型資料庫還沒有出現。

PolarDB 性能真的比 Aurora 高嗎？

當年，記得 Aurora 剛剛出來的時候，業界有質疑的聲音：“ Aurora會不會充其量就是一個翻版的 MySQL ？”今天，當阿裡雲全新一代 PolarDB 出來，會不會也會有質疑的聲音。

據業内人士透露，阿裡雲這款資料庫比 AWS Aurora 性能好太多，這是真的嗎？如果是真的，那性能比 MySQL 好太多太多了，你服不服？青出于藍而勝于藍，不是不無道理。

我們來看看性能名額吧。業界通常用 SysBench 來測試，包括亞馬遜的 Aurora 與 MySQL 的對比，而在阿裡雲内部是用使用者典型場景和資料來對比 PolarDB和 RDS 的。

資料庫的重新構想

老式關系資料庫體系結構：

在過去的30-40年中，這種單一的關系資料庫棧沒有發生太大的變化。盡管存在用于擴充資料庫的不同傳統方法（例如，分片、無共享或共享磁盤），但所有這些方法都共享相同的基本資料庫體系結構。它們都不能解決大規模的性能、彈性和故障範圍的問題，因為緊密耦合的單體基本限制仍然存在。

為了解決關系資料庫的局限性，我們通過将系統分解為基本的建構塊來重新定義棧。我們認識到對 緩存和日志記錄層 創新時機已經成熟。我們可以将這些層移動到專門建構的、可擴充、可自我修複、多租戶，以及對資料庫專門優化的存儲服務中。當我們開始建構分布式存儲系統時，Amazon Aurora 誕生了。

解除安裝REDO日志：日志即資料庫

傳統的關系資料庫在頁面中組織資料，當頁面被修改時，它們必須定期重新整理到磁盤。為了在故障時維護 ACID 語義，頁面修改也記錄在 REDO 日志記錄中，REDO 日志記錄以連續流的形式寫入磁盤。雖然這種體系結構提供了支援關系資料庫管理系統所需的基本功能，但它存在效率低下的問題。例如，一個邏輯寫入會變成多個（最多五個）實體磁盤寫入，進而導緻性能問題。

資料庫管理者試圖通過減少頁面重新整理頻率來解決寫放大問題。這反過來又惡化了崩潰恢複持續時間的問題。重新整理間隔越長，意味着用于重建正确頁面從磁盤讀取的 REDO 日志記錄越多。這會導緻恢複較慢。

在 Amazon Aurora 中，日志即資料庫。資料庫執行個體将 REDO 日志記錄寫入分布式存儲層，存儲層根據需要從日志記錄建構頁面。資料庫執行個體從不需要刷髒頁，因為存儲層總是知道頁面内容。這提高了資料庫的性能和可靠性。由于消除了寫放大，并且使用了可擴充的存儲叢集，寫性能大大提高。

例如，與運作在類似硬體上的 Amazon RDS for MySQL 相比，Amazon Aurora MySQL 相容版在 sysbench 基準測試中顯示了5倍的寫入 IOPS。資料庫崩潰恢複時間大大縮短，因為資料庫執行個體不再需要執行 REDO 日志回放。存儲層負責 REDO 日志在讀取時的頁面生成，進而使新的存儲服務不受傳統資料庫體系結構的限制，是以可以進一步進行創新。

基于單元的架構

正如我之前所說，一切都會出現故障。在大型系統中，元件會發生故障，并且經常發生故障，整個執行個體出現故障，網絡故障可以隔離大量基礎設施。更不常見的是，由于自然災害，整個資料中心可能會變得孤立或癱瘓。在 AWS，我們處理故障，并且在問題發生之前依靠基于單元的體系結構來解決問題。

AWS 有多個地理區域（20個），在每個區域内，我們有多個可用區。利用多個區和區域，設計良好的服務可以在不影響服務可用性的情況下，在元件故障和更大的災難中生存下來。Amazon Aurora 将所有寫操作複制到三個區域，以提供更好的資料持久性和可用性。事實上，Aurora 可以在放棄資料可用性的情況下容忍整個區域的失敗，并且可以從較大的故障中快速恢複。

然而，衆所周知，複制是資源密集型的，那麼，是什麼使得 Aurora 能夠在提供高性能的同時提供強大的資料複制呢？答案在于仲裁。

仲裁之美

一切都會出現故障。系統越大，出現故障的可能性就越大：網絡鍊路、SSD、整個執行個體或軟體元件。即使軟體元件沒有bug，它仍然需要定期重新開機進行更新。

傳統的方法是阻塞 I/O，直到故障轉移，并且在出現故障元件時以“降級模式”運作，這種方法在規模較大時存在問題。應用程式通常不能很好地容忍 I/O 中斷。通過中等複雜的數學計算，可以證明，在大型系統中，随着系統規模的增大，降級模式下運作的機率接近1。然後，有一個真正令人讨厭的“灰色故障”問題，當元件沒有完全失效，而是變慢時，就會出現這種問題。如果系統設計沒有預見到這種降級，慢的元件會拖累整個系統的性能。

Amazon Aurora 使用仲裁來解決元件故障和性能下降的問題。寫仲裁的基本思想很簡單：寫入盡可能多的副本，以確定仲裁讀取總是找到最新的資料。最基本的仲裁示例是“三取二”：

Vw+Vr>VVw+Vr>V

Vw>V/2Vw>V/2

V=3V=3

Vw=Vr=2Vw=Vr=2
           

例如，您可能要執行三次實體寫入，寫入仲裁為2。在邏輯寫入操作成功之前，您不必等待所有三個操作都完成。如果一次寫入失敗或速度慢，這是正常的，因為總體操作結果和延遲不會受到異常值的影響。這很重要：即使有什麼東西壞了，寫入也能成功而且速度很快。

簡單的⅔仲裁允許您容忍整個可用性區域的故障。不過，這還不夠好。雖然一個區域的故障是一個罕見的事件，但它不會降低其他區域中元件故障的可能性。使用 Aurora，我們的目标是可用性區域+1：我們希望能夠容忍一個區域的丢失，再加上一個故障，而不會造成任何資料持久性丢失，并且對資料可用性的影響最小。我們使用 4/6 的仲裁來實作這一目标：

Vw+Vr>VVw+Vr>V

Vw>V/2Vw>V/2

V=6V=6

Vw=4Vw=4

Vr=3Vr=3
           

對于每個邏輯日志寫入，我們發出六個實體副本寫入，并考慮當其中四個寫入完成時寫入操作成功。在每個區域有兩個副本的情況下，如果整個可用性區域發生故障，則寫入仍将完成。如果某個區域出現故障，并且發生其他故障，仍然可以達到讀取仲裁，然後通過快速修複恢複寫入能力。

快速修複和追趕

資料複制有不同的方法。在傳統存儲系統中，資料鏡像或擦除編碼發生在整個實體存儲單元的級别上，幾個單元組合在一個 RAID 陣列中。這種方法使修複速度變慢。RAID 陣列重建性能受到陣列中少數裝置功能的限制。随着儲存設備越來越大，在重建過程中複制的資料量也會越來越大。

Amazon Aurora 使用了一種完全不同的複制方法，基于分片和擴充架構。Aurora 資料庫卷邏輯上分為 10GB 邏輯單元（保護組），每個保護組以六副本複制到實體單元（段）。單個存儲段分布在一個大型分布式存儲中。當發生故障并取出一個段時，修複單個保護組隻需要移動大約 10GB 的資料，這在幾秒鐘内完成。

此外，當必須修複多個保護組時，整個存儲組都會參與修複過程。這提供了很高的帶寬來快速完成整個修複。是以，如果區域故障後又出現另一個元件故障，對于給定的保護組，Aurora 可能會在幾秒鐘内失去寫入仲裁。然而，一個自動啟動的修複能夠恢複高速可寫性。換言之，Aurora 的儲存會很快自我修複。

讀取怎麼樣？仲裁讀取代價很高，最好避免。用戶端 Aurora 存儲驅動程式跟蹤哪些段的寫入成功。它不需要在正常的頁面讀取上執行仲裁讀取，因為它總是知道從何處擷取頁面的最新副本。此外，驅動程式跟蹤讀取延遲，并始終嘗試從延遲最低的存儲副本讀取。唯一需要仲裁讀取的情況是在資料庫執行個體重新啟動時進行恢複。初始的 LSN 标記必須通過詢問存儲節點來重建。

創新的基礎

許多引人注目的新 Aurora 功能都直接由分布式自愈存儲體系結構實作。舉幾個例子：

• 讀可伸縮性：除了主資料庫執行個體外，在 Aurora 的多個區域中最多可以提供15個讀副本，以實作讀可伸縮性和更高的可用性。讀取副本使用與主機相同的共享存儲。
• 連續備份和時間點恢複：Aurora 存儲層連續透明地将 REDO 日志流備份到 Amazon S3。您可以執行時間點還原到配置的備份視窗中的任何時間戳。不需要計劃快照建立，并且當最接近感興趣時間的快照距離較遠時，不會丢失任何事務。
• 快速克隆：Aurora 存儲層可以快速建立卷的實體副本，而無需複制所有頁面。頁面最初在父卷和子卷之間共享，在修改頁面時完成寫入時的複制。克隆卷時沒有重複成本。
• Backtrack：将資料庫回退到特定時間點的快速方法，無需從備份中進行完全恢複。誤丢了一張表？你可以用 Aurora Backtrack 來回退。

在 Aurora 存儲引擎的基礎上建立了更多的關系資料庫創新。我們進入了關系資料庫的新時代，而 Aurora 隻是一個開始。客戶的聲音是最好的回應。Capital One、Dow Jones、Netflix 和 Verizon 等各行業的上司者都在将關系資料庫工作負載遷移到 Aurora，包括 MySQL 和 PostgreSQL 相容版本。

1 使用mysqldump實用程式建立資料庫的轉儲，然後将該資料導入現有aurora mysql資料庫叢集

因為aurora mysql與mysql相容，是以該過程與将mysql資料導入rds mysql的過程類似， 可參考文檔。

其整體架構如下圖所示：

1.1 安裝并配置好mysql資料庫

我在光環雲裸金屬伺服器上部署了mysql資料庫，具體部署過程略，可以百度。

1.2 建立mysql資料庫的副本

1.2.1 設定複制選項

編輯檔案/etc/my.cnf sudo vi /etc/my.cnf

更新[mysqld]字段如下：

[mysqld] log-bin=mysql-bin server-id=1

重新開機mysql服務 service mysqld restart

1.2.2 建立現有資料庫的備份副本

上圖中建立了一個資料庫schema_xuyi，現在将schema_xuyi進行備份，執行如下指令：

mysqldump \
--databases  schema_xuyi \
--master-data=2  \
--single-transaction \
--order-by-primary \
-r backup.sql \
-u  local_user \
-p 
           

圖中可見生成了備份檔案backup_xuyi.sql

1.3 建立aurora mysql資料庫

具體建立過程省略，注意與此前的mysql資料庫版本盡量一緻。

遠端連接配接到aurora mysql資料庫，其初始狀态如下圖：

1.4 使用mysql指令遠端連接配接到aurora mysql資料庫并導入此前的sql檔案

執行指令：

mysql -h aurora-1-instance-1.cbgpcbkn8knw.us-east-1.rds.amazonaws.com -P 3306 -u admin -p
           

其中aurora-1-instance-1.cbgpcbkn8knw.us-east-1.rds.amazonaws.com部分是aurora mysql資料庫的終端節點，連接配接成功

執行指令 source backup_xuyi.sql;

Workbench的重新整理操作沒找到，重新連接配接了一下aurora mysql資料庫，可見其狀态如下：

其中已經有了schema_xuyi的庫，說明mysqldump導入成功，本次測試隻是為了驗證從外部mysql導入到aurora的過程，至此本次操作完成。

2 将完整備份檔案和增量檔案從資料庫複制到S3存儲桶，然後從這些檔案還原aurora mysql資料庫叢集

參考文檔：

2.1 準備工作

2.1.1 在本地伺服器上安裝percona

本地資料庫版本是mysql5.7，建議percona版本為Percona XtraBackup 2.4

執行以下指令：

yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
yum install -y percona-xtrabackup-24.x86_64
           

從上圖可見Percona-xtrabackup安裝成功。

2.1.2 準許aurora mysql通路S3存儲桶

在跟aurora mysql資料庫相同的區域中建立一個存儲桶

過程比較簡單，省略。

建立IAM政策以通路S3資源

可以通過IAM控制台來建立相應的政策，具體過程省略，可以授予aurora 通路S3的所有權限。

建立IAM角色以允許aurora mysql通路AWS服務

具體建立角色的過程省略，可以參考文檔：

如下圖所示，建立了一個角色role_aurora_to_s3，并将上一步的政策附加到了該角色上。

将角色與aurora mysql資料庫關聯

具體操作過程見文檔

如上圖所示，已經将角色與aurora mysql資料庫相關聯。為了讓角色生效還需要修改參數組，我們選擇建立一個參數組

其中參數“aurora_load_from_s3_role”的值更新為前面所建立角色的ARN。

再修改資料庫執行個體的資料庫選項

應用修改，立即重新開機資料庫。

2.2 備份要還原為aurora mysql的資料庫的檔案

2.2.1 準備工作

為了跟之前的資料庫内容差別開來，特意建立了庫schema_test,并在其中建立了一張表table_test，如下圖所示：

2.2.2 使用percona xtrabackup建立備份

全量備份

xtrabackup --user=root --password=XY-zte110 --backup --target-dir=/root/backupfiles
           

可見在目前目錄下生成了一個backupfiles目錄，該類目下的内容如上圖所示。

通過aws CLI将備份檔案夾整個上傳到s3存儲桶（具體上傳的過程省略），登入s3控制台可見

2.3 從S3存儲桶還原aurora mysql資料庫

登入aurora控制台，進入資料庫頁面

在資料庫頁面點選“從S3還原”， 引擎選項->aurora 版本->我們選擇的是mysql5.7

點選“下一步”

下一步，進入資料庫詳細資訊頁面進行設定，具體内容與建立aurora執行個體的過程相似

下一步，配置進階設定

從這個配置的過程來看，跟建立一個新的aurora執行個體完全相同，由此可以斷定aurora從s3還原實際上是重新起了一個aurora執行個體。最後點選“建立資料庫”

确實是新生成一個資料庫執行個體，耐心等待吧。

切換到資料庫頁面，可以看到有兩個aurora執行個體

上圖中的執行個體aurora-instance-xuyi-copy就是從s3還原出來的新的aurora執行個體，已經成功建立。現在遠端到該執行個體檢視資料庫狀況

從s3還原實際上是重新起了一個aurora執行個體。最後點選“建立資料庫”

确實是新生成一個資料庫執行個體，耐心等待吧。

切換到資料庫頁面，可以看到有兩個aurora執行個體

上圖中的執行個體aurora-instance-xuyi-copy就是從s3還原出來的新的aurora執行個體，已經成功建立。現在遠端到該執行個體檢視資料庫狀況

可見全量複制成功。 至此通過S3還原aurora資料庫完成。

叢集可能會産生費用

資料庫免費試用連結及上手教程

你需要的教程這裡都有，不僅有視訊教程還有文檔教程

文檔教程分為初級中級與進階

• 操作需謹慎 誤操作會導緻費用産生