為確保業務不中斷並盡可能減少資料遺失，高可用性 (HA) 和災難復原 (DR) 是 AlloyDB Omni 的重要資料保護策略。高可用性著重於維持資料庫可用性，並盡可能縮短復原時間目標 (RTO)；災難復原則著重於從災難性事件中復原，並盡可能縮短復原點目標 (RPO)。
RTO 和 RPO 應符合業務需求，定義如下：
- RTO 是指資料庫可停機或無法使用的最長時間，超過這個時間，業務就會受到無法接受的影響，例如收益或生產力損失。
- RPO 是指企業在不影響業務需求的前提下，可承受的最大資料損失量。舉例來說，需要完整稽核追蹤記錄的庫存系統，可能會有零資料遺失的要求。
AlloyDB Omni 提供下列可用性參考架構，可提高可用性：
可用性機制
以下是確保可用性的主要機制：
- 資料庫備份
- 資料庫複製
資料庫備份
資料庫備份是資料保護的基本環節，涉及建立資料庫資料檔案的實體副本。不同備份類型 (完整、增量和差異) 在復原點目標 (RPO)、備份大小和時間長度，以及還原時間之間，提供不同的平衡。
為確保復原效率，並在系統故障時盡可能減少資料遺失，完善的備份策略必須同時包含資料庫和預寫記錄檔 (WAL) 備份。定期 (通常是每天) 備份資料檔案至關重要。您也必須備份 WAL 檔案，這些檔案會記錄資料庫修改內容，對於時間點復原和維護還原期間的資料完整性至關重要。
資料庫複製
PostgreSQL 提供副本伺服器，可提高可靠性。這些副本分為「暖」待命 (不接受應用程式連線) 或「熱」待命 (以唯讀模式運作)。系統會持續將主要資料庫的變更套用至副本，確保副本資料維持最新狀態。如果主要資料庫故障，副本會升級為主要狀態，並承擔主要資料庫的責任。
資料庫副本可以與主要執行個體位於相同的可用區或資料中心，也可以位於不同的可用區、不同的區域，或這些位置的組合。副本與主要資料庫的距離越遠，傳送變更以保持副本最新狀態時的延遲時間就越長。對於跨遠距位置的部署作業，為了減輕大規模故障 (例如區域故障) 的影響，資料複製通常會以非同步方式進行。這種做法可避免這類設定可能發生的效能降低問題。
在高可用性部署中，副本通常會部署在主要資料庫附近。舉例來說，如果副本部署在同一資料中心內的不同可用區，則可提供較低的 RTO，且 RPO 接近零。另一方面，在災難復原設定中，副本會部署在不同的資料中心或區域，具體取決於所需的服務中斷防護層級。這種方法會導致 RPO 較高 (因為複製作業可能為非同步)，且 RTO 各不相同。
下表摘要說明 AlloyDB Omni 可用性參考架構使用的機制：
| 功能 | 標準 | Enhanced | Premium |
|---|---|---|---|
| 備份 | ✔ | ✔ | ✔ |
| 可用區副本 | ❌ | ✔ | ✔ |
| 跨可用區副本 | ❌ | ✔ | ✔ |
| 區域副本 | ❌ | ❌ | ✔ |
表格 1。支援的 AlloyDB Omni 可用性機制
資料庫故障和復原情境
資料庫故障可能發生在下列層級：
- 執行個體 (節點或伺服器) 故障：資料庫本身故障。
- 伺服器故障：託管資料庫的伺服器故障。
- 可用區故障：伺服器所在的整個資料中心發生故障。
- 區域故障：包含多個資料中心 (可用區) 的整個區域無法使用，例如因洪水或大地震。
當事件數量減少，且預防這些事件的成本增加時，災害的可能性和風險就會降低。企業必須判斷自身的風險承受度，並選擇要接受潛在的中斷，還是投資更具韌性的架構，盡可能降低風險。
下表摘要列出 AlloyDB Omni 參考架構支援的復原情境：
| 災害類型 | 標準 | Enhanced | Premium |
|---|---|---|---|
| VM/執行個體故障 | ✔ | ✔ | ✔ |
| 節點/伺服器故障 | ✔ | ✔ | ✔ |
| 可用區故障 | ❌ | ✔ | ✔ |
| 區域故障 | ❌ | ❌ | ✔ |
表格 2。支援的復原情境
請考量 AlloyDB Omni 資料庫的業務目標，例如關鍵應用程式需要多個 9 (99.99%) 的可用性，以及復原時零資料遺失。可用性參考架構的目標是滿足 RTO 和 RPO 需求。
AlloyDB Omni 提供標準、進階和頂級可用性架構，可保護資料庫免於計畫內和計畫外停機，滿足各種業務需求。舉例來說，開發環境可能使用具備備份功能的基本防護，而重要應用程式則可採用高可用性和災難復原設定。
後續步驟
進一步瞭解 AlloyDB Omni 可用性參考架構：