高可用性和資料復原能力

本頁說明高可用性,以及建議使用的工具。這些工具也支援為啟用透明資料加密 (TDE) 的叢集設定高可用性。

關於資料韌性

您可以從可用性、服務還原時間和資料遺失的角度,思考資料韌性。可用性通常以正常運作時間來衡量,並以資料庫可用時間的百分比表示。舉例來說,如要達到 99.99% 的可用性,資料庫每年停機時間不得超過 52.6 分鐘,每月不得超過 4.38 分鐘。服務中斷後恢復服務所需的時間稱為復原時間目標 (RTO)。因服務中斷而可接受的資料遺失量稱為復原點目標 (RPO),以交易遺失的時間長度表示。舉例來說,如果 RPO 為 10 分鐘,代表發生故障時,您最多可能會遺失 10 分鐘的資料。

一般而言,我們會一併設定可用性目標 (即服務水準目標,簡稱 SLO),以及復原時間目標 (RTO) 和復原點目標 (RPO)。舉例來說,針對特定工作負載,您可以將 SLO 設為 99.99%,並要求 RPO 為 0,也就是在發生任何故障時不得遺失資料,且 RTO 為 30 秒。如果是其他工作負載,您可以將 SLO 設為 99.9%,RPO 設為 5 分鐘,RTO 設為 10 分鐘。

您可以透過資料庫備份,實作基本的資料庫復原機制。 AlloyDB Omni 支援使用 pgBackRest 備份,並封存資料庫的預寫記錄 (WAL) 檔案,盡量減少資料遺失。採用這種做法時,如果主要資料庫發生故障,可以從備份還原,RPO 為幾分鐘,RTO 則為幾分鐘到幾小時,視資料庫大小而定。

如需更嚴格的 RPO 和 RTO 規定,您可以使用 Patroni,以高可用性設定設置 AlloyDB Omni。在這個架構中,有一個主要資料庫和兩個待命 (或副本) 資料庫。您可以設定 AlloyDB Omni 使用標準 PostgreSQL 串流複寫,確保在主要資料庫上提交的每筆交易,都會同步複寫到兩個待命資料庫。這樣一來,在大多數的故障情境中,RPO 為零,RTO 則不到 60 秒。

視叢集設定而定,同步複製可能會影響交易的回應時間,您可以選擇承擔少量資料遺失的風險。舉例來說,您可以透過非同步複製而非同步複製,實作高可用性,以換取較低的交易延遲時間,但 RPO 不為零。由於同步複製可能會影響交易延遲,因此高可用性架構幾乎一律是在單一資料中心內,或在相近的資料中心之間 (相距數十公里或延遲時間 <10 毫秒) 實作。不過,請注意,本文件預設使用同步複製功能。

為因應災難復原 (即防止資料中心或多個資料中心相鄰的區域遺失),AlloyDB Omni 可設定為從主要區域到次要區域的非同步串流複製,通常相距數百或數千公里,或相距 10 到 100 毫秒。在這個設定中,主要區域會設定為在區域內的主要和待命資料庫之間進行同步串流複製,並設定從主要區域到一或多個次要區域的非同步串流複製。您可以在次要區域中設定 AlloyDB Omni,並使用多個資料庫節點,確保從主要區域容錯移轉後,能立即受到保護。

高可用性的運作方式

實作資料庫高可用性的具體技術和工具,會因資料庫管理系統而異。以下是實作資料庫高可用性時,通常會涉及的一些技術和工具,具體情況可能因資料庫管理系統而異:

  • 備援:在多個伺服器或地理區域複製資料庫,可在主要執行個體故障時提供容錯移轉選項。

  • 自動容錯移轉:偵測故障並順暢切換至健全複本的機制,可將停機時間降至最低。系統會轉送查詢,讓應用程式要求傳送至新的主要節點。

  • 資料連續性:Google 實施保護措施,確保資料在發生故障時仍維持完整。包括複製技術和資料一致性檢查。

  • 叢集:叢集是指將多個資料庫伺服器分組,以單一系統的形式共同運作。主要節點會處理讀寫流量,而待命節點則會持續複製資料,提供容錯移轉備援功能,並支援讀取擴充性。

  • 備援:使用故障轉移前的主要節點和備用節點,以原始容量還原為原始架構的方法。

  • 負載平衡:將資料庫要求分配到多個執行個體,可提升效能並處理增加的流量。

  • 監控和快訊:監控工具會偵測伺服器故障、高延遲、資源耗盡等問題,並觸發快訊或自動容錯移轉程序。

  • 備份與還原:如果資料損毀或發生災難性故障,可以使用備份將資料庫還原至先前的狀態。

  • 連線集區 (選用):最佳化與資料庫互動的應用程式效能和擴充性。

高可用性工具

Patroni 是 PostgreSQL 資料庫的開放原始碼叢集管理工具,專為管理及自動化 PostgreSQL 叢集的高可用性而設計。Patroni 使用各種分散式共識系統 (例如 etcd、Consul 或 Zookeeper) 來協調及管理叢集狀態。Patroni 的主要功能和元件包括高可用性、自動容錯移轉、領導者選舉、複製和復原。Patroni 會與資料庫伺服器執行個體上的 PostgreSQL 服務一併執行,管理其健康狀態、容錯移轉和複製作業,確保高可用性和可靠性。

Patroni 使用分散式共識系統儲存中繼資料及管理叢集。在本指南中,我們使用名為 etcd 的分散式設定儲存庫 (DCS)。etcd 的用途之一是儲存及擷取分散式系統資訊,例如設定、健康狀態和目前狀態,確保所有節點的設定一致。

高可用性 Proxy (HAProxy) 是一種開放原始碼軟體,用於負載平衡及 Proxy 處理 TCP 和 HTTP 應用程式。負載平衡器會將網路流量分配到多個伺服器,藉此提高網頁應用程式的效能和可靠性。HAProxy 也會執行健康檢查,維護所連線後端伺服器的健康狀態。如果伺服器未通過健康狀態檢查,HAProxy 會停止將流量傳送至該伺服器,直到伺服器再次通過健康狀態檢查。

同步和非同步複製的注意事項

在 Patroni 管理的 PostgreSQL 叢集中,可以設定同步和非同步模式的複製。根據預設,Patroni 會使用非同步串流複製功能。如果 RPO 規定嚴格,建議使用同步複製。

PostgreSQL 的同步複製功能會等待交易寫入主要執行個體和至少一個同步待命執行個體,然後才提交,確保資料一致。同步複製可確保主要執行個體故障時不會遺失資料,提供強大的資料耐用性和一致性。主要執行個體會等待同步待命執行個體傳送確認訊息,這可能會導致延遲時間變長,且封包往返時間增加,進而降低處理量。這可能會降低整體系統處理量,尤其是在高負載的情況下。

非同步複製功能可讓交易在主要節點上提交,不必等待待命節點確認。主要伺服器會將 WAL 記錄傳送至待機伺服器,後者會以非同步方式套用這些記錄。這種非同步方法可縮短寫入延遲時間並提升效能,但如果主要執行個體在待命執行個體趕上之前故障,則有資料遺失的風險。備用伺服器可能落後主要伺服器,導致容錯移轉期間可能出現不一致的情況。

在 Patroni 叢集中,選擇同步或非同步複製,取決於資料耐用性、一致性和效能的具體需求。如果資料完整性和資料遺失量極低是關鍵,建議採用同步複製;如果優先考量效能和低延遲,則適合採用非同步複製。您可以設定混合式解決方案,包括建立三節點叢集,在同一區域但不同鄰近可用區或資料中心中,設定同步待命節點,並在不同區域或較遠的資料中心中,設定第二個非同步待命節點,以防範區域中斷。

後續步驟