本文說明多種架構，可為 Google Cloud上的 PostgreSQL 部署作業提供高可用性 (HA)。高可用性是衡量系統在基礎架構故障時的復原能力。本文所指的高可用性，是指 PostgreSQL 叢集在單一雲端區域內或多個區域間的可用性，具體取決於高可用性架構。
本文適用於資料庫管理員、雲端架構師和 DevOps 工程師，他們希望瞭解如何提高整體系統運作時間，進而提升 PostgreSQL 資料層的可靠性。本文將討論在 Compute Engine 上執行 PostgreSQL 的相關概念。本文不會討論如何使用代管資料庫，例如 PostgreSQL 適用的 Cloud SQL 和 PostgreSQL 適用的 AlloyDB。
如果系統或應用程式需要持續性狀態才能處理要求或交易，資料持續性層 (資料層) 就必須可用，才能順利處理資料查詢或變動的要求。資料層的停機時間會導致系統或應用程式無法執行必要工作。
視系統的服務等級目標 (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 邏輯複製功能有相關限制，因此邏輯串流複製功能需要特別設定，才能用於高可用性設定。本指南討論的是標準實體複寫，而非邏輯複寫。
- 運作時間
- 資源可運作並能回應要求的時間百分比。
- 故障偵測
- 識別基礎架構故障的程序。
- 容錯移轉
- 將備份或待命基礎架構 (在本例中為副本節點) 升級為主要基礎架構的程序。容錯移轉期間，備用節點會成為主要節點。
- 切換
- 在正式版系統上執行手動容錯移轉的程序。切換作業可測試系統是否運作正常，或將叢集中的現有主要節點移出，以進行維護。
- 復原時間目標 (RTO)
- 資料層容錯移轉程序完成所經過的即時時間長度。RTO 取決於從業務角度來看可接受的時間量。
- 復原點目標 (RPO)
- 資料層因容錯移轉而持續發生的資料損失量 (以經過的實際時間計算)。RPO 取決於從業務角度來看，可接受的資料遺失量。
- 備用廣告
- 在導致容錯移轉的狀況獲得改善後，重新啟用先前主要節點的程序。
- 自我修復
- 系統解決問題的能力，不需人工操作員採取外部動作。
- 網路分區
- 架構中的兩個節點 (例如主要和副本節點) 無法透過網路彼此通訊時的狀況。
- 裂腦
- 兩個節點同時認為自己是主要節點時發生的情況。
- 節點群組
- 提供服務的一組運算資源。本文中，該服務是指資料保存層。
- 見證節點或仲裁節點
- 獨立的運算資源，可協助節點群組判斷發生腦裂狀況時應採取的行動。
- 初選或黨魁選舉
- 一組可感知對等互連的節點 (包括見證節點) 決定哪個節點應為主要節點的程序。
高可用性架構的適用時機
與單一節點資料庫設定相比，高可用性架構可提供更完善的保護機制，避免資料層停機。如要為您的業務用途選取最佳選項，您需要瞭解可容許的停機時間，以及各種架構的相應取捨。
如要提高資料層的正常運作時間，以滿足工作負載和服務的可靠性需求，請使用高可用性架構。如果您的環境可容許一定程度的停機時間，高可用性架構可能會造成不必要的成本和複雜度。舉例來說，開發或測試環境不常需要高資料庫層級可用性。
考量高可用性需求
以下幾個問題可協助您決定最適合貴商家的 PostgreSQL HA 選項：
- 你希望達到什麼程度的可用性？您是否需要某個選項，讓服務在單一可用區或整個區域發生故障時，仍能繼續運作？部分高可用性選項僅限於單一區域，其他則可跨多個區域。
- 哪些服務或客戶依賴您的資料層，如果資料持久層發生停機，對您的業務會造成哪些影響？如果服務僅供內部客戶使用，且他們只需要偶爾使用系統，那麼服務的可用性要求可能低於持續為客戶提供服務的面向終端客戶服務。
- 您的營運預算為何？成本是值得注意的考量因素：為了提供高可用性，基礎架構和儲存空間費用可能會增加。
- 程序需要多自動化？需要多快完成容錯移轉？(您的 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選項的耐用性較低。onremote_apply：同步待命副本會先確認收到交易，並成功套用至資料庫，再向用戶端確認交易已提交。使用remote_apply設定可確保交易會保留在副本中，且用戶端查詢結果會立即納入交易的影響。與on和remote_write相比，remote_apply的耐用性和一致性更高。
synchronous_commit 設定選項會與 synchronous_standby_names 設定選項搭配使用，指定參與同步複製程序的待命伺服器清單。如果未指定任何同步待命名稱，交易提交作業就不會等待複製作業完成。
PostgreSQL HA 架構
最基本的資料層 HA 包含下列項目：
- 用於判斷主要節點是否發生故障的機制。
- 執行容錯移轉的程序，其中備用節點會升級為主要節點。
- 變更查詢路徑的程序，讓應用程式要求傳送至新的主要節點。
- (選用) 使用容錯移轉前的主要節點和副本節點，以原始容量還原為原始架構的方法。
以下各節將概述下列 HA 架構：
- Patroni 範本
- pg_auto_failover 擴充功能和服務
- 具狀態 MIG 和地區永久磁碟
如果發生基礎架構或區域中斷，這些高可用性解決方案可將停機時間降到最低。選擇這些選項時，請根據業務需求，在提交延遲時間和耐久性之間取得平衡。
高可用性架構的重要環節，是準備新待命環境以供後續容錯移轉或回復時，所需的時間和手動作業。否則，系統只能承受一次故障，且服務不會受到違反服務等級協議的保護。建議您選取可使用生產基礎架構執行手動容錯移轉或切換作業的 HA 架構。
使用 Patroni 範本的 HA
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 服務健康狀態和設定。
為確保叢集成員角色，主要節點會定期更新 DCS 中的領導者金鑰。領導者鍵包含存留時間 (TTL)。如果 TTL 到期但未更新，系統會從 DCS 逐出主要金鑰，並開始選取程序，從候選集區中選出新的主要金鑰。
下圖顯示健康狀態良好的叢集，其中節點 A 成功更新了領導者鎖定。
圖 2：健康叢集的圖表。
圖 2 顯示健全的叢集：節點 B 和節點 C 會監控，而節點 A 則成功更新領導者金鑰。
故障偵測
Patroni 代理程式會持續更新 DCS 中的金鑰，藉此傳送健康狀態。同時，代理程式會驗證 PostgreSQL 健康狀態；如果代理程式偵測到問題，就會自行關閉節點，或將節點降級為副本。如下圖所示，如果受損節點是主要節點，DCS 中的領導者金鑰就會過期，並進行新的領導者選舉。
圖 3：受損叢集的圖表。
圖 3 顯示受損的叢集：主要節點停止運作，且最近未在 DCS 中更新其領導者金鑰，而非領導者副本則收到領導者金鑰已過期的通知。
在 Linux 主機上，Patroni 也會在主要節點上執行作業系統層級的監控程式。這個監控程式會監聽 Patroni 代理程序傳送的存活訊息。如果程序沒有回應，且未傳送存活訊號，監控程序就會重新啟動主機。如果 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 的備援程序有助於在容錯移轉後，將 HA 叢集還原至正常狀態。系統會自動將受影響的節點初始化為叢集副本，藉此管理叢集的回復程序，讓叢集恢復原狀。
舉例來說，節點可能會因為作業系統或基礎架構發生故障而重新啟動。如果節點是主要節點，且重新啟動時間超過領導者金鑰 TTL，系統就會觸發領導者選舉，並選取及升級新的主要節點。過時的主要 Patroni 程序啟動時，會偵測到自己沒有領導者鎖定，自動降級為副本，並以該身分加入叢集。
如果發生無法復原的節點故障 (例如不太可能發生的區域故障)，您需要啟動新的節點。資料庫運算子可以手動啟動新節點，也可以使用具備狀態的地區代管執行個體群組 (MIG)，並設定最少節點數，自動執行這項程序。建立新節點後，Patroni 會偵測到新節點屬於現有叢集，並自動將節點初始化為副本。
使用 pg_auto_failover 擴充功能和服務進行 HA
pg_auto_failover 是積極開發的開放原始碼 (PostgreSQL 授權) PostgreSQL 擴充功能。pg_auto_failover 會擴充現有的 PostgreSQL 功能，藉此設定高可用性架構。pg_auto_failover 除了 PostgreSQL 之外，沒有任何依附元件。
如要在高可用性架構中使用 pg_auto_failover 擴充功能，您至少需要三個節點，每個節點都必須執行 PostgreSQL，並啟用擴充功能。任何節點發生故障都不會影響資料庫群組的正常運作時間。pg_auto_failover 管理的節點集合稱為「編隊」。下圖顯示 pg_auto_failover 架構。
圖 6：pg_auto_failover 架構圖。
圖 6 顯示 pg_auto_failover 架構，其中包含兩個主要元件：監控服務和 Keeper 代理程式。Keeper 和 Monitor 都包含在 pg_auto_failover 擴充功能中。
監控服務
pg_auto_failover Monitor 服務是以 PostgreSQL 擴充功能的形式實作；當服務建立 Monitor 節點時，會啟動已啟用 pg_auto_failover 擴充功能的 PostgreSQL 執行個體。Monitor 會維護形成作業的全球狀態，從成員 PostgreSQL 資料節點取得健康狀態檢查狀態，並使用有限狀態機 (FSM) 建立的規則協調群組。根據狀態轉換的 FSM 規則，監視器會將升級、降級和設定變更等動作的指令傳達給群組節點。
Keeper 代理程式
在每個 pg_auto_failover 資料節點上，擴充功能會啟動 Keeper 代理程式程序。這個 Keeper 程序會監控及管理 PostgreSQL 服務。Keeper 會將狀態更新傳送至 Monitor 節點，並接收及執行 Monitor 傳送的回應動作。
根據預設，pg_auto_failover 會將所有群組次要資料節點設為同步副本。提交作業所需的同步副本數量，取決於您在監控器上設定的 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_failover 不提供任何伺服器端查詢路徑功能。
pg_auto_failover 則採用用戶端查詢轉送機制，使用官方 PostgreSQL 用戶端驅動程式 libpq。定義連線 URI 時，驅動程式可以在 host 關鍵字中接受多個主機。
應用程式使用的用戶端程式庫必須包裝 libpq，或實作提供多個主機的功能，才能支援全自動容錯移轉。
備援和切換程序
當 Keeper 程序重新啟動失敗的節點，或啟動新的替代節點時，程序會檢查監控節點，判斷要執行的下一個動作。如果失敗並重新啟動的節點先前是主要節點，且監控器已根據容錯移轉程序選取新的主要節點，則 Keeper 會將這個過時的主要節點重新初始化為次要備用資源。
pg_auto_failover 提供 pg_autoctl 工具，可讓您執行切換作業，測試節點容錯移轉程序。除了讓運算子在實際工作環境中測試高可用性設定，這項工具也能在容錯移轉後，協助您將高可用性叢集還原為正常狀態。
使用具備有狀態 MIG 和區域永久磁碟的高可用性解決方案
本節說明使用下列 Google Cloud元件的 HA 方法：
- 區域永久磁碟。 使用地區永久磁碟時，資料會在區域內的兩個可用區之間同步複製，因此不需要使用串流複製功能。不過，高可用性只能在一個區域的兩個區域中使用。
- 有狀態代管執行個體群組。 一對具備狀態的 MIG 會做為控制層的一部分，確保一個主要 PostgreSQL 節點持續運作。有狀態 MIG 啟動新執行個體時，可以附加現有的地區永久磁碟。在單一時間點，只有其中一個 MIG 會執行執行個體。
- Cloud Storage。 Cloud Storage 值區中的物件包含設定，指出兩個 MIG 中哪個正在執行主要資料庫節點，以及應在哪個 MIG 中建立容錯移轉執行個體。
- MIG 健康狀態檢查和自動修復。 健康狀態檢查會監控執行個體的健康狀態。如果執行中的節點不健康，健康狀態檢查就會啟動自動修復程序。
- 記錄。 當自動修復功能停止主要節點時，系統會在記錄中記錄項目。系統會使用篩選器，將相關記錄項目匯出至 Pub/Sub 接收器主題。
- 事件驅動型 Cloud Run functions。 Pub/Sub 訊息會觸發 Cloud Run 函式。 Cloud Run 函式會使用 Cloud Storage 中的設定，判斷要對每個具狀態 MIG 採取哪些動作。
- 內部直通式網路負載平衡器。 負載平衡器會將流量導向群組中正在執行的執行個體。這樣可確保因重新建立執行個體而導致的執行個體 IP 位址變更，不會影響用戶端。
下圖顯示使用有狀態 MIG 和區域永久磁碟的 HA 範例：
圖 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，並將地區永久磁碟掛接至該 VM。冷待命執行個體和主要節點執行個體具有相同的資料。
- 使用相同的執行個體範本建立一對有狀態 MIG。MIG 會提供健康狀態檢查，並做為控制層的一部分。如果主要節點故障，系統會在目標 MIG 中以宣告方式建立容錯移轉執行個體。目標 MIG 定義於 Cloud Storage 物件中。系統會使用每個執行個體的設定，連結地區永久磁碟。
如果及時發現資料服務中斷，強制連接作業通常會在不到一分鐘內完成，因此可以達成以分鐘為單位的 RTO。
如果貴商家可以容忍額外的停機時間，以便偵測及通報服務中斷，並手動執行容錯移轉，則不需要自動執行強制附加程序。如果您的 RTO 容許度較低，可以自動執行偵測和容錯移轉程序。或者，您也可以使用 PostgreSQL 適用的 Cloud SQL，這個服務提供全代管的 HA 做法。
故障偵測和容錯移轉程序
高可用性方法會使用執行個體群組的自動修復功能，透過健康狀態檢查監控節點健康狀態。如果健康狀態檢查失敗，現有執行個體會被視為健康狀態不良，並停止執行。這個停止作業會使用 Logging、Pub/Sub 和觸發的 Cloud Run 函式，啟動容錯移轉程序。
為滿足這部 VM 必須一律掛接區域磁碟的要求，Cloud Run 函式會設定其中一個 MIG，在區域永久磁碟可用的兩個區域之一建立執行個體。節點故障時，系統會根據 Cloud Storage 中保存的狀態，在替代區域啟動替代執行個體。
圖 9. MIG 中的可用區故障圖。
在圖 9 中，區域 A 的前一個主要節點發生故障，Cloud Run functions 已設定 MIG B 在區域 B 中啟動新的主要執行個體。系統會自動設定故障偵測機制，監控新主要節點的健康狀態。
查詢路徑
內部直通式網路負載平衡器會將用戶端連線路徑導向執行 PostgreSQL 服務的執行個體。負載平衡器會使用與執行個體群組相同的健康狀態檢查，判斷執行個體是否可處理查詢。如果節點正在重建，因此無法使用，連線就會失敗。 執行個體恢復運作後，健康狀態檢查就會開始通過，新的連線也會轉送至可用節點。這個設定中沒有唯讀節點，因為只有一個執行中的節點。
備用程序
如果資料庫節點因基礎硬體問題而無法通過健康狀態檢查，系統會在其他基礎執行個體上重新建立節點。此時，架構會還原至原始狀態，無需執行任何額外步驟。不過，如果發生區域故障，設定會繼續以效能降低的狀態執行，直到第一個區域恢復運作為止。雖然機率極低，但如果為地區永久磁碟複製和有狀態 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 |
|---|---|---|
|
提供 Hook 介面，允許在重要步驟 (例如降級或升級時) 呼叫使用者定義的動作。 功能豐富的可設定性，例如支援不同類型的 DCS、初始化副本的不同方式，以及提供 PostgreSQL 設定的不同方式。 可設定待命叢集，允許串聯副本叢集，簡化叢集之間的遷移作業。 |
由於專案相對較新，因此有此限制。 | 不適用。 |
成熟度
| Patroni | pg_auto_failover | 具備區域性永久磁碟的有狀態 MIG |
|---|---|---|
| 這個專案自 2015 年推出以來，已在 Zalando 和 GitLab 等大型企業的生產環境中採用。 | 這項專案於 2019 年初宣布，相對來說是新專案。 | 完全由正式發布的 Google Cloud 產品組成。 |
維護和監控的最佳做法
維護及監控 PostgreSQL HA 叢集，對於確保高可用性、資料完整性和最佳效能至關重要。以下各節將提供監控及維護 PostgreSQL HA 叢集的一些最佳做法。
定期執行備份和復原測試
定期備份 PostgreSQL 資料庫，並測試復原程序。 這麼做有助於確保資料完整性，並在發生中斷時盡量縮短停機時間。測試復原程序，驗證備份內容並找出潛在問題，防患於未然。
監控 PostgreSQL 伺服器和複製延遲
監控 PostgreSQL 伺服器，確認伺服器正在執行。監控主要節點和備用節點之間的複製延遲時間。延遲時間過長可能會導致資料不一致，並在容錯移轉時造成更多資料遺失。設定延遲大幅增加的警示，並立即調查根本原因。使用 pg_stat_replication 和 pg_replication_slots 等檢視畫面，有助於監控複製延遲。
實作連線集區
連線集區可協助您有效管理資料庫連線。 連線集區有助於減少建立新連線的負擔，進而提升應用程式效能和資料庫伺服器穩定性。PGBouncer 和 Pgpool-II 等工具可為 PostgreSQL 提供連線集區。
實作全方位監控
如要深入瞭解 PostgreSQL HA 叢集，請建立健全的監控系統，方法如下：
- 監控重要的 PostgreSQL 和系統指標，例如 CPU 使用率、記憶體用量、磁碟 I/O、網路活動和有效連線。
- 收集 PostgreSQL 記錄，包括伺服器記錄、WAL 記錄和自動清除記錄，以進行深入分析和疑難排解。
- 使用監控工具和資訊主頁，以視覺化方式呈現指標和記錄，快速找出問題。
- 將指標和記錄檔與警示系統整合，主動接收潛在問題的通知。
如要進一步瞭解如何監控 Compute Engine 執行個體，請參閱 Cloud Monitoring 總覽。
後續步驟
- 瞭解 Cloud SQL 高可用性設定。
- 進一步瞭解使用地區永久磁碟的高可用性選項。
- 瞭解 Patroni。
- 瞭解 pg_auto_failover。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 Cloud 架構中心。
貢獻者
作者：Alex Cârciu | 解決方案架構師