CloudNativePG 雙中心高可用性架構與無資料遺失同步機制

CloudNativePG 透過主備架構實現企業級 PostgreSQL 高可用性部署，雖然不支援真正的雙活架構，但提供快速故障轉移的主備模式，可達成 RPO ≤ 5 分鐘的災難復原能力。作為 Kubernetes 原生的 PostgreSQL 運算子，CloudNativePG 利用 PostgreSQL 內建的同步複寫機制，實現無資料遺失的資料同步，同時提供自動化的生命週期管理和故障恢復能力。

CloudNativePG 核心架構與基本概念

CloudNativePG 是專為 Kubernetes 環境設計的 PostgreSQL 運算子，採用完全雲原生的設計理念。該系統使用主備（primary/standby）架構，結合 PostgreSQL 原生的串流複寫技術，而非依賴外部工具如 Patroni 或 repmgr。核心組件包括 CloudNativePG 控制器管理器、實例管理器（Instance Manager）和多個自定義資源定義（CRDs）。

控制器管理器部署在 cnpg-system 命名空間中，負責整體集群的生命週期管理。實例管理器作為每個 PostgreSQL Pod 的 PID 1 執行程序，直接管理 PostgreSQL 程序的啟動、監控和故障恢復。系統透過 Cluster、Backup、ScheduledBackup、Pooler 等 CRDs 提供聲明式配置介面。

在服務管理方面，CloudNativePG 自動建立三種類型的 Kubernetes 服務：-rw 指向主實例（讀寫）、-ro 指向備份實例（唯讀）、-r 指向任何可用實例。這種設計確保應用程式可以透過一致的服務端點存取資料庫，無需關心底層拓樸變化。與傳統部署相比，CloudNativePG 提供不可變基礎設施、自癒能力、原生安全性和自動服務管理等獨特優勢。

雙中心部署模式分析

PostgreSQL 本質上不支援真正的 Active-Active（多主）配置，因為寫入衝突、腦裂情況和一致性問題使得真正的雙活架構極其複雜。CloudNativePG 實現的是具有極快故障轉移能力的 Active-Passive 架構，透過跨資料中心的副本集群提供災難復原能力。

分散式拓樸架構

CloudNativePG 支援兩種主要的多集群部署模式。**分散式拓樸（推薦用於災難復原）**在一個資料中心部署主集群，在另一個資料中心部署副本集群，形成對稱架構，支援受控的升級/降級操作而無需重新克隆。獨立副本集群主要用於報告和 OLAP 工作負載，但升級時需要完全重新克隆。

部署場景涵蓋私有雲（跨資料中心的多個 Kubernetes 集群）、公有雲（不同區域的多個集群）、混合雲和多雲部署。網路連線需求包括直接串流複寫（需要低延遲網路）和透過物件儲存的 WAL 運送（對網路中斷更有彈性）。

故障轉移與自癒機制

單集群內提供自動故障轉移，透過就緒探針自動偵測主實例故障，在可用副本間進行 leader 選舉，並自動更新服務端點。跨集群故障轉移需要手動干預，透過受控切換流程實現：首先將當前主集群降級為副本，然後將指定副本集群升級為主。

故障回復程序包括自動重新整合恢復的主實例作為備份，使用 pg_rewind 重新同步前主實例，以及利用卷快照實現大型資料庫的快速恢復。防止腦裂的機制包括單主實例強制執行、自動服務重定向和複寫插槽管理。

PostgreSQL 同步複寫機制實現

CloudNativePG 建立在 PostgreSQL 成熟的 WAL（Write-Ahead Logging）串流架構之上，實現企業級資料庫可靠性。PostgreSQL 的物理串流複寫透過網路連線將 WAL 串流從主實例發送到副本，支援熱備份（允許副本上的唯讀查詢）和級聯複寫。

同步 vs 非同步複寫

非同步複寫（預設）中，主實例不等待副本確認，提供更高的效能和較低的延遲，但存在資料遺失風險。同步複寫中主實例等待副本確認後才提交交易，透過 synchronous_commit 參數提供可配置的耐久性級別，保證零資料遺失。

PostgreSQL 提供五個耐久性級別：off（無等待 WAL 刷新）、local（等待本地 WAL 刷新）、remote_write（等待副本作業系統級寫入確認）、on（等待副本 fsync 到永久儲存）和 remote_apply（等待 WAL 重播和副本上的可見性）。其中 on 是預設設定，提供主實例和副本當機的倖存保證。

CloudNativePG 的複寫實現

CloudNativePG 自動建立專用複寫使用者並實現基於 TLS 憑證的加密複寫連線。系統結合多種複寫方法：主要使用串流複寫進行即時同步，備用檔案式 WAL 運送透過物件儲存，並在啟用連續備份時自動配置 restore_command。

**現代同步配置（v1.24+）**透過 .spec.postgresql.synchronous 段落提供增強控制，支援仲裁式（method: "any"）和優先順序式（method: "first"）同步複寫。資料耐久性模式包括 strict（寫入操作在同步備份不足時阻塞）和 preferred（在副本不可用時繼續操作但降低同步保證）。

無資料遺失同步配置實現

實現零資料遺失需要正確配置同步複寫參數。推薦配置包括最少 3 個實例，使用仲裁式同步複寫，設定至少 1 個同步副本，並採用嚴格資料耐久性模式：

spec:
  instances: 3
  postgresql:
    synchronous:
      method: "any"
      number: 1
      names: ["*"]
      dataDurability: "strict"
    parameters:
      synchronous_commit: "on"

CloudNativePG 動態管理 PostgreSQL 的 synchronous_standby_names 參數，自動排除不健康的副本，並提供自癒功能。複寫插槽管理確保 WAL 段不會在副本確認接收前被回收，防止副本重新初始化。

效能最佳化配置

同步複寫的效能影響因素包括網路延遲、副本效能、磁碟 I/O 和負載平衡。建議配置包括多可用區部署、專用複寫網路、硬體容量規劃和主動複寫插槽監控。WAL 相關參數調整包括設定適當的 wal_keep_size、調整檢查點參數和最佳化連線設定。

關鍵監控指標包括 pg_stat_replication.sync_state（監控同步副本狀態）、複寫延遲指標和複寫插槽延遲監控。透過這些指標可以確保同步複寫正常運作並及時發現潛在問題。

高可用性與災難復原機制

CloudNativePG 的高可用性策略結合多個層面的保護機制。Pod 反親和性規則確保實例分散在不同節點和可用區，PodDisruptionBudgets 確保維護期間的集群可用性。自動故障轉移透過活性和就緒探針監控實例健康狀態，並在故障時自動升級最健康的副本。

備份與恢復策略

連續備份透過 Barman 物件儲存整合，支援增量備份、並行 WAL 運送和加密。排程備份提供定期完整備份，可配置保留策略和備份選項。點時間恢復（PITR）支援恢復到特定時間點、交易 ID 或 LSN，為精確的資料恢復提供靈活性。

卷快照備份為大型資料庫提供快速備份和恢復能力，特別適合 TB 級資料庫的快速恢復需求。CloudNativePG 支援線上和離線快照，可與 Kubernetes VolumeSnapshot API 整合。

監控與可觀測性

內建 Prometheus 匯出器在埠 9187 提供自訂 SQL 指標支援，預設監控查詢包含在 ConfigMap 中。JSON 格式的日誌輸出到 stdout 用於日誌聚合，自動建立 PodMonitor 以整合 Prometheus Operator。跨集群可觀測性需要聯邦 Prometheus 設定，監控複寫延遲、WAL 運送指標和憑證過期。

實際配置範例與最佳實踐

生產環境多可用區配置

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: postgres-production
spec:
  instances: 3
  postgresql:
    synchronous:
      method: "any"
      number: 1
      dataDurability: "preferred"
    parameters:
      shared_buffers: "512MB"
      effective_cache_size: "2GB"
      synchronous_commit: "on"
  affinity:
    enablePodAntiAffinity: true
    topologyKey: topology.kubernetes.io/zone
  backup:
    barmanObjectStore:
      destinationPath: "s3://backups/postgres"

跨區域副本集群配置

跨區域災難復原透過副本集群實現，結合 WAL 運送和串流複寫。配置包括外部集群參考、TLS 憑證管理和物件儲存整合：

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: postgres-replica-dr
spec:
  instances: 2
  replica:
    enabled: true
    source: primary-cluster
  externalClusters:
    - name: primary-cluster
      barmanObjectStore:
        destinationPath: "s3://backups/primary"

安全性最佳實踐

TLS 加密預設啟用，支援憑證式身份驗證和 90 天自動憑證輪換。網路安全透過 NetworkPolicy 實現細粒度存取控制，RBAC 整合提供適當的權限管理。秘密管理包括自動化憑證和認證處理。

營運最佳實踐

營運程序包括使用 kubectl cnpg 外掛程式進行集群管理、實施全面的監控和警報策略、維護緊急程序手冊。效能調整關注資源大小規劃（shared_buffers 佔記憶體 25%），儲存類別選擇（使用 SSD 儲存），以及適當的連線池配置。

容量規劃建議小型工作負載使用 1 CPU 核心和 1GB RAM，中型工作負載使用 2-4 CPU 核心和 2-4GB RAM，大型工作負載使用 4-8 CPU 核心和 8-16GB RAM。儲存建議使用基於 SSD 的儲存類別，為 WAL 檔案配置獨立的高效能儲存。

結論與建議

CloudNativePG 透過主備架構提供了穩健的雙中心 PostgreSQL 部署基礎，雖然不支援真正的 Active-Active 配置，但提供具有快速故障轉移能力的精密 Active-Passive 部署。透過同步複寫實現 RPO=0，透過卷快照實現接近零的 RTO，為關鍵任務應用提供企業級資料庫可靠性。

成功實施零資料遺失場景的關鍵在於理解 synchronous_commit 級別、複寫拓樸、故障情況和效能權衡之間的相互作用。CloudNativePG 的自動 synchronous_standby_names 管理，結合其智慧自癒能力，為需要最大資料耐久性的關鍵 PostgreSQL 部署提供了引人注目的解決方案。

組織在實施零資料遺失的 CloudNativePG 場景時，應專注於適當的網路架構、全面監控和徹底的故障情況測試，以確保實施滿足其特定的 RPO 和 RTO 需求。建議採用聲明式配置、自動化營運流程，並維護詳細的故障復原程序文件。

philipz/CloudNativePG_AA.md