《亞馬遜云科技:2024年Amazon Aurora 數據庫高可用及容災白皮書(32頁).pdf》由會員分享,可在線閱讀,更多相關《亞馬遜云科技:2024年Amazon Aurora 數據庫高可用及容災白皮書(32頁).pdf(32頁珍藏版)》請在三個皮匠報告上搜索。
1、Amazon Aurora 高可用與容災白皮書 注意事項 客戶須根據實際業務情況酌情參考本文檔中的信息。本文檔:(a)僅供參考;(b)基于當前亞馬遜云科技產品和用途。如有更改,恕不另行通知;(c)不代表亞馬遜云科技及其附屬公司、供應商或許可方作出任何承諾或保證。文中涉及的亞馬遜云科技產品或服務均“按原樣”,不包含任何形式的保證、陳述或條件,無論是明示還是暗示。亞馬遜云科技對客戶的責任和義務受雙方協議約束,本文檔與亞馬遜云科技和客戶之間簽訂的任何協議無關,亦不影響任何此類協議。2024 Amazon Web Services,Inc.或其附屬公司保留所有權利 2 目錄 摘要與簡介 04 摘要 0
2、4 您的架構是否符合良好架構原則?04 簡介 05 Amazon Aurora 架構及其高可用性和容災功能 07 單區域實現高可用性和容災 12 跨區域擴展高可用性和容災 12 監控高可用性和容災環境 13 監控 Amazon Aurora 事件 14 最佳實踐 15 指定 RTO 和 RPO 15 制定與 RTO 和 RPO 相匹配的高可用性和容災策略 15 編寫并測試高可用性和容災流程文檔 16 定期測試和審查高可用性及容災實現流程 16 常見的高可用性和容災使用場景與設計模式 17 在打補丁、升級和重大 Schema 變更期間保持可用性 26 總結 30 貢獻者 31 延伸閱讀 32 3
3、 摘要與簡介 摘要摘要 Amazon Aurora 是一款全托管的關系型數據庫,提供超高性能、全球規模的可用性,并與 MySQL 和 PostgreSQL 完全兼容。Amazon Aurora 提供單區域和跨區域的高可用性(HA)和容災(DR)能力。本白皮書探討了 Amazon Aurora 提供的高可用性和容災能力,展示了支撐構建具有韌性的全球化應用程序的設計模式,闡述了如何利用 Amazon Aurora 的多可用區(AZ)部署和 Global Database(全球數據庫)功能,以及如何在單個區域內和跨區域實現高可用性和容災。您的架構是否您的架構是否符合符合良好架構原則?良好架構原則?A
4、mazon Well-Architected Framework 可幫助您權衡在云端構建系統時所做決策的利弊。該框架的六大支柱助您在設計和運營可靠、安全、高效、經濟實惠且可持續的系統時實現架構最佳實踐。借助 Amazon Well-Architected Tool(可在亞馬遜云科技管理控制臺中免費使用),可以衡量針對每個支柱的系列問題,評估您的工作負載是否遵循這些最佳實踐。在亞馬遜云科技上的工作負載容災:云端恢復白皮書中,我們描述了一套經客戶驗證的最佳實踐,用于設計架構良好的容災工作負載。如需獲得更多關于云架構的專家指導和最佳實踐資源(包括參考架構部署、圖表和白皮書),請訪問亞馬遜云科技架構中
5、心。4 簡介簡介 Amazon Aurora 是完全兼容 MySQL 和 PostgreSQL 的關系型數據庫管理系統(RDBMS)。Amazon Aurora 能夠以十分之一的成本提供媲美商業數據庫的性能和可用性。Amazon Aurora 也是一款全托管數據庫服務,可實現全自動化管理數據庫,例如高可用性(HA)、容災(DR)、復制、擴展、備份、恢復和監控。本白皮書將探討 Amazon Aurora 的高可用性和容災能力,以及如何利用常見的架構模式,在單個區域和多個區域實現高可用性和容災。注意:除非另有說明,本白皮書涵蓋的所有特性、功能和架構模式均注意:除非另有說明,本白皮書涵蓋的所有特性、
6、功能和架構模式均適用于適用于 Amazon Aurora MySQL 和和 Amazon Aurora PostgreSQL。在探索 Amazon Aurora 的高可用性和容災功能之前,讓我們先理解高可用性和容災的含義。5 高可用性高可用性 可用性是衡量系統韌性的常用定量指標。工作負載的可用性指其可訪問時間占總運行時間的百分比。該百分比在一定時間范圍內(如一個月或一年)計算得出(可用時間/總時間),例如 99.99%(4 個 9)。具備高可用性的數據庫能在硬件、軟件或網絡故障等問題發生時,以最少或無需人工介入的方式確保服務等級協議規定的運行性能。傳統的高可用性實現方式是在與源數據庫隔離的硬件
7、上創建一個主數據庫的副本。1當發生中斷時,該副本將被提升為新的主數據庫。數據庫與應用程序的連接可通過虛擬 IP(VIP)、域名系統(DNS)重定向或 Proxy 層等方式進行管理。2系統可結合仲裁投票和心跳機制等多種方法監控主數據庫健康狀態,從而檢測中斷情況。3 容災容災 容災和高可用性是高韌性數據庫架構的兩個完全獨立但同等重要的能力。容災是指企業在自然災害或人為災難發生后恢復 IT 基礎設施訪問和功能的方法。容災策略可能需要人工干預,例如運行腳本、更改端點和調整基礎設施規模。容災通常不僅局限于數據庫層面。例如,發生重大自然災害后,整個數據中心可能無法訪問。在這種情況下,容災流程可用于恢復數據
8、庫和應用程序,使應用能在另一個未受影響的亞馬遜云科技區域繼續運行。容災流程通常包括完善的備份策略。備份可讓數據庫恢復到災難發生前的特定時間點。設計容災流程時,需要考慮的兩個關鍵因素是恢復時間目標(RTO)和恢復點目標(RPO)。RTO 和 RPO 取決于應用程序及其底層數據庫的業務需求。即使在同一企業或部門內,不同的應用程序和工作負載也可能有不同的 RTO 和 RPO 要求。RPO 是指從最近數據恢復點算起可接受的最大間隔長度。它決定了在數據庫中斷與最近一個恢復點之間可允許的數據丟失量。例如,如果您將 RPO 定義為 15 分鐘,那么在發生災難時,您最多可能丟失 15 分鐘的數據。RTO 是指
9、從數據庫中斷到服務恢復的最大可接受延遲時間。它決定了可接受的數據庫不可用時間窗口。例如,如果您確定應用程序的 RTO 為 5 分鐘,那么您的容災策略應該能讓應用程序(包括數據庫和其他應用程序組件)在 5 分鐘內恢復服務。1 高可用性是系統的一種特性,旨在確保系統的運行性能水平(通常指正常運行時間)高于一般水平。2 Proxy(如 Amazon RDS Proxy)是一種中間服務,可以池化和共享應用程序的數據庫連接,從而提升應用程序的擴展能力。借助 Proxy 服務,您可以應對不可預測的數據庫流量突增,快速建立連接,避免連接數超出數據庫配置。通過消除對 DNS 的依賴,Proxy 還可以縮短高可
10、用性配置中的故障轉移時間。3 分布式系統通過仲裁投票機制來執行一致性操作。規范的仲裁機制通過獲得最小投票數來決定是否允許事務執行。心跳是系統以預設的時間間隔產生的信號,用于向其伙伴系統表明自身運行正常。心跳機制是一種常用于高可用系統的同步技術。6 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和
11、容災流程文檔 定期測試和審查高可用性及容災實現流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 Amazon Aurora 架構及其高 可用性和容災功能 分布式存儲分布式存儲 Amazon Aurora 架構從設計之初就考慮了高可用性和容災能力。Amazon Aurora 的存儲子系統是分布式的,專為 Amazon Aurora 量身打造。Amazon Aurora 采用六副本方式,同時在三個可用區復制新寫入數據庫的數據。即使在極少發生的整個可用區故障加上另一個可用區并發存儲節點故障(AZ+1 故障)的情況下
12、,分布式存儲仍能確保您的數據保持完整。這種分布式存儲架構還能利用存儲節點間的 peer-to-peer 協議自動擴展和自我修復,比如應對節點故障和恢復丟失的數據庫寫入。7 盡管 Amazon Aurora 分布式存儲子系統提供了增強的數據持久性,但它本身并不能使數據庫實現高可用性。下面我們來討論 Amazon Aurora 數據庫集群的高可用性方案。Amazon Aurora 單可用區架構示例 Amazon Aurora 架構中,計算資源與存儲解耦,從而允許計算和存儲子系統獨立地從故障中恢復??梢詫⒁粋€ Aurora 數據庫集群部署到單個區域中的一個或多個可用區中。單可用區 Aurora 數據
13、庫集群由一個寫入實例組成,該實例可接受讀取和寫入請求。應用程序 A 只讀實例端點 集群端點 區域 1 可用區 1 寫入實例 數據副本 數據副本 數據副本 集群存儲卷 Amazon Aurora 數據庫集群數據庫集群 8 寫入 讀取 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定
14、期測試和審查高可用性及容災實現流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 Amazon Aurora 多可用區架構示例 多可用區 Aurora 數據庫集群由一個寫入數據庫實例和至少一個(最多 15 個)只讀數據庫實例組成。只讀數據庫實例作為低延遲讀取副本,只能接受讀請求。多可用區 Aurora 數據庫集群是一種全托管的單區域高可用性方案。多可用區 Aurora 數據庫集群需要一個寫入數據庫實例和一個或多個只讀數據庫實例,且只讀實例與寫入實例必須部署在不同的可用區中。以多可用區模式部署時,Amazon A
15、urora 提供 99.99%(4 個 9)的運行時間服務級別協議(SLA)。Aurora 數據庫集群提供一個集群端點(或寫入實例端點),該端點始終連接至當前的寫實例,可接受讀取和寫入請求。Aurora 數據庫集群還提供一個連接至只讀實例的只讀端點。如果存在多個只讀實例,Amazon Aurora 會對所有可用的只讀實例進行負載均衡。采用多可用區架構時,Amazon Aurora 自動檢測寫入實例中斷,并自動實現故障轉移,切換到數據庫集群中的某個只讀實例。如果存在多個只讀實例,可以配置參數值(015)為它們分配優先級順序。優先級最高(參數值為 0)的只讀實例將被選為首要故障轉移目標。故障轉移成
16、功后,使用寫入端點重新連接的應用程序會自動被重定向到新的寫入實例。因此,應用程序無需任何改動即可在故障轉移后重新連接至數據庫。故障轉移最多可能需要 60 秒完成。在此期間及之前應用程序提交的請求都會失敗,因此需要應用程序重新提交那些請求。使用 Amazon Relational Database Service(Amazon RDS)Proxy 可以進一步縮短故障轉移時間,它能在保持應用程序連接的同時自動連接至新的數據庫實例。當故障轉移發生時,Amazon RDS Proxy 會直接將請求路由至新的數據庫實例,可將 Aurora 數據庫的故障轉移時間最多縮短 66%。集群端點 應用程序 A 只
17、讀實例端點 區域 1 可用區 1 可用區 2 可用區 3 只讀實例 只讀實例 寫入實例 數據副本 數據副本 數據副本 集群存儲卷 Amazon Aurora 數據庫集群數據庫集群 9 寫入 讀取 讀取 讀取 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性及容
18、災實現流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 Amazon Aurora 還支持在 Amazon Web Services JDBC Driver 中使用一個增強型 Java 數據庫連接(JDBC)封裝器。該封裝器是現有的開源 JDBC 的擴展。其作用是擴展驅動程序功能,使應用程序能夠充分利用 Amazon Aurora 的功能。Amazon Web Services JDBC Driver 支持 PostgreSQL 和 MySQL(PostgreSQL JDBC Driver 或 MySQL J
19、DBC Driver)。Amazon Web Services JDBC Driver 能夠感知故障轉移,并與 Amazon Aurora 集群協同工作,以最大限度減少停機時間,并在數據庫實例發生故障時快速恢復連接。Amazon Aurora 提供全托管備份能力。您可以為您的 Aurora 數據庫集群啟用自動備份功能,并將備份保留時間設置為 1 到 35 天。配置完成后,Amazon Aurora 將自動持續備份您的數據庫集群。如果需要保留超出備份保留期限的數據,您可以為 Amazon Aurora 集群存儲卷中的數據創建快照。請注意,Amazon Aurora 數據庫集群快照不會自動過期,如
20、果不再需要,您必須手動將其刪除。您可以利用時間點恢復(PITR)功能,將 Aurora 數據庫恢復到備份保留期內的任意時間點。除此之外,您也可以使用 Amazon Backup 服務來管理 Amazon Aurora 數據庫集群的備份。Amazon Aurora Global Database Amazon Aurora 還提供 Amazon Aurora Global Database,可以實現數據庫集群跨多個區域運行。Aurora Global Database 采用異步復制方式復制數據,一般延遲不到 1 秒,同時保持數據庫高可用以運行應用程序工作負載。一個 Aurora Global D
21、atabase 最多可部署到 5 個備區域。每個備區域中最多可配置 15 個只讀實例。這種架構將讀節點規模擴展到最多支持 5 個備區域和 90 個只讀實例。Aurora Global Database 支持在每個區域進行低延遲的快速本地讀取,并能從區域級故障中快速恢復。如果主區域發生故障,您可以將其中一個備區域提升為承擔讀/寫處理的主區域。即使在整個區域服務完全中斷的情況下,Amazon Aurora 數據庫集群通常也能在 1 分鐘內恢復。這可以使您的應用程序實現 1 秒 RPO 和 1 分鐘 RTO,為 Amazon Aurora 數據庫集群的全球業務連續性奠定堅實基礎。Amazon Aur
22、ora Global Database 可以助您快速應對區域性故障,在發生故障后迅速恢復應用可用性。根據具體情況,Amazon Aurora Global Database 支持兩種不同的切換方法:Global Database Switchover(主備切換)和 Global Database Failover(故障轉移)。Global Database Switchover 要求部署的所有區域的數據庫集群都處于可用狀態。您可以通過執行 Global Database Switchover 來交換主集群和備集群的角色。常見的使用場景包括為滿足合規要求的 跨區域容災測試和運維場景。利用 Glo
23、bal Database Switchover 功能,您可以通過調用 SwitchoverGlobalCluster API 或執行 switchover-global-cluster CLI 命令,快速將其中一個備區域提升為主區域。請注意,此功能會在切換至備區域后自動逆轉數據復制的流向。Global Database Switchover 功能還支持將主區域切換回原來的主區域。此外,Global Database Switchover 還可用于區域輪換等使用場景,以實現全天侯運行模式。10 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性
24、和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性及容災實現流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 Global Database Failover 是一個跨區域的數據庫故障轉移過程??稍谥鲄^域發生故障(如區域級 或服務中斷)時,從備區域發起故障轉移流程。您可以通過控
25、制臺,調用 FailoverGlobalCluster API 或執行 failover-global-cluster CLI 命令并設置 AllowDataLoss 參數,發起 Global Database Failover。Global Database Failover 會將選定的備區域數據庫集群提升為主集群,并使用新的主區域數據庫集群的快照重新初始化數據庫拓撲中的所有可用備區域。當舊的主區域從故障中恢復后,Amazon Aurora 會使用當前主區域數據庫集群的快照恢復數據,將該區域重新添加至您的數據庫拓撲中。此外,Amazon Aurora 還會創建快照,從而保留故障轉移前的數據。
26、由于 Aurora Global Database 采用異步復制,因此,Global Database Failover 可能會導致丟失故障轉移時尚未復制到備區域的數據。關于 Global Database Failover 和 Global Database Switchover 的具體細節,請參閱 Amazon Aurora 用戶指南。Amazon Aurora PostgreSQL Global Database 提供 Managed RPO 機制,讓您能夠為您的數據庫規劃和實施 RPO。Amazon Aurora Global Database 還提供寫入轉發功能,可將備區域的寫入操作
27、轉發至主區域。Amazon Aurora Global Database 架構示例 Amazon Aurora 還提供托管式藍/綠部署,可減少重大變更操作導致的停機時間,例如數據庫引擎大小版本升級、測試新的數據庫和應用程序功能,以及 Schema 維護或變更。Amazon Aurora 提供零停機打補丁(ZDP)功能,可顯著降低小版本升級期間應用程序的停機時間。在 Amazon Aurora 小版本升級過程中,零停機打補丁功能會盡最大可能保持客戶端連接。如果零停機打補丁順利完成,在升級過程中,數據庫引擎重啟,但應用程序會話會始終保持連接。數據庫引擎重啟可能導致吞吐量下降,持續時間從幾秒到 1
28、分鐘不等。11 入站復制 應用程序 A 集群端點 應用程序 B 只讀實例端點 只讀實例端點 可用區 1 可用區 2 可用區 3 可用區 1 可用區 2 只讀實例 只讀實例 寫入實例 只讀實例 只讀實例 存儲 存儲 出站復制 主區域 備區域 1 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災
29、流程文檔 定期測試和審查高可用性及容災實現流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 入站復制 單區域實現高可用性和容災單區域實現高可用性和容災 Amazon Aurora 提供全托管的自動備份功能,支持制定滿足業務和合規性要求的單區域容災策略。如果需要長期保留備份,可以使用 Amazon Backup 通過集中策略管理創建手動快照,或者將數據庫集群快照數據導出至 Amazon S3 存儲桶:導出在后臺運行,不會影響運行中集群的性能。要在單個區域內構建高可用 Aurora 數據庫,可將數據庫集群部署到多
30、個可用區中。多可用區數據庫集群包括一個寫入數據庫實例,以及至少一個部署在不同可用區的只讀數據庫實例,提供故障轉移冗余。對于此類數據庫,服務等級協議保證 99.99%(4 個 9)的正常運行時間。多可用區配置可自動檢測和緩解故障,例如當寫入實例發生故障時,自動進行故障轉移,將指定的只讀實例提升為新的主實例。您無需重新配置應用程序,應用程序可通過集群端點和只讀實例端點無縫連接新提升的實例。在多可用區配置中,如果發生數據庫實例故障,底層實例會在故障轉移后自動切換;而在單可用區配置中,在新實例可用之前可能會出現數分鐘的停機 時間??鐓^域擴展高可用性和容災跨區域擴展高可用性和容災 常見的跨區域容災模式是
31、在備區域配置快照備份。這是一種具有較高 RTO 和 RPO 容忍度的跨區域容災模式。在主區域故障時,備區域快照備份不受主區域故障影響,因此可以通過備區域備份來實施恢復策略。相比于單區域 Aurora 數據庫集群部署提供的標準高可用性,Amazon Aurora Global Database提供了更強大的業務連續性和容災方案。Amazon Aurora 的解耦架構設計使單個數據庫集群能夠跨多個區域運行,在提供低延遲本地讀取的同時,還能應對區域級故障,這使 Amazon Aurora 成為擴展高可用性和容災策略的理想跨區域解決方案。Amazon Aurora Global Database 可通
32、過 Global Database Failover 功能,在主區域發生故障時將工作負載快速故障轉移到備區域,從而實現分鐘級 RTO。對于區域輪換、全天候式應用程序或容災演練等場景,在主區域和備區域均可用且運行正常的情況下,可以使用 Global Database Switchover 功能。此外,Amazon Aurora Global Database 還支持對備區域采用 headless 集群配置,即備集群只包含 Amazon Aurora 存儲卷,不包含任何數據庫實例。Headless 配置作為容災策略的一部分,除了可以節約成本,還能確保備份不受主區域故障影響。您可以在將備區域提升為主
33、區域前,為備區域集群添加一個數據庫實例。此外,您還可以選擇在備區域預配 Amazon Aurora Serverless v2 實例,這是一種經濟高效的部署方案。如果您考慮采用 headless 配置,建議您權衡 RTO 和成本控制。12 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程
34、文檔 定期測試和審查高可用性及容災實現流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 監控高可用性和容災環境 Amazon Aurora 提供多種可觀察性工具,包括 Amazon CloudWatch Logs、增強監控和 Amazon RDS Performance Insights,用于監控數據庫集群的運行狀況、可用性和性能。監控單區域 Aurora 數據庫集群的關鍵 CloudWatch 指標包括:請參閱 Amazon Aurora 指標參考和監控工具,了解監控 Amazon Aurora 數據庫集群
35、的其他指標和工具。監控跨區數據庫的關鍵 CloudWatch 指標包括:注意:AuroraGlobalDBRPOLag 僅監測用戶 transaction 的延遲。AuroraGlobalDBProgressLag 還監測了健康檢查 transaction 的延遲。因此,即便用戶 transaction 很少或者沒有 transaction 時,您也可以通過監測 AuroraGlobalDBProgressLag 來查看健康檢查 transaction 的延遲,來診斷網絡問題。此外,Amazon Aurora PostgreSQL Global Database 還提供以下兩個 函數:顯示 G
36、lobal Database 的備數據庫集群的延遲時間。列出主數據庫集群和備數據庫集群下的所有備數據庫實例。請參閱監控 Amazon Aurora PostgreSQL Global Database 了解如何使用這些函數的更多信息。CPUUtilization DatabaseConnections NetworkThroughput NetworkTransmitThroughput NetworkReceiveThroughput StorageNetworkThroughput StorageNetworkTransmitThroughput StorageNetworkReceive
37、Throughput AuroraReplicaLag aurora_global_db_status aurora_global_db_instance_status AuroraGlobalDBDataTransferBytes AuroraGlobalDBProgressLag AuroraGlobalDBReplicatedWriteIO AuroraGlobalDBReplicationLag AuroraGlobalDBRPOLag 13 監控監控 Amazon Aurora 事件事件 Amazon RDS 事件的生成表明 Amazon Aurora 環境發生了變化。例如,當為數據
38、庫集群打補丁時,Amazon Aurora 會生成一個事件。Amazon Aurora 會幾乎實時地將事件傳遞至 Amazon CloudWatch Events 和 Amazon EventBridge。Amazon RDS 將事件分為不同的類別,您可以訂閱這些類別,當某個類別中發生事件時就會收到通知。有關更多詳細信息,請參閱 Amazon Aurora 用戶指南中的使用 Amazon RDS 事件通知。14 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和
39、容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性及容災實現流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 最佳實踐 指定指定 RTO 和和 RPO 根據業務需求制定容災策略。首先,為每個工作負載指定 RPO 和 RTO。您可以進一步將工作負載分為不同層級,關鍵任務層級的工作負載有更嚴格的服務等級(如更低的 RTO 和 RPO),而較低層級工作負載的限制條
40、件則相應放寬,同時要考慮相關成本影響。請務必根據業務優先級設置 RTO 和 RPO 目標,因為更嚴格的恢復目標通常需要權衡取舍,比如更高的運營成本。制定與制定與 RTO 和和 RPO 相匹配的高可用性和容災策略相匹配的高可用性和容災策略 高可用性策略:高可用性策略:創建多可用區 Aurora 數據庫集群,在單個區域內實現高度可用的 Aurora 數據庫部署,由 Amazon Aurora 提供 99.99%(4 個 9)的正常運行時間 SLA 保障。此外,您還可以添加 Aurora 只讀實例作為故障轉移目標,在寫入實例故障時隨時接管工作負載。Amazon Aurora 自動管理故障轉移過程。容
41、災策略:容災策略:在確定 RTO 和 RPO 后,您需要設置與其相匹配的自動備份保留時間。自動備份的保留期限決定了您可以將 Aurora 數據庫集群還原到多久 之前的時間點。默認情況下,Amazon Aurora 的自動備份保留時間為 1 天,但您可以將備份保留時間延長至 35 天。保留期越長,可用于恢復的歷史數據就越多,這直接影響 RTO。根據您的容災策略,可能手動快照需要保留更長時間。此外,在不同的區域和賬戶中保存備份副本,可以提供額外的韌性保障。使用 Amazon Backup 可簡化這一過程。Amazon Backup 提供手動快照的生命周期管理和集中式備份計劃配置。15 編寫并測試高
42、可用性和容災流程文檔編寫并測試高可用性和容災流程文檔 請詳細記錄實現高可用性和容災流程。Amazon Aurora 數據庫管理員手冊中包含了高可用性和容災流程,如自動備份、備份時段、維護時段和故障轉移配置等。您還可以使用故障注入查詢來測試 Aurora 數據庫集群的容錯能力。不過,務必要創建一份包含所有相關細節的操作手冊,例如腳本位置、需要收集的數據點,以及按何種順序執行哪些流程。這些細節需要記錄在案,并在災難發生時明確傳達。編寫完成后,定期開展容災演練來測試該流程。根據需要更新操作手冊。定期測試和審查高可用性及容災實現流程定期測試和審查高可用性及容災實現流程 工作負載本身會發生變化,這種變化
43、可能影響當前高可用性和容災流程的有效性。制定流程,定期測試實現高可用性和容災的流程,驗證其有效性,并找出任何需要改進的地方。例如,數據庫的規??赡芤呀浽鲩L,導致備份和恢復時間比最初設計的更長,您需要做好響應的準備。16 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查
44、高可用性及容災實現流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 常見的高可用性和容災使用常見的高可用性和容災使用場景與設計模式場景與設計模式 使用場景:多區域應用程序通過容災區域實現讀使用場景:多區域應用程序通過容災區域實現讀/寫能力寫能力 在備區域部署應用程序,除了能在多個區域為用戶提供低延遲讀取服務,備區域上的應用程序還可能向數據庫寫入數據。例如,寫入轉發功能可以允許遠程用戶將數據寫入就近備區域中的只讀實例,而無需直接寫入主區域,這樣可以降低全球分布式應用程序的延遲。設計模式:通過全設計模式:通過全球
45、球只讀副本實現寫入轉發只讀副本實現寫入轉發 使用 Amazon Aurora Global Database 的容災只讀實例進行就近讀取,根據用戶距離選擇就近實例,提升性能。這種情況下,備區域不僅僅是用于被動容災。寫入轉發允許應用程序將寫入操作指向本地的只讀實例。這種直接寫入方式能夠透明地處理會話和事務上下文,確保寫入與后續讀取之間的一致性。主數據庫集群是權威數據源,其數據更改首先被保存到存儲層,然后復制 Aurora Global Database 的備集群。這種架構允許將寫入操作定向到您的 Aurora Global Database 的任何遠程集群,簡化了應用程序開發。17 Amazon
46、 Aurora Global Database 寫入轉發示例 有關更多詳細信息,請參閱 Amazon Aurora 用戶指南中的在 Amazon Aurora Global Database 中使用寫入轉發。使用場景:節省容災成本使用場景:節省容災成本 如果您正在尋找一種經濟實惠且亞秒級 RPO 延遲的多區域韌性解決方案,Amazon Aurora Global Database 是很好的選擇。Aurora Global Database 的 headless 集群模式允許備區域僅包含存儲卷而無數據庫實例。這種方法適用于 RTO 超過在備區域配置數據庫實例所需時間(通常最多為 10 分鐘)的容
47、災場景。設計模式:設計模式:Amazon Aurora Global Database 中的中的 headless 集群集群 Aurora Global Database 中的 headless 備集群不含任何數據庫實例,而主區域的集群由一個寫入實例、一個或多個只讀實例,以及存儲主數據的集群存儲卷組成。在這種配置下,備區域僅包含存儲備數據的備集群存儲卷。Amazon Aurora 使用專用基礎設施,通過亞馬遜云科技骨干網絡跨區域復制數據,延遲很低。這種 headless 集群配置方式可以降低您的 Aurora Global Database 的資源成本,因為架構中存儲與計算解耦,未配置數據庫實
48、例的備區域不產生計算資源費用。Amazon Aurora Global Database headless 集群示例 有關更多詳細信息,請參閱 Amazon Aurora 用戶指南中的在備區域創建 headless Aurora 數據庫集群。應用程序 A 主區域 備區域 1 可用區 1 可用區 2 可用區 3 只讀實例 只讀實例 寫入實例 存儲 存儲 應用程序 B 1.寫入只讀 端點 主區域 備區域 1 可用區 1 可用區 2 可用區 3 可用區 1 可用區 2 只讀實例 只讀實例 寫入實例 2.寫入請求 被轉發至主區域的寫入實例 只讀實例 只讀實例 3.提交寫請求 存儲 4.復制更新到備區域
49、 存儲 出站復制 入站復制 入站復制 18 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性和容災流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 出站復制 使用場景:限制最
50、大使用場景:限制最大 RPO 損失損失 在某些情況下(如網絡或工作負載導致的事件),從主集群到備集群的復制可能會出現延遲,可能導致 RPO 延遲增加。對于數據保護要求較高的應用程序,此設計模式可以緩解備集群 RPO 延遲增加問題。設計模式:設計模式:Managed RPO 注意:這種架構模式只適用于 Amazon Aurora PostgreSQL Global Database。對于 Amazon Aurora PostgreSQL Global Database,可以通過 rds.global_db_rpo 參數來管理 RPO。Amazon Aurora 會監控 AuroraGlobalD
51、BRPOLag 指標,確保至少有一個集群符合指定 RPO 窗口期。只要有任何一個備集群的 RPO 延遲在指定范圍內,就會提交主集群上的事務。如果所有備集群的延遲都超出指定 RPO 延遲范圍,主集群事務將被阻止,直到一個備集群數據完全同步,以保證符合 RPO 要求。設置 RPO(rds.global_db_rpo=20 秒)。兩個備區域的 RPO 延遲都在指定范圍內。備區域 1 應用程序 A 可用區 1 可用區 2 只讀實例 只讀實例 主區域 RPO 延遲:15 秒 可用區 1 可用區 2 可用區 3 存儲 只讀實例 只讀實例 寫入實例 備區域 2 存儲 可用區 1 可用區 2 只讀實例 只讀實
52、例 出站復制 存儲 RPO:將參數 rds.global_db_rpo 的值設為 20(秒)有效的 RPO 值范圍從 20 秒到 2,147,483,647 秒 RPO 延遲:10 秒 入站復制 入站復制 19 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性
53、和容災流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 其中一個備區域的 RPO 延遲仍在指定范圍內,寫入操作繼續進行 兩個備區域的延遲都超出了允許的 RPO 延遲范圍,主區域的寫入操作被暫停 備區域 1 應用程序 A 可用區 1 可用區 2 只讀實例 只讀實例 主區域 RPO 延遲:35 秒 可用區 1 可用區 2 可用區 3 存儲 只讀實例 只讀實例 寫入實例 備區域 2 存儲 可用區 1 可用區 2 只讀實例 只讀實例 出站復制 存儲 RPO:將參數 rds.global_db_rpo 的值設為 20(
54、秒)有效的 RPO 值范圍從 20 秒到 2,147,483,647 秒 RPO 延遲:22 秒 備區域 1 應用程序 A 可用區 1 可用區 2 只讀實例 只讀實例 主區域 RPO 延遲:25 秒 可用區 1 可用區 2 可用區 3 存儲 只讀實例 只讀實例 寫入實例 備區域 2 存儲 可用區 1 可用區 2 只讀實例 只讀實例 出站復制 存儲 RPO:將參數 rds.global_db_rpo 的值設為 20(秒)有效的 RPO 值范圍從 20 秒到 2,147,483,647 秒 RPO 延遲:10 秒 入站復制 入站復制 入站復制 入站復制 20 摘要與簡介 摘要 您的架構是否符合 良
55、好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性和容災流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 其中一個備區域的延遲恢復到目標范圍內,寫入操作得以恢復 使用場景:滿足容災測試的監管合規性要求使用場景:滿足
56、容災測試的監管合規性要求 常見標準做法是,在區域間定期輪換運行主系統。這不僅可以確保流程的完整性和準確性,還能確保員工為容災場景做好準備。Global Database Switchover 支持的使用場景包括容災演練、主數據庫輪換,或無需重新創建集群即可還原到之前的主區域。設計模式:設計模式:Global Database Switchover Global Database Switchover 可將 Amazon Aurora Global Database 的主集群例行遷移至不同區域,適用于運維和計劃流程等受控場景。例如,一家在多地設有分支機構的金融機構可能采用這種方法,每個季度在指定
57、的備區域間輪換運行主集群。在切換過程中,當前主區域的主集群會轉為只讀狀態,同時同步數據到備區域的存儲卷,確保數據零丟失(RPO=0)。被選中的備集群會被提升為主集群,維持數據復制拓撲結構,所有區域的數據庫實例都會重啟,這會導致幾分鐘內的短暫不可用。備區域 1 應用程序 A 可用區 1 可用區 2 只讀實例 只讀實例 主區域 RPO 延遲:35 秒 可用區 1 可用區 2 可用區 3 存儲 只讀實例 只讀實例 寫入實例 備區域 2 存儲 可用區 1 可用區 2 只讀實例 只讀實例 出站復制 存儲 RPO:將參數 rds.global_db_rpo 的值設為 20(秒)有效的 RPO 值范圍從 2
58、0 秒到 2,147,483,647 秒 RPO 延遲:15 秒 入站復制 入站復制 21 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性和容災流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者
59、 延伸閱讀 文檔修訂 Amazon Aurora Global Database 三區域架構示例 切換完成后,備區域 1 成為新的主區域。在舊主區域停止寫入的同時,備區域的數據完成完全同步,實現 RPO=0。備區域 1 應用程序 A 可用區 1 可用區 2 只讀實例 只讀實例 主區域 可用區 2 可用區 3 存儲 只讀實例 只讀實例 寫入實例 備區域 2 存儲 可用區 1 可用區 2 只讀實例 只讀實例 出站復制 存儲 備區域 1 應用程序 A 可用區 1 可用區 2 只讀實例 只讀實例 主區域 可用區 2 可用區 3 存儲 只讀實例 只讀實例 寫入實例 備區域 2 存儲 可用區 1 可用區
60、2 只讀實例 只讀實例 出站復制 存儲 入站復制 入站復制 入站復制 入站復制 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性和容災流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀
61、文檔修訂 可用區 1 可用區 1 22 新的主區域允許寫入操作且維持數據復制拓撲結構 有關更多詳細信息,請參閱 Amazon Aurora 用戶指南中的 執行 Global Database Switchover。使用場景:從區域故障中快速恢復使用場景:從區域故障中快速恢復 在極少數情況下,Amazon Aurora Global Database 的主區域可能發生意外中斷,導致主集群及其寫入數據庫實例不可用,同時數據復制也會停止。在這種情況下,Global Database Failover 的設計模式可以最大程度減少停機時間和數據丟失。設計模式:設計模式:Global Database F
62、ailover(“區域(“區域故障故障”場景)”場景)下線應用程序,防止寫入發送至主集群。檢查數據庫的所有備集群的延遲時間,選擇復制延遲最短的備區域(AuroraGlobalDBRPOLag);使用這個備區域可最大限度減少當前故障主區域的數據丟失。重新配置應用程序,將所有寫入操作指向新提升的主區域中的 Aurora Global Database 集群,并更新端點引用。在 Amazon RDS Proxy 中重定向寫入操作(如適用)。舊主區域恢復后,Amazon Aurora 將自動把它作為備區域重新添加至您的 Aurora Global Database 配置。這樣就保持了全球集群的原始拓撲
63、結構。有關更多詳細信息,請參閱 Amazon Aurora 用戶指南中的 執行 Global Database Failover。應用程序 A 主區域 可用區 1 可用區 2 寫入實例 只讀實例 備區域 1 可用區 1 可用區 2 可用區 3 存儲 只讀實例 只讀實例 只讀實例 備區域 2 存儲 可用區 1 可用區 2 只讀實例 只讀實例 入站復制 存儲 入站復制 出站復制 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aur
64、ora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性和容災流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 23 Amazon Aurora Global Database 三區域架構示例 發生故障轉移時,主區域停止接受寫請求。識別出復制延遲最短的某個備區域(本例為備區域 1)。備區域 1 應用程序 A 可用區 1 可用區 2 只讀實例 只讀實例 主區域 可用區 2 可用區 3 存儲 只讀實例 只
65、讀實例 寫入實例 備區域 2 存儲 可用區 1 可用區 2 只讀實例 只讀實例 出站復制 存儲 應用程序 A 可用區 2 主區域 只讀實例 可用區 2 存儲 只讀實例 只讀實例 可用區 1 備區域 2 存儲 只讀實例 可用區 1 備區域 1 入站復制 入站復制 入站復制 入站復制 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性
66、和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性和容災流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 可用區 1 24 故障轉移完成后,備區域 1 提升為新的主區域。應用程序 A 連接的端點切換至新主區域中的數據庫集群端點。舊主區域恢復后,Amazon Aurora 自動將其作為備區域重新添加至該 Global Database 拓撲結構中 應用程序 A 主區域 可用區 1 可用區 2 寫入實例 只讀實例 存儲 應用程序 A 主區域 可用區 1 可用區 2 寫入實例 只讀實例 備區域
67、1 可用區 1 可用區 2 可用區 3 存儲 只讀實例 只讀實例 只讀實例 備區域 2 存儲 可用區 1 可用區 2 只讀實例 只讀實例 入站復制 存儲 入站復制 出站復制 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性和容災流程 常見的高可用性和容災使用場
68、景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 25 在打補丁、升級和重大 Schema 變更期間保持可用性 計劃內停機(通常由版本升級、打補丁和 Schema 變更等維護任務所需)可能持續幾分鐘到幾天不等。使用數據庫副本執行這些任務,然后將生產流量切換至新提升的副本上,有助于減少停機時間。然而,復制設置、提升和切換過程可能很復雜,容易出錯,特別是在大規模場景下。Amazon Aurora 藍/綠部署提供托管式解決方案,極大簡化了復制流程。Amazon Aurora 藍藍/綠部署綠部署 Amazon Aurora 的藍/綠部署功能支持創建
69、與生產環境保持同步的預生產環境。生產環境(藍環境)和預生產環境(綠環境)通過邏輯日志復制保持同步。綠環境可快速提升為生產環境,且不會丟失數據。切換期間會阻止對兩個環境的寫入,確保數據同步。將生產流量切換至新提升的綠環境通常會導致不到 1 分鐘的短暫停機,但根據實際工作負載情況,停機時長可能更長。切換完成后,藍環境的名稱和端點將分配給新提升的綠環境,無需對應用程序進行任何更改。26 生產環境 讀取訪問 讀/寫訪問 生產環境應用程序 讀取訪問 只讀實例(auroradb-instance-2)只讀實例端點 復制 Amazon Aurora 可用區 2 集群端點 Amazon Aurora 只讀實例
70、端點 只讀實例(auroradb-instance-3)可用區 1 Amazon Aurora 復制 可用區 3 區域 1 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性和容災流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema
71、變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 寫入實例(auroradb-instance-1)27 生產環境和預生產環境 生產環境(藍環境)Amazon Aurora 數據庫集群數據庫集群(auroradb)可用區 3 復制 Amazon Aurora 可用區 1 只讀實例(auroradb-instance-3)只讀實例端點 讀取訪問 Amazon Aurora 生產環境應用程序 讀取訪問 讀取訪問 讀/寫訪問 集群端點 寫入實例(auroradb-instance-1-green-abc123)可用區 2 測試應用程序 讀取訪問 Amazon Aurora 復制 只讀實例端點 只
72、讀實例(auroradb-instance-2-green-abc123)Amazon Aurora 只讀實例端點 只讀實例(auroradb-instance-3-green-abc123)可用區 1 Amazon Aurora 復制 可用區 3 預生產環境(綠環境)Amazon Aurora 數據庫集群數據庫集群(auroradb-green-abc123)邏輯復制 只讀實例(auroradb-instance-2)只讀實例端點 復制 Amazon Aurora 可用區 2 寫入實例(auroradb-instance-1)集群端點 區域 1 摘要與簡介 摘要 您的架構是否符合 良好架構原
73、則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 RTO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性和容災流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 讀/寫訪問 28 新生產環境和舊生產環境 有關更多詳細信息,請參閱 Amazon Aurora 用戶指南中的使用 A
74、mazon RDS 藍/綠部署進行數據庫更新。讀取訪問 讀/寫訪問 生產環境應用程序 讀取訪問 只讀實例(auroradb-instance-2-old1)只讀實例端點 復制 Amazon Aurora 可用區 2 寫入實例(auroradb-instance-1-old1)集群端點 Amazon Aurora 只讀實例端點 只讀實例(auroradb-instance-3-old1)可用區 1 Amazon Aurora 復制 舊生產環境 Amazon Aurora 數據庫集群數據庫集群(auroradb-old1)只讀實例(auroradb-instance-2)只讀實例端點 復制 Ama
75、zon Aurora 可用區 2 寫入實例(auroradb-instance-1)集群端點 Amazon Aurora 只讀實例端點 只讀實例(auroradb-instance-3)可用區 1 Amazon Aurora 復制 新生產環境 Amazon Aurora 數據庫集群數據庫集群(auroradb)區域 1 可用區 3 可用區 3 摘要與簡介 摘要 您的架構是否符合 良好架構原則?簡介 Amazon Aurora 架構及其 高可用性和容災功能 單區域實現高可用性 和容災 跨區域擴展高可用性 和容災 監控高可用性和容災 環境 監控 Amazon Aurora 事件 最佳實踐 指定 R
76、TO 和 RPO 制定與 RTO 和 RPO 相匹配 的高可用性和容災策略 編寫并測試高可用性和 容災流程文檔 定期測試和審查高可用性和容災流程 常見的高可用性和容災使用場景與設計模式 在打補丁、升級和重大 Schema 變更期間保持可用性 總結 貢獻者 延伸閱讀 文檔修訂 29 總結 關系型數據庫是高可用性應用程序的關鍵組件。作為高吞吐量的關系型數據庫管理系統,Amazon Aurora 能夠在云規模環境中保持數據的可用性和持久性。對于關鍵業務工作負載,可使用多可用區 Amazon Aurora 集群提高正常運行時間,緩解可用性事件的影響。Amazon Aurora Global Datab
77、ase 進一步拓展了這一能力,支持全球分布式應用程序,實現最短的恢復時間目標(RTO)、恢復點目標(RPO)和跨區域低延遲讀取,構建強大的容災解決方案。有關 Amazon Aurora 更多詳細信息,請參閱 Amazon Aurora 用戶指南以及使用 Aurora Global Database。30 貢獻者 對本文檔做出貢獻的人員包括:Aditya Samant Amazon RDS 和 Amazon Aurora 數據庫解決方案首席架構師 Shayon Sanyal Amazon RDS 和 Amazon Aurora 數據庫解決方案首席架構師 31 延伸閱讀 如需了解更多信息,請參見:亞馬遜云科技架構中心 亞馬遜云科技上的工作負載容災:云端恢復 Amazon Aurora 容災指南 32