philipz · June 26, 2025 05:25 · Jun 26, 2025
diff --git a/CloudNativePG_AA.md b/CloudNativePG_AA.md
@@ -0,0 +1,148 @@
+# 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 個同步副本，並採用嚴格資料耐久性模式**：
+
+```yaml
+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 運送指標和憑證過期。
+
+## 實際配置範例與最佳實踐
+
+### 生產環境多可用區配置
+
+```yaml
+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 憑證管理和物件儲存整合：
+
+```yaml
+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 需求。建議採用聲明式配置、自動化營運流程，並維護詳細的故障復原程序文件。