Compute Engine 上 PostgreSQL 叢集的高可用性架構

Last reviewed 2024-12-03 UTC

本文說明幾種架構，可為 Google Cloud上的 PostgreSQL 部署項目提供高可用性 (HA)。高可用性是衡量系統在底層基礎架構故障時的復原能力。在本文件中，HA 是指 PostgreSQL 叢集在單一雲端區域內或多個區域之間的可用性，具體取決於 HA 架構。

本文適用對象為資料庫管理員、雲端架構師和開發運作工程師，他們希望瞭解如何透過提升整體系統運作時間，提高 PostgreSQL 資料層的可靠性。本文探討在 Compute Engine 上執行 PostgreSQL 的相關概念。本文不討論如何使用代管資料庫，例如 PostgreSQL 適用的 Cloud SQL 和 AlloyDB for PostgreSQL。

如果系統或應用程式需要永久狀態來處理要求或交易，則資料永久層 (資料層) 必須可用，才能成功處理資料查詢或變動要求。資料層停機時間會導致系統或應用程式無法執行必要工作。

視系統的服務水準目標 (SLO) 而定，您可能需要提供更高可用性的架構。實現高可用性的方法不只一種，但一般來說，您會佈建備援基礎架構，讓應用程式能快速存取。

本文將討論下列主題：

• 高可用性資料庫概念相關字詞的定義。
• 高可用性 PostgreSQL 拓撲的選項。
• 考量各項架構選項時的背景資訊。

術語

下列術語和概念是業界標準，有助於瞭解本文範圍以外的內容。

複製

寫入交易 (INSERT、UPDATE 或 DELETE) 和結構定義變更 (資料定義語言 (DDL)) 的擷取、記錄和套用程序，會依序套用至架構中的所有下游資料庫副本節點。

主要節點

提供讀取作業的節點，具有最新狀態的永久資料。所有資料庫寫入作業都必須導向主要節點。

副本 (次要) 節點

主要資料庫節點的線上副本。變更會同步或非同步從主要節點複製到副本節點。您可以從副本節點讀取資料，但請注意，資料可能會因複製延遲而略有延遲。

複製延遲

以記錄檔序號 (LSN)、交易 ID 或時間表示的測量值。 複製延遲時間是指變更作業套用至副本與主要節點之間的時間差。

持續封存

一種增量備份，資料庫會持續將依序交易儲存至檔案。

預寫記錄檔 (WAL)

預寫記錄檔 (WAL) 是一種記錄檔，會在資料檔案實際變更前，記錄資料檔案的變更。如果伺服器當機，WAL 是確保寫入資料完整性和耐用性的標準方法。

WAL 記錄

套用至資料庫的交易記錄。WAL 記錄會經過格式化，並儲存為一系列記錄，說明資料檔案頁面層級的變更。

記錄序號 (LSN)

交易會建立 WAL 記錄，並附加至 WAL 檔案。 插入位置稱為記錄序號 (LSN)。 這是一個 64 位元整數，以兩個十六進位數字表示，並以斜線分隔 (XXXXXXXX/YYZZZZZZ)。「Z」代表 WAL 檔案中的偏移位置。

區隔檔案

根據您設定的檔案大小，檔案會包含盡可能多的 WAL 記錄。區隔檔案的檔案名稱會不斷增加，預設檔案大小為 16 MB。

同步複製

一種複製形式，主要伺服器會等待副本確認資料已寫入副本交易記錄，然後才向用戶端確認提交。執行串流複製時，您可以使用 PostgreSQL synchronous_commit 選項，確保主要伺服器和副本之間的一致性。

非同步複製

一種複製形式，主要伺服器不會等待副本確認交易已成功接收，就會向用戶端確認提交。與同步複製相比，非同步複製的延遲時間較短。不過，如果主要執行個體當機，且已提交的交易未轉移至副本，資料就有可能遺失。非同步複製是 PostgreSQL 的預設複製模式，會使用檔案型記錄傳送或串流複製。

檔案式記錄傳送

PostgreSQL 的複製方法，可將 WAL 區隔檔案從主要資料庫伺服器轉移至副本。主要服務會以持續封存模式運作，而每個待命服務則會以持續復原模式運作，以讀取 WAL 檔案。這類複製作業是非同步的。

串流複製

一種複製方法，副本會連線至主要執行個體，並持續接收一連串變更。由於更新是透過串流傳送，因此與記錄傳送複製相比，這種方法可讓副本與主要執行個體保持更同步的狀態。雖然複製作業預設為非同步，但您也可以設定同步複製。

實體串流複製

將變更傳輸至副本的複製方法。這個方法會使用 WAL 記錄，其中包含以磁碟區塊位址和逐位元組變更形式呈現的實體資料變更。

邏輯串流複製

這種複製方法會根據複製身分 (主鍵) 擷取變更，與實體複製相比，可進一步控管資料複製方式。由於 PostgreSQL 邏輯複製功能有限制，邏輯串流複製功能需要針對高可用性設定進行特殊設定。本指南討論的是標準實體複製，不討論邏輯複製。

uptime

資源運作並能回應要求的時間百分比。

故障偵測

識別基礎架構故障的程序。

容錯移轉

將備份或待命基礎架構 (在本例中為副本節點) 升級為主要基礎架構的程序。容錯移轉期間，副本節點會變成主要節點。

切換

在正式環境系統上手動執行容錯移轉的程序。切換作業會測試系統是否正常運作，或將目前的主要節點從叢集移除以進行維護。

復原時間目標 (RTO)

資料層容錯移轉程序完成所需的實際時間長度。RTO 取決於業務上可接受的時間長度。

復原點目標 (RPO)

資料層因容錯移轉而承受的資料遺失量 (以經過的實際時間計算)。RPO 取決於從業務角度來看可接受的資料遺失量。

fallback

在導致容錯移轉的情況獲得解決後，恢復先前主要節點的程序。

自我修復

系統不需人類操作員採取外部動作，即可解決問題的能力。

網路失聯

架構中的兩個節點 (例如主要節點和副本節點) 無法透過網路相互通訊的情況。

腦裂

兩個節點同時認為自己是主要節點時，就會發生這種情況。

節點群組

提供服務的一組運算資源。在本文件中，該服務是資料持續性層。

見證人或仲裁節點

獨立的運算資源，可協助節點群組判斷發生腦裂狀況時應採取的行動。

主要或領導者選舉

一組對等感知節點 (包括見證節點) 決定哪個節點應為主節點的程序。

何時應考慮採用高可用性架構

與單一節點資料庫設定相比，高可用性架構可更有效地防範資料層停機。如要根據業務用途選取最佳選項，您必須瞭解自己對停機時間的容忍度，以及各種架構的取捨。

如要提供更長的資料層運作時間，以滿足工作負載和服務的可靠性需求，請使用高可用性架構。如果您的環境可以容忍一定程度的停機時間，高可用性架構可能會產生不必要的成本和複雜性。舉例來說，開發或測試環境很少需要高資料庫級別可用性。

考量高可用性需求

以下幾個問題可協助您決定最適合貴商家的 PostgreSQL 高可用性選項：

• 您希望達到什麼程度的可用性？您是否需要一個選項，讓服務在只有單一可用區或整個區域故障時，仍能繼續運作？部分高可用性選項僅限於單一區域，其他選項則可跨多個區域。
• 哪些服務或客戶仰賴您的資料層？如果資料持續層發生停機，您的業務會付出什麼代價？如果服務僅供內部客戶使用，且客戶只需偶爾使用系統，則可用性需求可能低於持續為客戶提供服務的面向終端客戶服務。
• 您的營運預算有多少？成本是值得注意的考量因素：為了提供高可用性，基礎架構和儲存空間成本可能會增加。
• 程序需要多高的自動化程度？需要多快完成容錯移轉？(您的 RTO 為何？)高可用性選項會因系統容錯移轉和提供給客戶的速度而異。
• 您是否能承受容錯移轉導致的資料遺失？(您的 RPO 為何？)由於高可用性拓撲的分散式特性，提交延遲時間和因故障而遺失資料的風險之間會相互制衡。

高可用性的運作方式

本節說明 PostgreSQL 高可用性架構基礎的串流和同步串流複製。

串流複製

串流複製是一種複製方法，副本會連線至主要執行個體，並持續接收 WAL 記錄串流。與記錄傳送複製相比，串流複製可讓副本與主要執行個體保持更同步的狀態。PostgreSQL 從第 9 版開始提供內建串流複製功能。許多 PostgreSQL 高可用性解決方案都使用內建的串流複製功能，提供多個 PostgreSQL 副本節點與主要節點保持同步的機制。本文稍後的「PostgreSQL 高可用性架構」一節會討論其中幾種選項。

每個副本節點都需要專屬的運算和儲存資源。副本節點基礎架構與主要節點各自獨立。您可以將副本節點做為熱備援，用於處理唯讀用戶端查詢。這種方法可讓唯讀查詢在主要執行個體和一或多個副本之間進行負載平衡。

串流複製預設為非同步，主要執行個體不會等待副本確認，就會向用戶端確認交易提交。如果主要執行個體在確認交易後，但在副本收到交易前發生故障，非同步複製可能會導致資料遺失。如果副本升級為新的主要執行個體，就不會出現這類交易。

同步串流複製

您可以選擇一或多個副本做為同步待命，將串流複製設為同步。如果您將架構設為同步複製，則主要執行個體必須等到副本確認交易持續性後，才會確認交易修訂。同步串流複製功能可提高耐用性，但交易延遲時間會較長。

synchronous_commit 設定選項也可讓您為交易設定下列漸進式副本耐用性等級：

• local：同步待命副本不會參與修訂確認。WAL 記錄寫入並清除至本機磁碟後，主要執行個體會確認交易修訂版本。主要執行個體上的交易修訂版本不涉及待命副本。如果主要執行個體發生任何故障，交易可能會遺失。
• on [預設]：同步待命副本會先將已提交的交易寫入 WAL，再傳送確認訊息給主要執行個體。使用 on 設定可確保只有在主要和所有同步待命副本同時發生儲存空間故障時，交易才會遺失。由於副本只會在寫入 WAL 記錄後傳送確認，因此查詢副本的用戶端在將相應的 WAL 記錄套用至副本資料庫之前，不會看到變更。
• remote_write：同步待命副本會確認在 OS 層級收到 WAL 記錄，但不保證 WAL 記錄已寫入磁碟。由於 remote_write 不保證 WAL 已寫入，因此如果在寫入記錄之前，主要和次要節點都發生故障，交易可能會遺失。remote_write 的耐用性低於 on 選項。
• remote_apply：同步待命副本會先確認交易收據，並成功套用至資料庫，然後才向用戶端確認交易提交。使用 remote_apply 設定可確保交易會保存至副本，且用戶端查詢結果會立即包含交易的效果。相較於 on 和 remote_write，remote_apply 的耐用性和一致性更高。

synchronous_commit 設定選項可與 synchronous_standby_names 設定選項搭配使用，後者可指定參與同步複製程序的待命伺服器清單。如未指定同步待命名稱，交易修訂版本就不會等待複製作業。

PostgreSQL 高可用性架構

在最基本的層級，資料層高可用性包含下列項目：

• 用來判斷主要節點是否故障的機制。
• 執行容錯移轉的程序，其中副本節點會升級為主要節點。
• 變更查詢轉送作業的程序，讓應用程式要求能傳送至新的主要節點。
• (選用) 採用容錯移轉前的主要和副本節點，並維持原始容量，以便復原至原始架構。

以下各節將概略介紹下列高可用性架構：

• Patroni 範本
• pg_auto_failover 擴充功能和服務
• 有狀態 MIG 和區域性永久磁碟

如果基礎架構或可用區發生中斷，這些高可用性解決方案可將停機時間降至最低。選擇這些選項時，請根據業務需求，在修訂延遲時間和耐用性之間取得平衡。

高可用性架構的重要層面，是為後續容錯移轉或備用方案準備新待命環境所需的時間和手動作業。否則，系統只能承受一次故障，且服務無法避免違反服務水準協議。建議您選取可透過正式環境基礎架構執行手動容錯移轉或切換作業的高可用性架構。

使用 Patroni 範本的高可用性

Patroni 是一套成熟且積極維護的開放原始碼 (MIT 授權) 軟體範本，提供設定、部署及操作 PostgreSQL HA 架構的工具。Patroni 提供共用叢集狀態和架構設定，並保存在分散式設定儲存庫 (DCS) 中。實作 DCS 的選項包括：etcd、Consul、Apache ZooKeeper 或 Kubernetes。下圖顯示 Patroni 叢集的主要元件。

圖 1. Patroni 叢集主要元件的圖表。

在圖 1 中，負載平衡器位於 PostgreSQL 節點前端，而 DCS 和 Patroni 代理程式則在 PostgreSQL 節點上運作。

Patroni 會在每個 PostgreSQL 節點上執行代理程式程序。代理程式程序會管理 PostgreSQL 程序和資料節點設定。Patroni 代理程式會透過 DCS 與其他節點協調。Patroni 代理程式程序也會公開 REST API，您可以查詢該 API，判斷每個節點的 PostgreSQL Service Health 和設定。

為了聲明其叢集成員角色，主要節點會定期更新 DCS 中的領導者金鑰。leader 鍵包含存留時間 (TTL)。如果 TTL 到期且未更新，領導者金鑰會從 DCS 中移除，並開始領導者選舉，從候選集區中選出新的主要節點。

下圖顯示健康的叢集，其中節點 A 成功更新領導者鎖定。

圖 2：健康叢集的圖表。

圖 2 顯示健康的叢集：節點 B 和節點 C 監控，而節點 A 成功更新領導者金鑰。

故障偵測

Patroni 代理會更新 DCS 中的金鑰，持續回報健康狀態。同時，代理會驗證 PostgreSQL 健康狀態；如果代理偵測到問題，就會自行關閉節點，或將節點降級為副本。如下圖所示，如果受損節點是主要節點，其在 DCS 中的領導者金鑰會過期，並會進行新的領導者選舉。

圖 3：受損叢集的圖表。

圖 3 顯示受損的叢集：故障的主要節點最近未更新 DCS 中的領導者金鑰，而非領導者副本則收到領導者金鑰已過期的通知。

在 Linux 主機上，Patroni 也會在主要節點上執行 OS 層級監控程式。這個監控程式會監聽 Patroni 代理程式程序傳送的 keep-alive 訊息。如果程序沒有回應，且未傳送持續運作信號，監控程式就會重新啟動主機。Watchdog 可協助防止腦裂狀況，即 PostgreSQL 節點繼續做為主要節點，但 DCS 中的領導者金鑰因代理程式故障而過期，並選出不同的主要節點 (領導者)。

容錯移轉程序

如果 DCS 中的領導者鎖定到期，候選副本節點就會開始選舉領導者。當副本發現缺少領導者鎖定時，會檢查其複製位置，並與其他副本進行比較。每個副本都會使用 REST API 取得其他副本節點的 WAL 記錄位置，如下圖所示。

圖 4：Patroni 容錯移轉程序圖。

圖 4 顯示 WAL 記錄位置查詢，以及來自有效副本節點的相應結果。節點 A 無法使用，而健康狀態良好的節點 B 和 C 則會互相傳回相同的 WAL 位置。

最新節點 (如果有多個節點位於相同位置，則為多個節點) 會同時嘗試取得 DCS 中的領導者鎖定。不過，只有一個節點可以在 DCS 中建立領導者金鑰。第一個成功建立領導者金鑰的節點，就是領導者競賽的贏家，如下圖所示。或者，您也可以在設定檔中設定 failover_priority 標記，指定偏好的容錯移轉候選項目。

圖 5. 領袖競賽圖表。

圖 5 顯示領袖競賽：兩位領袖候選人嘗試取得領袖鎖定，但兩個節點中只有一個節點 (節點 C) 成功設定領袖金鑰並贏得競賽。

副本在領導者選舉中勝出後，會將自己升級為新的主要副本。從副本升級為主要節點開始，新的主要節點會更新 DCS 中的領導者金鑰，以保留領導者鎖定，其他節點則做為副本。

Patroni 也提供 patronictl 控制工具，可讓您執行切換作業，測試節點容錯移轉程序。這項工具可協助操作人員在正式環境中測試高可用性設定。

查詢轉送

在每個節點上執行的 Patroni 代理程式程序會公開 REST API 端點，顯示目前的節點角色：主要或副本。

REST 端點	主要 HTTP 傳回代碼	副本的 HTTP 傳回代碼
/primary	200	503
/replica	503	200

如果特定節點變更角色，相關健康狀態檢查會變更回應，因此負載平衡器健康狀態檢查可以使用這些端點，通知主要和副本節點流量轉送。Patroni 專案提供負載平衡器 (例如 HAProxy) 的範本設定。內部直通式網路負載平衡器可以使用這些相同的健康狀態檢查，提供類似的功能。

備用程序

如果節點故障，叢集會處於功能低下的狀態。Patroni 的備用程序有助於在容錯移轉後，將高可用性叢集還原至健康狀態。備用程序會自動將受影響的節點初始化為叢集副本，藉此管理叢集恢復原始狀態的過程。

例如，節點可能會因作業系統或基礎架構故障而重新啟動。如果節點是主要節點，且重新啟動的時間超過領導者金鑰存留時間，系統就會觸發領導者選舉，並選取及升級新的主要節點。當「過時」的主要 Patroni 程序啟動時，會偵測到自己沒有領導者鎖定，並自動降級為副本，然後以該身分加入叢集。

如果發生無法復原的節點故障 (例如不太可能發生的可用區故障)，您必須啟動新節點。資料庫運作人員可以手動啟動新節點，也可以使用有狀態的區域代管執行個體群組 (MIG)，並設定節點數量下限，自動執行這項程序。建立新節點後，Patroni 會偵測到新節點是現有叢集的一部分，並自動將節點初始化為副本。

使用 pg_auto_failover 擴充功能和服務的高可用性

pg_auto_failover 是積極開發的開放原始碼 (PostgreSQL 授權) PostgreSQL 擴充功能。pg_auto_failover 透過擴充現有的 PostgreSQL 功能來設定 HA 架構。pg_auto_failover 除了 PostgreSQL 之外，沒有任何依附元件。

如要搭配高可用性架構使用 pg_auto_failover 擴充功能，您至少需要三個節點，每個節點都必須執行 PostgreSQL，並啟用擴充功能。任何節點故障都不會影響資料庫群組的運作時間。由 pg_auto_failover 管理的節點集合稱為「編隊」。下圖顯示 pg_auto_failover 架構。

圖 6：pg_auto_failover 架構圖。

圖 6 顯示 pg_auto_failover 架構，其中包含兩個主要元件：Monitor 服務和 Keeper 代理程式。Keeper 和 Monitor 都包含在 pg_auto_failover 擴充功能中。

監控服務

pg_auto_failover 監控服務是以 PostgreSQL 擴充功能的形式實作；當服務建立監控節點時，會啟動已啟用 pg_auto_failover 擴充功能的 PostgreSQL 執行個體。監控器會維護叢集的整體狀態、從成員 PostgreSQL 資料節點取得健康狀態檢查狀態，並使用有限狀態機 (FSM) 建立的規則來協調群組。根據 FSM 的狀態轉換規則，Monitor 會向群組節點傳達指令，例如升級、降級和設定變更。

Keeper 代理

在每個 pg_auto_failover 資料節點上，擴充功能會啟動 Keeper 代理程式程序。這個 Keeper 程序會觀察及管理 PostgreSQL 服務。Keeper 會將狀態更新傳送至 Monitor 節點，並接收及執行 Monitor 傳送的回應動作。

根據預設，pg_auto_failover 會將所有群組次要資料節點設為同步副本。提交所需的同步副本數量，取決於您在 Monitor 設定的 number_sync_standby。

故障偵測

主要和次要資料節點上的 Keeper 代理程式會定期連線至 Monitor 節點，回報目前狀態，並檢查是否有任何要執行的動作。監控節點也會連線至資料節點，透過執行 PostgreSQL 通訊協定 (libpq) API 呼叫來執行健康狀態檢查，模擬 pg_isready() PostgreSQL 用戶端應用程式。如果一段時間 (預設為 30 秒) 後，這兩項動作都未成功，監控節點會判定資料節點發生故障。您可以變更 PostgreSQL 設定，自訂監控時間和重試次數。詳情請參閱「容錯移轉和容錯」。

如果發生單一節點故障，則會發生下列其中一種情況：

• 如果健康狀態不良的資料節點是主要節點，監控器會啟動容錯移轉。
• 如果健康狀態不良的資料節點是次要節點，監控器會停用該節點的同步複製功能。
• 如果故障的是 Monitor 節點，則無法自動容錯移轉。為避免單點故障，請務必採取適當的監控和災難復原措施。

下圖顯示上述清單中說明的失敗情境和形成結果狀態。

圖 7.pg_auto_failover 故障情境圖表。

容錯移轉程序

群組中的每個資料庫節點都有下列設定選項，可決定容錯移轉程序：

• replication_quorum：布林值選項。如果 replication_quorum 設為 true，系統會將節點視為潛在容錯移轉候選節點
• candidate_priority：介於 0 到 100 之間的整數值。candidate_priority 的預設值為 50，您可以變更這個值，影響容錯移轉優先順序。系統會根據 candidate_priority 值，優先將節點視為潛在容錯移轉候選節點。candidate_priority 值越高的節點，優先順序越高。容錯移轉程序要求在任何 pg_auto_failover 形成中，至少有兩個節點的候選優先順序不為零。

如果主要節點故障，且次要節點具有有效的同步複製功能，且是 replication_quorum 的成員，則系統會考慮將次要節點升級為主要節點。

系統會根據下列漸進式條件，考慮是否要升級次要節點：

• 候選優先順序最高的節點
• 待命資料庫，且已將最先進的 WAL 記錄位置發布至監控器
• 隨機選取做為最終平手決勝依據

如果容錯移轉候選資料庫尚未在 WAL 中發布最先進的 LSN 位置，則該資料庫為「落後候選資料庫」。在這種情況下，pg_auto_failover 會在容錯移轉機制中安排一個中繼步驟：落後的候選節點會從 LSN 位置最先進的待命節點擷取缺少的 WAL 位元組。接著，待命節點會升級。Postgres 允許這項作業，因為串聯複製功能可讓任何待命節點做為其他待命節點的上游節點。

查詢轉送

pg_auto_failure 不提供任何伺服器端查詢轉送功能。相反地，pg_auto_failure 依賴用戶端查詢轉送，使用官方 PostgreSQL 用戶端驅動程式 libpq。定義連線 URI 時，驅動程式可在 host 關鍵字中接受多個主機。

應用程式使用的用戶端程式庫必須包裝 libpq，或實作可為架構提供多個主機的功能，才能支援全自動容錯移轉。

備用廣告和切換程序

當 Keeper 程序重新啟動失敗的節點或啟動新的替代節點時，程序會檢查 Monitor 節點，判斷要執行的下一個動作。如果重新啟動的故障節點先前是主要節點，且監控器已根據容錯移轉程序選取新的主要節點，Keeper 會將這個「過時」的主要節點重新初始化為次要副本。

pg_auto_failure 提供 pg_autoctl 工具，可讓您執行切換作業，測試節點容錯移轉程序。除了讓操作人員在正式環境中測試高可用性設定，這項工具還能協助您在容錯移轉後，將高可用性叢集還原至健康狀態。

使用有狀態 MIG 和區域性永久磁碟的高可用性

本節說明使用下列 Google Cloud元件的高可用性方法：

• 區域性永久磁碟。使用區域永久磁碟時，資料會在區域內的兩個可用區之間同步複製，因此您不需要使用串流複製。不過，高可用性僅限於一個區域中的兩個可用區。
• 有狀態代管執行個體群組。一組有狀態的 MIG 會做為控制層的一部分，讓一個主要 PostgreSQL 節點保持運作。有狀態 MIG 啟動新的執行個體時，可以附加現有的區域永久磁碟。在單一時間點，兩個 MIG 中只有一個會有執行中的執行個體。
• Cloud Storage。Cloud Storage bucket 中的物件包含一項設定，指出兩個 MIG 中哪一個正在執行主要資料庫節點，以及應在哪個 MIG 中建立容錯移轉執行個體。
• MIG 健康狀態檢查和自動修復。健康狀態檢查會監控執行個體健康狀態。如果執行中的節點健康狀態不佳，健康狀態檢查就會啟動自動修復程序。
• Logging。自動修復功能停止主要節點時，系統會在 Logging 中記錄一筆項目。相關記錄項目會使用篩選器匯出至 Pub/Sub 接收器主題。
• 事件導向 Cloud Run 函式。Pub/Sub 訊息會觸發 Cloud Run functions。Cloud Run 函式會使用 Cloud Storage 中的設定，判斷要對每個有狀態的 MIG 採取哪些動作。
• 內部直通式網路負載平衡器。負載平衡器會將流量轉送至群組中執行中的執行個體。這可確保用戶端不會看到因重新建立執行個體而導致的執行個體 IP 位址變更。

下圖顯示使用有狀態 MIG 和區域性永久磁碟的高可用性範例：

圖 8.使用有狀態 MIG 和區域性永久磁碟的高可用性架構圖。

圖 8 顯示健康狀態良好的主要節點，正在處理用戶端流量。用戶端會連線至內部直通式網路負載平衡器的靜態 IP 位址。負載平衡器會將用戶端要求轉送至在 MIG 中執行的 VM。資料磁碟區會儲存在已掛接的區域性永久磁碟。

如要採用這種方法，請建立含有 PostgreSQL 的 VM 映像檔，並在初始化時啟動，做為 MIG 的執行個體範本。您也必須在節點上設定 HTTP 健康狀態檢查 (例如 HAProxy 或 pgDoctor)。HTTP 健康狀態檢查可確保負載平衡器和執行個體群組都能判斷 PostgreSQL 節點的健康狀態。

區域性永久磁碟

如要佈建區塊儲存裝置，在區域中的兩個可用區之間同步複製資料，可以使用 Compute Engine 區域永久磁碟儲存空間選項。區域永久磁碟可提供基礎建構模塊，讓您實作 PostgreSQL 高可用性選項，而不必依賴 PostgreSQL 的內建串流複製功能。

如果主要節點 VM 執行個體因基礎架構故障或可用區中斷而無法使用，您可以強制將區域永久磁碟附加至同一區域備份可用區中的 VM 執行個體。

如要將區域永久磁碟連接至備份可用區中的 VM 執行個體，您可以執行下列任一操作：

• 在備份可用區中維護冷待命 VM 執行個體。冷待命 VM 執行個體是已停止的 VM 執行個體，未掛接區域永久磁碟，但與主要節點 VM 執行個體相同。如果發生故障，冷待命 VM 會啟動，並掛接區域性永久磁碟。冷待命執行個體和主要節點執行個體具有相同的資料。
• 使用相同的執行個體範本，建立一組有狀態 MIG。MIG 提供健康狀態檢查，並做為控制層的一部分。如果主要節點故障，系統會以宣告方式在目標 MIG 中建立容錯移轉執行個體。目標 MIG 定義於 Cloud Storage 物件中。系統會使用個別執行個體設定，來連接區域性永久磁碟。

如果能及時發現資料服務中斷，強制連結作業通常會在不到一分鐘內完成，因此可以達到以分鐘為單位的 RTO。

如果貴商家可以容忍偵測和通報服務中斷，以及手動執行容錯移轉所需的額外停機時間，則不需要自動執行強制附加程序。如果 RTO 容忍度較低，可以自動化偵測和容錯移轉程序。或者，PostgreSQL 適用的 Cloud SQL 也提供這種高可用性方法的完整全代管實作。

故障偵測和容錯移轉程序

高可用性方法會使用執行個體群組的自動修復功能，透過健康狀態檢查監控節點健康狀態。如果健康狀態檢查失敗，系統會將現有執行個體視為健康狀態不良，並停止執行個體。這項停止作業會使用 Logging、Pub/Sub 和觸發的 Cloud Run functions 函式，啟動容錯移轉程序。

為滿足這項 VM 必須一律掛接區域磁碟的需求，Cloud Run functions 會設定其中一個 MIG，在區域性永久磁碟可用的兩個可用區之一建立執行個體。節點故障時，系統會根據 Cloud Storage 中保存的狀態，在替代可用區啟動替換執行個體。

圖 9.MIG 可用區故障圖表。

在圖 9 中，可用區 A 的前主要節點發生故障，Cloud Run functions 已設定 MIG B，在可用區 B 啟動新的主要執行個體。系統會自動設定故障偵測機制，監控新主要節點的健康狀態。

查詢轉送

內部直通式網路負載平衡器會將用戶端轉送至執行 PostgreSQL 服務的執行個體。負載平衡器會使用與執行個體群組相同的健康狀態檢查，判斷執行個體是否能處理查詢。如果節點因重新建立而無法使用，連線就會失敗。執行個體恢復運作後，健康狀態檢查就會通過，新的連線也會轉送至可用的節點。這項設定中只有一個執行中的節點，因此沒有唯讀節點。

備用程序

如果資料庫節點因基礎硬體問題而未通過健康狀態檢查，系統會在其他基礎執行個體上重新建立節點。此時，架構會恢復原始狀態，不需執行任何額外步驟。不過，如果可用區故障，設定會繼續以效能降低的狀態運作，直到第一個可用區復原為止。雖然機率極低，但如果設定區域性 Persistent Disk 複製和有狀態 MIG 的兩個可用區同時發生故障，PostgreSQL 執行個體就無法復原，資料庫在服務中斷期間也無法處理要求。

高可用性選項比較

下表比較 Patroni、pg_auto_failover 和採用區域性永久磁碟的有狀態 MIG 提供的 HA 選項。

設定與架構

Patroni	pg_auto_failover	具備區域性永久磁碟的有狀態 MIG
需要高可用性架構、DCS 設定，以及監控和快訊功能。在資料節點上設定代理程式相對簡單。	除了 PostgreSQL 之外，不需要任何外部依附元件。需要一個專門做為監控器的節點。監控節點需要高可用性和災難復原功能，確保不會發生單點故障 (SPOF)。	完全由 Google Cloud服務組成的架構。一次只能執行一個有效的資料庫節點。

高可用性設定

Patroni	pg_auto_failover	具備區域性永久磁碟的有狀態 MIG
可高度設定：支援同步和非同步複製，並可讓您指定要同步和非同步的節點。包括自動管理同步節點。 可設定多可用區和多區域高可用性。DCS 必須可供存取。	與 Patroni 類似：可高度設定。不過，由於監控器只能做為單一執行個體使用，因此任何類型的設定都必須考量到這個節點的存取權。	僅限單一區域中的兩個可用區，並採用同步複製。

處理網路失聯的能力

Patroni	pg_auto_failover	具備區域性永久磁碟的有狀態 MIG
自我隔離和 OS 層級監控功能可防範腦裂。如果無法連線至 DCS，主要執行個體會自行降級為副本，並觸發容錯移轉，確保耐用性高於可用性。	結合從主要執行個體到監控執行個體和副本執行個體的健康狀態檢查，偵測網路失聯，並在必要時降級。	不適用：一次只能有一個有效的 PostgreSQL 節點，因此沒有網路分區。

費用

Patroni	pg_auto_failover	具備區域性永久磁碟的有狀態 MIG
成本高昂，因為取決於您選擇的 DCS 和 PostgreSQL 副本數量。Patroni 架構不會大幅增加成本。不過，整體費用會受到基礎架構影響，因為基礎架構會使用多個運算執行個體來執行 PostgreSQL 和 DCS。由於這個選項會使用多個副本和獨立的 DCS 叢集，因此費用可能最高。	成本中等，因為需要執行一個監控節點和至少三個 PostgreSQL 節點 (一個主要節點和兩個副本)。	成本低廉，因為任何時候都只有一個 PostgreSQL 節點在執行。您只需支付單一運算執行個體的費用。

用戶端設定

Patroni	pg_auto_failover	具備區域性永久磁碟的有狀態 MIG
對用戶端透明，因為用戶端會連線至負載平衡器。	用戶端程式庫必須支援在設定中定義多個主機，因為這類資料庫不易透過負載平衡器前端處理。	對用戶端透明，因為用戶端會連線至負載平衡器。

擴充性

Patroni	pg_auto_failover	具備區域性永久磁碟的有狀態 MIG
設定擴充性和可用性時，可享有高度彈性。您可以新增更多副本，擴充讀取作業。	與 Patroni 類似：新增更多副本即可擴充讀取作業。	一次只能有一個有效的 PostgreSQL 節點，因此擴充性有限。

自動化 PostgreSQL 節點初始化、設定管理

Patroni	pg_auto_failover	具備區域性永久磁碟的有狀態 MIG
提供管理 PostgreSQL 設定 (patronictl edit-config) 的工具，並自動初始化叢集中的新節點或重新啟動的節點。您可以使用 pg_basebackup 或其他工具 (例如 barman) 初始化節點。	自動初始化節點，但初始化新的副本節點時，只能使用 pg_basebackup。設定管理僅限於 pg_auto_failover 相關設定。	有狀態執行個體群組搭配共用磁碟，就不需要初始化任何 PostgreSQL 節點。由於一次只會有一個節點運作，因此設定管理作業會在單一節點上進行。

自訂彈性和豐富功能

Patroni	pg_auto_failover	具備區域性永久磁碟的有狀態 MIG
提供掛鉤介面，允許在重要步驟 (例如降級或升級) 呼叫使用者可定義的操作。 功能豐富的可設定性，例如支援不同類型的 DCS、不同的初始化副本方式，以及不同的 PostgreSQL 設定方式。 可讓您設定待命叢集，以便使用串聯副本叢集，輕鬆在叢集之間遷移。	由於專案相對較新，因此資料有限。	不適用。

成熟度

Patroni	pg_auto_failover	具備區域性永久磁碟的有狀態 MIG
這項專案自 2015 年起推出，目前已由 Zalando 和 GitLab 等大型公司用於實際工作環境。	2019 年初宣布的新專案。	完全由正式發布的 Google Cloud 產品組成。

維護及監控的最佳做法

維護及監控 PostgreSQL 高可用性叢集，對於確保高可用性、資料完整性和最佳效能至關重要。下列各節提供監控及維護 PostgreSQL 高可用性叢集的一些最佳做法。

定期執行備份和復原測試

定期備份 PostgreSQL 資料庫，並測試復原程序。這麼做有助於確保資料完整性，並在發生服務中斷時盡量縮短停機時間。測試復原程序，驗證備份並在服務中斷前找出潛在問題。

監控 PostgreSQL 伺服器和複製延遲

監控 PostgreSQL 伺服器，確認是否正常運作。監控主要節點和副本節點之間的複製延遲時間。如果延遲時間過長，可能會導致資料不一致，並在發生容錯移轉時增加資料遺失量。設定快訊，在延遲時間大幅增加時通知您，以便及時調查根本原因。使用 pg_stat_replication 和 pg_replication_slots 等檢視畫面，有助於監控複製作業延遲時間。

實作連線集區

連線集區可協助您有效管理資料庫連線。連線集區有助於減少建立新連線的負擔，進而提升應用程式效能和資料庫伺服器穩定性。PGBouncer 和 Pgpool-II 等工具可為 PostgreSQL 提供連線集區。

導入全方位監控機制

如要深入瞭解 PostgreSQL 高可用性叢集，請按照下列步驟建立穩健的監控系統：

• 監控重要的 PostgreSQL 和系統指標，例如 CPU 使用率、記憶體用量、磁碟 I/O、網路活動和有效連線。
• 收集 PostgreSQL 記錄，包括伺服器記錄、WAL 記錄和 autovacuum 記錄，以便深入分析及排解問題。
• 使用監控工具和資訊主頁，以視覺化方式呈現指標和記錄，快速找出問題。
• 將指標和記錄與快訊系統整合，主動通知潛在問題。

如要進一步瞭解如何監控 Compute Engine 執行個體，請參閱「Cloud Monitoring 總覽」。

後續步驟

• 瞭解 Cloud SQL 高可用性設定。
• 進一步瞭解使用區域性永久磁碟的高可用性選項。
• 瞭解 Patroni。
• 瞭解 pg_auto_failover。
• 如要查看更多參考架構、圖表和最佳做法，請瀏覽 Cloud Architecture Center。

貢獻者

作者：Alex Cârciu | 解決方案架構師