RDS CDC Bridge 方案：Aurora pgoutput 設計基準（設計版 v4）¶

文檔資訊

分類: architecture
難度: advanced
預估閱讀時間: 6 分鐘
標籤: RDS, CDC, Aurora PostgreSQL, pgoutput, Slot策略, gameserver, 多環境部署, DeployBridgePod, globalsetting, 設計實作分離

摘要¶

Gameserver 重啟流程的 RDS CDC Bridge 架構設計基準。Aurora PostgreSQL 採用 pgoutput 作為最終方案，多站點共用同一 RDS instance 但不同 DB 時採獨立 Slot 策略，Publication / Slot 初始化整合進 DeployBridgePod init container，憑證直接沿用 globalsetting。本版本（v4）明確將設計說明與實作細節分離，設計文檔聚焦於架構決策與原則。

關鍵學習¶

Aurora PostgreSQL 僅支援 pgoutput（非 wal2json），設計文檔直接以此為既定方案，不保留選型比較
Replication Slot 每次只允許一個 active consumer，多環境共用 RDS 時須為每個 DB 建立獨立 Slot
多站點共用同一 RDS instance 但不同 DB 的情境，確認採用獨立 Slot 策略（game_slot_snapshot、game_slot_uat）
CREATE PUBLICATION 與 pg_create_logical_replication_slot 可整合進 DeployBridgePod init container，實現與 Bridge Pod 同進退
REPLICATION 權限不等於 admin，只需對現有帳號執行 ALTER ROLE ... REPLICATION 即可
專案憑證統一在 globalsetting 管理，Bridge Pod 沿用即可，無需額外建立 K8s Secret
設計文檔與實作文檔需嚴格分離，設計文檔不應包含大量程式碼範例

技術細節¶

Replication Slot 核心限制¶

PostgreSQL Replication Slot 每個 Slot 同時只允許 一個 active consumer。若兩個 Bridge Pod 嘗試連接同一個 Slot，後者會被拒絕或報錯。這是多環境策略的設計根因。

多環境共用 RDS 的 Slot 設計¶

當 snapshot、uat 等多個站點環境共用同一個 RDS instance 但使用**不同的 Database** 時，為每個 DB 建立獨立的 Slot：

game_slot_snapshot  →  snapshot DB  →  Bridge Pod A
game_slot_uat       →  uat DB       →  Bridge Pod B

各 Slot 彼此隔離，各環境 Bridge Pod 各自消費對應 Slot，不存在競爭問題。

DeployBridgePod 整合初始化原則¶

CREATE PUBLICATION 與 pg_create_logical_replication_slot 整合進 DeployBridgePod 的 init container，確保：

同進退：Bridge Pod 部署時自動完成 DB 端初始化
冪等性：使用 IF NOT EXISTS 語意或先偵測再建立，多次部署不會重複建立報錯
無人工漏步驟：避免忘記建立 Slot 導致 Bridge Pod 啟動後無法連接

憑證管理原則¶

專案憑證統一在 globalsetting 管理，init container 與 Bridge Pod 直接沿用。確認 globalsetting 中的資料庫帳號已被授予 REPLICATION 屬性（透過 ALTER ROLE ... REPLICATION，不需要 admin 身份）。

What Changed¶

v3 → v4 的核心演進：設計與實作分離

v3 文檔雖然已移除 CDC Plugin 選型比較，但仍包含大量實作細節（完整 Node.js 程式碼、詳細 YAML 範例）。使用者明確指示「實作和設計分開了，為什麼還有那麼多實作細節在裡面」，v4 依此原則重構。

設計文檔聚焦於**架構決策、設計原則、策略方向**，實作細節（程式碼範例、YAML 配置）移至獨立的實作文檔。這使設計文檔更易閱讀和維護，也讓不同角色（架構師 vs 工程師）能各自查閱對應文檔。

v2 → v3 的演進（仍有效）：

移除 pgoutput vs wal2json 選型比較，直接以 pgoutput 作為 Aurora 環境的既定方案。確認多站點共用 RDS 但不同 DB 時採用獨立 Slot 策略（每個 DB 一個 Slot）。

So What¶

此文檔代表 CDC Bridge 方案在 Aurora 環境下的**最終設計基準**，設計與實作已明確分離。

設計文檔的價值在於提供架構決策的脈絡與原則，而不是可直接貼上執行的程式碼。當新工程師加入或方案需要移植到新環境時，先看設計文檔理解「為什麼這樣設計」，再看實作文檔瞭解「怎麼做」。

特別是 init container 整合設計將 DBA 初始化步驟自動化，globalsetting 憑證策略確保與現有專案配置一致，這兩個決策降低了日常運維的人工介入需求。

Trade-offs¶

多 Slot vs 單 Slot + 多目標：多 Slot 架構隔離性好、各環境獨立，但 Slot 數量隨環境增加需監控管理；單 Slot 搭配 Bridge Pod 同時重啟多環境邏輯複雜但資源較少
init container 初始化 vs 手動 DBA 操作：init container 自動化降低人工失誤，但需確保冪等性（多次部署不重複建立）；手動操作彈性高但容易漏步驟
globalsetting 憑證 vs K8s Secret：沿用 globalsetting 減少配置管理點，但需確認帳號有 REPLICATION 權限；獨立 Secret 管理清晰但增加維護點
設計/實作分離 vs 單一文檔：分離後各自清晰易維護，但需同步更新兩份文檔；單一文檔自洽但隨時間膨脹難以閱讀

Try It Fast¶

-- 確認 Aurora 環境 Slot 狀態（設計驗證用）
SELECT slot_name, plugin, active, database, restart_lsn
FROM pg_replication_slots
ORDER BY slot_name;

-- 預期結果：各環境獨立 Slot，active = false 時表示 Bridge Pod 未連接
-- game_slot_snapshot | pgoutput | false | snapshot_db | ...
-- game_slot_uat      | pgoutput | false | uat_db      | ...

Recommendation¶

Aurora 一律使用 pgoutput：直接採用，不評估 wal2json（Aurora 不支援）
多站點多 Slot 策略：共用 RDS 但不同 DB 時，每個 DB 建立獨立 Slot（如 game_slot_snapshot、game_slot_uat）
整合 init container：CREATE PUBLICATION 和 CREATE SLOT 整合進 DeployBridgePod init container，確保冪等性
沿用 globalsetting 憑證：不需額外建立 K8s Secret，確認帳號有 REPLICATION 屬性（ALTER ROLE ... REPLICATION，不需 admin）
監控 Slot WAL 堆積：建立 pg_replication_slots 告警，偵測 inactive slot 避免 WAL 無限堆積
設計與實作文檔分開維護：設計文檔記錄架構決策，實作文檔記錄程式碼與配置細節

本文檔由 Semi-Brain 自動生成

Session ID: c68e794c-bec7-485d-8225-971a172f956c

分析信心度: 95%