本文是 PostgreSQL overview 的 implementation-layer deep article。Overview 已說明 PostgreSQL 在 OLTP 譜系的定位、本文聚焦 Patroni-based HA 的 lifecycle 設計 — 從正常運作到 failover 完成的 5 段、每段配置 + failure mode + recovery。

Failover lifecycle：5 段不是一條曲線

PostgreSQL 原生沒有 auto-failover；primary 掛了、application 卡死、SRE 手動 promote standby — 整個過程通常 5-30 分鐘。Patroni 把這條鏈拆成 自動化的 5 段 lifecycle、每段有自己的 trigger、配置、失敗模式：

每段都有獨立配置、不是「設一個 timeout 就好」。後面分段展開。

Stage 1：Detection — DCS heartbeat 跟 TTL

 1# patroni.yml 核心配置
 2scope: myapp-pg-cluster
 3namespace: /db/
 4name: pg-node-1                                # 跟 hostname 一致
 5
 6etcd:
 7  hosts: etcd1:2379,etcd2:2379,etcd3:2379       # DCS quorum
 8  protocol: https
 9
10bootstrap:
11  dcs:
12    ttl: 30                                     # leader lock TTL
13    loop_wait: 10                               # patroni 主循環間隔
14    retry_timeout: 10                           # DCS retry 上限
15    maximum_lag_on_failover: 1048576            # standby 落後 1MB 內才能 promote
16    synchronous_mode: false                     # async / sync 取捨

關鍵直覺：

• TTL (30s) = leader 失聯多久才被視為 dead。設太短（< 15s）會把 transient network jitter 當 dead；設太長（> 60s）unavailability 拖長
• loop_wait + retry_timeout < TTL：Patroni 必須在 TTL 內成功跟 DCS 互動 N 次、loop_wait=10 + retry_timeout=10 給每個循環 20s buffer
• maximum_lag_on_failover：standby WAL 落後超過這個閾值就 不參與 election；防止「promote 一個落後 5 分鐘的 standby」資料丟失

Stage 2：Election — DCS quorum + watchdog 防 split-brain

1watchdog:
2  mode: required                                # required / automatic / off
3  device: /dev/watchdog
4  safety_margin: 5

Election 期間最大風險是 split-brain — network partition 下、舊 leader 還活著但跟 DCS 斷線；新 leader 從 standby 升上來、application 同時連兩個 PostgreSQL 寫。資料 divergence 後 無法自動 reconcile。

防護機制兩層：

1. DCS quorum：etcd / Consul 至少 3 node、過半 quorum 才能寫 leader key — 少數派 partition 無法 elect 新 leader
2. Watchdog (Linux kernel)：required mode 強制 — Patroni 必須定期 poke /dev/watchdog、若 Patroni 自己掛或被 OS 凍結、kernel 自動 reboot 整台機器、避免舊 leader 在 DCS 失聯後繼續接寫

Watchdog required 是 production-grade 的硬要求 — automatic / off 在 split-brain 場景下無法防護。

Stage 3：Promotion — pg_ctl + replication slot 切換

新 leader 寫 DCS key 成功後、Patroni 自動執行：

1# Patroni 內部、不要手動跑
2pg_ctl promote -D /var/lib/postgresql/data
3# postgresql.auto.conf 移除 primary_conninfo
4# postgresql.auto.conf 重新計算 timeline ID
5# 啟動接寫

Promotion 期間關鍵議題：

• timeline divergence：新 leader 開新 timeline ID（從 leader 失聯時的 LSN 開始）；其他 standby 需要 pg_rewind 把自己的 WAL fork 點對齊新 timeline
• replication slot 處理：舊 leader 上的 replication slot 在 DCS 中已 stale、新 leader 重建 slot；如果 logical replication consumer 沒 idempotent、會 replay 部分訊息
• promotion latency：通常 3-10 秒（pg_ctl 本身 < 5s、加 DCS 寫確認）

Stage 4：Reconfiguration — client routing 切換

PostgreSQL 自己升 leader 還不夠、application 不知道；要靠前端 routing 層轉發。三種典型 pattern：

1[client] → [HAProxy / pgBouncer] → [pg-node-1 (leader)]
2                                 → [pg-node-2 (standby, read)]
3                                 → [pg-node-3 (standby, read)]

Patroni REST API 暴露 /leader / /replica / /health endpoint、HAProxy 用 health check 跑這些 endpoint：

1# haproxy.cfg
2backend pg-write
3  option httpchk OPTIONS /leader
4  http-check expect status 200
5  server pg-node-1 pg-node-1:5432 check port 8008
6  server pg-node-2 pg-node-2:5432 check port 8008 backup
7  server pg-node-3 pg-node-3:5432 check port 8008 backup

Reconfiguration 期間關鍵延遲：

• HAProxy health check 間隔（預設 2s）+ failure threshold（預設 3 次）= ~6s 切換感應
• PgBouncer 不主動 health check、要靠 application 端 retry 跟 connection drop 觸發重連
• 整個 reconfiguration 端到端通常 10-20s（含 PostgreSQL promotion 時間）

Stage 5：Recovery — pg_rewind 跟 base backup 取捨

舊 leader 恢復後變 standby，但 WAL 已 divergence — 必須選一條 recovery path：

• pg_rewind：rewind 舊 leader WAL 到分歧點、重新接 streaming replication；條件 = 分歧 WAL 量小（< 幾 GB）且 timeline 可對齊
• 重 base backup：用 pg_basebackup 從新 leader 拉完整 base + WAL；條件 = 任何時候都可、但時間長（TB 級 1-4 小時）

Patroni 預設嘗試 pg_rewind、失敗才退 base backup。production 配置：

1postgresql:
2  use_pg_rewind: true
3  remove_data_directory_on_rewind_failure: true   # rewind 失敗自動清 data dir、再 base backup
4  remove_data_directory_on_diverged_timelines: true

Production 故障演練

Case 1：Split-brain due to DCS partition

徵兆：兩個 PostgreSQL node 都在接寫、application 大量寫入 conflict / unique constraint violation。

根因：DCS（etcd）partition — 兩個 etcd node 在 partition 兩側、都自認 quorum；其實是 split-vote、兩邊都不應該。Patroni 在兩邊各 elect 一個 leader。

修法：

1. DCS 必須奇數 node（3 / 5 / 7）、過半 quorum 嚴格 enforce
2. DCS 部署跨 AZ / region 時、quorum size 要考慮 partition 機率（3 AZ 各 1 node 是 production 最低標）
3. Watchdog required mode 是最後一道閘門 — DCS partition 加 quorum 失靈時、watchdog 強制 reboot 失聯 node

Case 2：Standby 落後太多、無法 failover

徵兆：primary 失聯後、Patroni log 顯示 Following members have lag greater than maximum_lag_on_failover、所有 standby 都被拒 promote、cluster unavailable。

根因：maximum_lag_on_failover 設 1MB、但 standby replication lag 累積到 50MB（write-heavy workload + slow disk on standby）。安全機制觸發、但代價是 無 standby 可升、需要人工降低門檻或等 standby catch up。

修法：

1. 預防：standby 容量 / IO 對齊 primary、避免 lag 累積；prometheus alert pg_replication_lag_bytes > 10MB 觸發前 catch
2. 臨時：手動 patronictl edit-config 把 maximum_lag_on_failover 暫時拉到 50MB、接受可能丟 50MB worth of writes、換 availability
3. 長期：sync replication（一個 standby 強制同步）、保證至少一個 standby zero-lag

Case 3：Promotion 後 application connection storm

徵兆：failover 完成後 30-120 秒內、application log 大量 connection refused / password authentication failed、application 自己 retry storm。

根因：新 leader 剛 promote、PostgreSQL max_connections 容量還在 warm up（shared memory / cache 未 prime）、application 同時湧入大量 connection request；應用 retry 不夠 jitter、queue 堆積。

修法：

1. Application 用 exponential backoff with jitter、不要 immediate retry
2. PgBouncer / connection pool 限制每 application instance 對 PG 的 connection 上限、不直連 PG
3. 預先在 standby 跑 pg_prewarm 把熱表 cache 預熱、promotion 後 cache miss 不爆

Case 4：pg_rewind 失敗、退到 base backup 沒做

徵兆：舊 leader 恢復後、Patroni log 顯示 pg_rewind failed、舊 leader 一直 STARTING、無法重接 cluster；SRE 手動跑 pg_basebackup 才恢復。

根因：remove_data_directory_on_rewind_failure: false（預設）— rewind 失敗時 Patroni 不主動清 data dir、需要 SRE 手動處理；運維沒 runbook、卡在這步幾小時。

修法：

1. Production 設 remove_data_directory_on_rewind_failure: true + remove_data_directory_on_diverged_timelines: true、讓 Patroni 自動 fallback
2. data dir 跑在獨立 PV / disk、清掉風險可控（不要跑 root disk）
3. 容量規劃：base backup 時間預估納入 RTO（TB 級 base backup 1-4 小時、不是 RTO 30 分鐘所能承受）

Case 5：Watchdog 觸發整機 reboot、誤殺

徵兆：production server 在無故障時 unexpected reboot、dmesg 顯示 watchdog: BUG: soft lockup。

根因：Patroni 主循環因 etcd 短暫慢回應卡住 60+ 秒、kernel watchdog 觸發 reboot；但實際 PostgreSQL 沒 hang、是 Patroni-watchdog 鏈過敏。

修法：

1. safety_margin 設大一點（10-15）、給 Patroni loop_wait 抖動空間
2. etcd 跟 Patroni 部署在低延遲 network 內（同 AZ < 5ms）、跨 region etcd 不建議
3. watchdog device 用 softdog（軟體模擬）vs 硬體 watchdog、debug 時 softdog 容易觀察

容量規劃

整合 / 下一步

跟 PgBouncer 整合

PgBouncer 不主動感知 Patroni failover、要靠：

1. HAProxy 在 PgBouncer 上層：HAProxy 跑 Patroni health check、PgBouncer connection 重新路由
2. PgBouncer reload：failover 後 SRE / automation 跑 pgbouncer -R、強制重連 backend
3. Connection pool drain：application 端 connection pool 設 pool_lifetime_max=5min、舊 connection 自然汰換

跟 cert-manager（TLS rotation）

Patroni REST API 跟 PostgreSQL streaming replication 都用 TLS、cert rotation 不能停服務：

1. cert-manager 自動換證後、Patroni 跟 PostgreSQL 都需要 reload（不是 restart）
2. patronictl reload <cluster> 不會觸發 failover、只 reload config
3. PostgreSQL pg_ctl reload 是 SIGHUP、平滑載入新 cert

跟 backup / PITR

Patroni 不管 backup — 但 standby promotion 後、WAL archive 必須跟新 leader 的 timeline 對齊：

1. WAL archive 命令模板含 %t（timeline）：archive_command = 'wal-g wal-push %p'
2. Backup tool（pgBackRest / WAL-G）支援 timeline 切換、archive 不會中斷
3. 詳見 PITR + WAL archiving deep article

下一步議題

• Multi-region Patroni：跨 region 部署的 DCS quorum 設計、跟單 region 的取捨完全不同
• PostgreSQL 16+ streaming replication slot 持久化：簡化 standby promotion 後 logical consumer 重連
• 跟 Kubernetes operator 整合：Patroni 跑在 K8s 時、StatefulSet + pod identity + DCS 部署模式

相關連結

• 上游 vendor 頁：PostgreSQL
• 上游 chapter：High Concurrency Access — connection / replication / HA 全鏈
• 平行 deep article：pgBouncer 配置 / Vault Dynamic Credential
• Methodology：Vendor 深度技術文章的寫作方法論

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 Orchestrator failover — 自動 HA 的工具雙層架構跟 5 段 decision tree。

用詞註：Orchestrator 工具命名與 MySQL 5.7- SQL 命令（SHOW SLAVE STATUS / CHANGE MASTER TO / STOP SLAVE 等）沿用 master / slave。MySQL 8.0+ 改採 primary / replica、但 SQL syntax 仍保留別名。本文出現 master / slave 處對應 8.0 primary / replica 概念。

讀者第一個會問的問題：「Orchestrator 自己會壞嗎？壞了誰 failover Orchestrator？」這個 paradox 是 任何 HA 工具 的核心議題、PostgreSQL 的 Patroni 用 DCS（etcd / Consul）解決、MySQL 的 Orchestrator 用 內建 raft cluster 解決：

1被管的 (Layer 1):       primary MySQL → replica MySQL → replica MySQL → ...
2管理者 (Layer 2):       orchestrator instance × 3 (or 5) — 用 raft 自己選 leader
3管理者狀態存放 (Layer 3): 每個 orchestrator instance 自己有 MySQL backend (state)

Orchestrator 3 個 instance 構成 raft cluster、自己選 leader。Leader 才有 寫入 state + 發起 failover 權限、其他 instance follower 同步 state。Leader 失聯 → raft 重新選 leader（< 10 秒）、新 leader 繼續 manage MySQL topology。

跟 PostgreSQL Patroni 不同：Patroni 需要 外部 DCS（etcd / Consul）作為 source of truth、Patroni 本身 stateless；Orchestrator 內建 raft、不需要外部 DCS、但每個 orchestrator instance 需要 自己的 MySQL backend 存 state。

Orchestrator 雙層架構：管 MySQL 的 Layer 2

Layer 1 是 被管的 MySQL cluster — primary + replica 群。Layer 2 是 管理者 — orchestrator instance 群。Layer 2 監視 Layer 1、Layer 2 自己用 raft 自管。

Layer 1 對 Orchestrator 的需求：

• 所有 MySQL server 啟用 binlog + log_slave_updates（讓 Orchestrator 看得到 binlog event）
• 啟用 GTID（Orchestrator failover decision 依賴 GTID 比較進度、不用算 binlog position）
• 每個 server 有 orchestrator user（GRANT SUPER, REPLICATION CLIENT, REPLICATION SLAVE, PROCESS ON *.* TO 'orchestrator'@'%'）

Layer 2 配置：

 1# /etc/orchestrator.conf.json (簡化)
 2{
 3  "MySQLOrchestratorHost": "orchestrator-backend.example.com",
 4  "MySQLOrchestratorPort": 3306,
 5  "MySQLOrchestratorDatabase": "orchestrator",
 6
 7  # 用 backend MySQL（每個 orchestrator instance 自己一個）+ raft 同步
 8  "RaftEnabled": true,
 9  "RaftDataDir": "/var/lib/orchestrator",
10  "RaftBind": "10.0.1.10:10008",
11  "RaftNodes": [
12    "orchestrator1.example.com:10008",
13    "orchestrator2.example.com:10008",
14    "orchestrator3.example.com:10008"
15  ],
16
17  # Topology discovery
18  "DiscoverByShowSlaveHosts": true,
19  "InstancePollSeconds": 5,
20
21  # Failover detection
22  "FailureDetectionPeriodBlockMinutes": 60,
23  "RecoveryPeriodBlockSeconds": 3600,
24
25  # Failover automation
26  "RecoverMasterClusterFilters": ["*"],
27  "RecoverIntermediateMasterClusterFilters": ["*"],
28  "PreFailoverProcesses": ["/usr/local/bin/orchestrator-fence-master.sh"],
29  "PostFailoverProcesses": ["/usr/local/bin/orchestrator-notify-proxysql.sh"]
30}

Stage 1：Topology Discovery — 自動發現 + manual seed

Orchestrator 啟動後 seed 一個或多個 MySQL server、自動發現整個 topology：

• 連 seed server → SHOW SLAVE HOSTS → 發現所有 replica
• 對每個 replica 跑 SHOW MASTER STATUS + SHOW SLAVE STATUS → 建立 父子關係 graph
• 持續 poll（InstancePollSeconds=5）每 5 秒更新 topology state

Topology graph 的 node：

• Master：no slave status、被多個 replica 指
• Intermediate master：有 slave status 也有下游 replica（chained replication）
• Co-master：互相 replicate（罕見、active-passive failover 場景）
• Replica：有 slave status、無下游

Topology 可視化：Orchestrator UI（web）顯示 cluster 樹狀圖、操作員可手動 drag-and-drop replica 重新 attach。

Stage 2：Failure Detection — 區分真壞跟假壞

Orchestrator 不是 單一 ping 失敗就 failover、有 holistic detection：

Detection rule：Master 自己連不上 + 至少一個 replica 也看 master IO error → 判定 DeadMaster。單一 orchestrator 連不上 master 不觸發 — 防 orchestrator network 隔離造成的 false positive failover。

Stage 3：Failover Decision Tree — 選哪個 replica promote

判定 DeadMaster 後不是 選最近的 replica、用 decision tree：

1. GTID 最新的 replica：跟舊 master 同步最完整（用 Executed_Gtid_Set 對比）
2. 同 DC / AZ 的 replica（如果有 multi-DC 配置）
3. 手動指定的 promotion candidate（promote_rule=must 或 prefer）
4. Semi-sync ack 的 replica（如果 semi-sync 啟用）

GTID 最新是基本要求。其他規則是 tie-breaker。

Errant transaction 處理：選出的 candidate replica 如果有 errant GTID（master 沒有但 replica 有的 transaction）、Orchestrator 不會 promote 這個 replica（怕 errant transaction 變成 new master state）。改選次優 candidate。

Stage 4：Promote Action — 5 步 atomic（理想情況）

選好 candidate 後執行：

1. Fence 舊 master（pre-failover hook）：把舊 master 對外停掉、防 split-brain
2. STOP SLAVE on candidate：candidate 不再從舊 master pull binlog
3. RESET SLAVE ALL on candidate：candidate 清掉 slave 配置、變成獨立 master
4. Re-attach 其他 replica：用 CHANGE MASTER TO MASTER_HOST=<candidate>, MASTER_AUTO_POSITION=1（GTID auto-position）
5. Post-failover hook：通知 ProxySQL / HAProxy / DNS 切流量

每步任一失敗、Orchestrator 可能停在中間狀態、需要 人工介入。

Stage 5：Recovery — Old master 怎麼處理

Failover 完、舊 master 可能：

• 真的死了：物理 server 故障 / region outage → 不必處理、未來修好作為新 replica re-attach
• Network blip 後復活：舊 master 自己 仍認為自己是 master、再次接受寫入會造成 split-brain

修法：

• Fencing（必須）：pre-failover hook 把舊 master 對外 firewall 掉、或 force read_only=1、防舊 master 復活後接受寫入
• Manual reset：舊 master 復活後人工 confirm 是否變成新 master 的 replica（不要自動、自動容易誤判）

Orchestrator UI 在偵測到 errant master 時會標 warning、不會自動處理。

5 個 Production 踩雷

1. Split-brain — pre-failover hook 沒 fence 舊 master

舊 master network blip 後復活、orchestrator 已 promote 新 master、application 部分 instance 連舊 master、部分連新 master、雙寫造成 data divergence。

修法：

• Pre-failover hook 必須 fence（不是可選）：
  • 物理 fencing：透過 IPMI 重啟 / 關 server
  • Network fencing：透過 firewall rule 切斷 server 對外連線
  • MySQL fencing：SET GLOBAL read_only=1 + KILL 所有 active connection
• 用 VIP / DNS 配合：fence 完才切 VIP / DNS 到新 master、避免 application 連舊 IP
• 不依賴 application 連線 string 動態變更（DNS TTL 期間仍可能連舊 IP）

2. Pre-failover hook 失敗 — Orchestrator 該停還是該繼續

Pre-failover hook 跑失敗（fence script 因為 SSH 不通、IPMI 沒回應）。Orchestrator 有兩種策略：

• PostponeReplicaRecoveryOnLagMinutes：等 hook 成功才繼續、可能永遠 stuck
• FailMasterPromotionOnLagMinutes：放棄 promotion、留 cluster degraded（無 master）

兩者都不理想。多數 production 選 PostponeReplicaRecoveryOnLagMinutes=10：等 10 分鐘 hook 成功、超時則 alert 人工介入、不繼續 auto-promote（人工 review 才是正確選擇）。

3. Anti-flapping 窗口太短 — Master 抖動 vs 真死

FailureDetectionPeriodBlockMinutes=60：偵測一次 failure 後 60 分鐘內不再 trigger failover（即使再偵測到 failure）。預設 60 分鐘對 第一次 failover 後 master 仍不穩 的場景太長 — 60 分鐘內 master 真的死了第二次、orchestrator 不 failover。預設 60 分鐘對 網路抖動 的場景太短 — 60 分鐘內可能 multiple failover、cluster 一直在 promote。

修法：

• 評估自己 cluster 的 typical recovery time：1-2 小時、設 FailureDetectionPeriodBlockMinutes=120
• 監控 failover 頻率、單週 > 2 次表示底層問題（網路 / hardware）、不是調 anti-flapping window 解決

4. GTID errant transaction — Orchestrator 拒絕 promote 但沒講原因

Candidate replica 有 errant GTID（從別處 inject 的 transaction）、Orchestrator 拒絕 promote、log 訊息 errant GTID detected、但 沒寫實際是哪個 GTID。On-call 在事故中沒辦法 debug。

修法：

• 平時 監控 errant GTID：定期跑 pt-show-grants + GTID 比對、不要等 failover 才發現
• Orchestrator 的 OrchestratorIssuesAGtidPurge 設 true：preview mode 看 errant GTID 的位置
• Errant GTID 來源通常是 人為 inject（DBA 直接寫 replica 然後 binlog 出現）、教育 DBA 不要直接連 replica 寫

5. VIP / ProxySQL 整合斷層 — 切流量延遲

Post-failover hook 跑完 script 上報「我切完了」、但實際 VIP / DNS / ProxySQL 還沒看到變化。Application 連 stale endpoint 30 秒、寫入失敗。

修法：

• Post-failover hook 不只 trigger 切換、要 wait 切換完成：
  • VIP：等 arping 確認新 IP 已 propagate
  • ProxySQL：等 mysql_servers runtime table 更新 + 確認 monitor module 看到新 primary
  • DNS：先把 TTL 降到極短（5 秒）、再切 DNS、等 TTL 過
• Orchestrator PostFailoverProcessesFailOnError=true：hook 失敗整個 failover 標記失敗、人工檢查
• ProxySQL 用 mysql_replication_hostgroups 自動偵測 read_only flag、可不依賴 hook（推薦）

容量規劃要點

3 instance raft cluster 容忍 1 instance 故障。5 instance 容忍 2 instance 故障但 quorum cost 高、99% 場景 3 個夠用。

跟其他模組整合

跟 Replication topology

Orchestrator 100% 依賴 GTID + binlog ROW format（Replication Topology）。沒 GTID 用 binlog position、failover 時 re-pointing 容易出錯、Orchestrator 強烈建議 GTID。

跟 ProxySQL

ProxySQL 用 mysql_replication_hostgroups 自動偵測 read_only flag — orchestrator 切完新 master 後、ProxySQL monitor module 自動看到新 master 的 read_only=0、自動更新 routing、application 不用改 connection string。

這個 無需 post-failover hook 通知 ProxySQL 的整合是 ProxySQL + Orchestrator 組合的最大優勢、比手動 hook 通知 VIP / DNS 可靠。

跟 Patroni（PostgreSQL 對應）

兩者角色相同、設計取捨不同。Patroni 對 DCS 高依賴、Orchestrator 對自己 backend MySQL 高依賴。

跟 RDS / Aurora MySQL

AWS RDS / Aurora 內建 multi-AZ failover、不用 Orchestrator。Aurora failover < 30 秒、RDS failover ~60-120 秒。Aurora 把 replication / failover 整套封進 storage layer、application 看到的是 reader endpoint + writer endpoint。

詳見 Aurora vendor page。

跟 Vitess

Vitess shard 內部用 VTOrc（Vitess fork of Orchestrator）— 概念跟 Orchestrator 一致、針對 Vitess topology metadata 適配。

詳見 Vitess sharding 設計 篇（待寫）。

相關連結

• MySQL vendor overview
• MySQL Replication Topology（GTID 是 Orchestrator pre-requisite）
• MySQL ProxySQL 配置（Orchestrator + ProxySQL 自動失效切換組合）
• PostgreSQL Patroni HA（PG sibling、不同 HA 機制）
• Aurora vendor page（managed MySQL、Orchestrator 不需要）
• quorum 卡片 / failover 卡片
• 官方：orchestrator GitHub / orchestrator docs

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 Group Replication + InnoDB Cluster — synchronous multi-primary 的 transaction model + 部署模型。

把「Group Replication multi-primary mode」當成「multi-primary 直接線性 scale write」是常見誤解。

Single-primary 跟 multi-primary 共用同一套 GR 機制（GCE atomic broadcast + certification + applier）— 切換 mode 是 配置變更。但 性能效果 經常跟讀者預期不同：在 single-primary cluster 上加開 group_replication_single_primary_mode=OFF、預期 3 個 instance 都可以接受 write 帶來吞吐倍增、實際上每個寫入仍要全 cluster GCE broadcast + certification、寫吞吐沒爆增 / latency 飆高 / certification 衝突回退增加。

這篇 deep article 把 GR 的 certification 流程 講清楚 — 為什麼「multi-primary」聽起來像「線性 scale」、實際是「保 strong consistency 的 multi-entry」。然後展開 InnoDB Cluster（GR + MySQL Shell + MySQL Router）作為 production deployment 工具。

Group Replication 的 transaction model

GR 用 Group Communication Engine (GCE)（Paxos 變種）達成 atomic broadcast — 任何 write transaction 必須先 broadcast 到所有 member、所有 member 確認 certification pass 才 commit。

每個 transaction 的 GR lifecycle：

11. Client → Member A: BEGIN; UPDATE ...; COMMIT;
22. Member A: 先 local execute、收集 write_set（被改的 row + PK + transaction GTID）
33. Member A: write_set + binlog event → GCE broadcast to all members
44. GCE: Paxos consensus、所有 member 收到 broadcast、按 *相同順序*
55. Each Member: certification phase — 看 write_set 跟 *尚未 apply 的 incoming transactions* 是否有 PK 衝突
66. 若無衝突 → apply 該 transaction（local + remote member 都 apply）、回 client COMMIT OK
77. 若衝突 → certification fail、Member A 對 client 回 ERR_LOCK_DEADLOCK / GR_CONFLICT、application 必須 retry

核心結論：

• Single-primary mode：只有指定 member 接受 write、其他 member 純 apply、certification 仍跑（但衝突極少、因只有一個寫入源）
• Multi-primary mode：所有 member 都接受 write、certification 衝突常見、application 必須處理 conflict retry

「multi-primary 不會線性 scale write」的原因：

• 每個 write 仍要全 cluster GCE broadcast + certification
• 寫吞吐 ceiling 受 最慢 member + 網路延遲 限制（不是「N members × M throughput」）
• 多寫入源增加 certification 衝突機率、衝突 retry 反而拖 throughput

「multi-primary 真實價值」：

• 跨 region multi-active deploy（每個 region local member 接受 local write、無 cross-region write latency）— 但需求極少、多數場景 single-primary + Aurora DSQL / Spanner 更實際
• 零停機 maintenance（任一 member 下線、其他繼續接 write、不必 failover）— 但 single-primary mode 也提供同等 HA

對 99% production case：single-primary mode 才是正確選擇。Multi-primary 是 特殊 use case 工具、不是 預設 mode。

Group Communication Engine（GCE）

GR 內建 GCE、基於 XCom protocol（Paxos 變種）。GCE 責任：

• Atomic broadcast：保證 message 到所有 member、按相同順序
• Group membership：偵測 member join / leave / fail、reconfigure consensus
• Network partition handling：minority partition 自動 fence（read-only）、majority 繼續服務

GCE 跟 Raft 對比：

GR 的設計取捨：緊耦合 MySQL（不必外部 DCS）、Paxos-like consensus（不像 Raft 那麼簡單但效率更高）。trade-off 是 對 ops 的 transparency 較低 — XCom 內部行為對 DBA 是 black box。

InnoDB Cluster：GR + MySQL Shell + MySQL Router

純 GR 是 底層 replication mechanism、要組成 production deployment 需要：

• MySQL Shell (mysqlsh)：CLI 工具、提供 dba.createCluster() / cluster.addInstance() 等 cluster 管理 API
• MySQL Router：connection routing layer、自動發現 cluster topology、寫入 routing 給 primary、讀取 routing replica
• MySQL Group Replication plugin：在每個 MySQL instance 啟用

InnoDB Cluster = GR + Shell + Router、是 Oracle 推薦的 production GR deployment 方式。

起始部署（3 member single-primary cluster）

 1# Step 1: 在每個 instance 啟 GR plugin + 配 my.cnf
 2[mysqld]
 3server_id = 1                          # 各 instance 不同
 4gtid_mode = ON
 5enforce_gtid_consistency = ON
 6log_bin = mysql-bin
 7binlog_format = ROW
 8master_info_repository = TABLE
 9relay_log_info_repository = TABLE
10transaction_write_set_extraction = XXHASH64
11plugin_load_add = 'group_replication.so'
12
13group_replication_group_name = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
14group_replication_start_on_boot = OFF
15group_replication_local_address = "node1.example.com:33061"
16group_replication_group_seeds = "node1:33061,node2:33061,node3:33061"
17group_replication_bootstrap_group = OFF
18group_replication_single_primary_mode = ON       # 99% 場景用 ON
19group_replication_enforce_update_everywhere_checks = OFF
20
21# Step 2: 用 MySQL Shell 從第一個 member bootstrap cluster
22mysqlsh --user=root --host=node1.example.com
23> dba.configureInstance('root@node1:3306')
24> var cluster = dba.createCluster('prodCluster')
25> cluster.addInstance('root@node2:3306')
26> cluster.addInstance('root@node3:3306')
27> cluster.status()  # 應該顯示 3 member、1 PRIMARY + 2 SECONDARY
28
29# Step 3: 部署 MySQL Router
30mysqlrouter --bootstrap root@node1:3306 --directory /etc/mysql-router --user=mysqlrouter
31systemctl start mysql-router
32
33# 完成 — application 連 mysql-router:6446 (R/W) 或 :6447 (R/O)

Application 連 Router、Router 自動發現 cluster topology + 自動 failover routing。Application 不必知道哪個 instance 是 primary。

5 個 Production 踩雷

1. Certification lag — Multi-primary 模式 retry storm

Multi-primary mode 下、3 個 instance 同時收到 相同 row 的 conflicting write、certification 階段必有 N-1 個 transaction 被退回。Application 看到 ER_GR_CONFLICT_TRANSACTION_ABORTED、retry、若不智能 retry（exponential backoff）會 retry storm、整個 cluster 寫吞吐暴降。

修法：

• 99% 場景用 single-primary mode、避開 conflict
• 真的需要 multi-primary：application 必須 sharding-aware（不同 entry 寫不同 row range）、本質上跟 Vitess sharding 同概念但用 GR 機制
• Application retry 用 jitter exponential backoff、不直接 retry

2. Certification queue 爆炸 — Single-primary mode 仍受 cert backlog 影響

Single-primary mode 下 primary 接受 write、broadcast 到 secondary。Secondary 跟 primary network latency / 處理速度差時、cert queue 累積。Cert queue 滿 → primary write 也被卡（GR 設計：所有 member 同步前不接受新 write、保 consistency）。

修法：

• 監控 group_replication_member_stats view：COUNT_TRANSACTIONS_IN_QUEUE 持續 > 0 是警訊
• 提高 group_replication_message_cache_size（預設 1 GB）給 large transaction 緩衝
• 確認 所有 member 同 instance class、不要混 spec
• 跨 region GR：完全不推薦（network latency 殺 cert throughput）

3. Large transaction — 全 cluster 卡住

GR 必須把整個 transaction（含所有 write_set）一次 broadcast。10 GB transaction（大批量 UPDATE）必須一次塞滿 GCE buffer、cluster 內所有 member 都暫停接受新 transaction 直到 broadcast / apply 完成。常見場景：批次 archive / 大 backfill / INSERT ... SELECT 1 億 row。

修法：

• group_replication_transaction_size_limit（預設 150 MB）超過直接 reject、不要設 unlimited
• 大批量寫入拆 chunk（每 chunk < 100 MB）、用 application 層 loop
• 對 archive / backfill 用 INSERT INTO archive SELECT ... LIMIT 10000 chunked、不是一個 transaction

4. Network partition — Minority partition 自動 read-only

3 member cluster、network partition 把 1 個 member 隔離。被隔離 member 是 minority、自動進入 read-only mode（不接受 write）、防 split-brain。Application 連到 minority member 寫入會失敗。

修法：

• MySQL Router 自動發現 cluster topology、自動 route write 到 majority partition primary
• Application 必須處理 connection error + retry（甚至 connection string 改成 Router endpoint 而非個別 instance）
• 監控 group_replication_primary_member UDF、確認哪個是真 primary

5. Member 加入 catch-up — 大量 binlog 阻擋 cluster service

新 member 加入 cluster（new instance / 復原 failed member）必須 catch-up — apply 從 GR cluster start 到當前所有 binlog 才能 join consensus。如果 cluster 已運作 1 個月、binlog 累積 100 GB、catch-up 可能 6-12 小時、catch-up 期間 該 member 不投票、其他 member 仍 service、但 majority 安全邊界縮小（3 → 2 member working）。

修法：

• 用 MySQL Shell clone plugin 直接 physical-snapshot 一個 existing member、跳過 binlog replay：

  1> cluster.addInstance('root@node4:3306', {recoveryMethod: 'clone'})

• Clone 期間原 member 暫不接 write traffic（用 Router temporarily 排除）

• 規劃 maintenance window 加 member、不要在 peak load 期間

何時用 GR / InnoDB Cluster

跟其他模組整合

跟 Replication topology

GR 取代傳統 async / semi-sync replication、不是 加在上面。啟用 GR 後不要再配 master-slave style replication。詳見 Replication Topology。

跟 Orchestrator

Orchestrator 跟 InnoDB Cluster 不該 同時用 — 兩者都會 trigger failover、會打架。GR / InnoDB Cluster 內建 failover、不需要 Orchestrator。詳見 Orchestrator Failover。

跟 ProxySQL / MySQL Router

ProxySQL 可以連 GR cluster（自動偵測 read_only flag）、但 MySQL Router 是 GR 原生的 routing layer、跟 InnoDB Cluster 緊耦合（透過 MySQL Shell metadata）。

選擇邏輯：

• 純 MySQL stack, 想 Oracle-supported 整套 → MySQL Router
• 已用 ProxySQL（包含其他非 GR cluster）+ 統一 routing → 仍用 ProxySQL

詳見 ProxySQL 配置。

跟 InnoDB Tuning

GR 對 innodb_flush_log_at_trx_commit / sync_binlog 行為更敏感 — GR 要求 binlog 必須 fsync to disk（sync_binlog=1）保 zero-loss、不能用 sync_binlog=0 換速度。詳見 InnoDB Tuning。

跟 PostgreSQL Patroni 對比

兩者角色相同、設計取捨不同。詳見 PostgreSQL Patroni HA。

容量規劃要點

Member 跨 region：不推薦。GR 對 latency 敏感、跨 region 50-200ms RTT 嚴重影響 cert throughput。multi-region 需求用 Aurora Global Database / Spanner 等專為跨 region 設計的方案。

相關連結

• MySQL vendor overview
• MySQL Replication Topology（GR 取代傳統 replication）
• MySQL Orchestrator Failover（GR / InnoDB Cluster 不必 Orchestrator）
• MySQL ProxySQL 配置（routing layer 對比）
• MySQL InnoDB Tuning（GR durability 需求）
• PostgreSQL BDR / Multi-Master（PG sibling、active-active 寫入 3 種路徑跟 conflict 治理）
• PostgreSQL Patroni HA（PG sibling、不同 consensus）
• quorum 卡片 / Paxos / Raft 對比
• 官方：MySQL Group Replication / InnoDB Cluster

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 failover 流程的實作層教學。前置閱讀建議 Aurora storage architecture（理解為什麼 Aurora failover 不需要 data catch-up）。

問題情境

典型觸發場景：DraftKings / Standard Chartered 等級的金融交易服務、AZ-level outage 期間用戶操作不能斷、RTO 預算 < 60 秒、但 application 端看到的 reconnect 行為跟 AWS 文件不一致。

讀者常見的具體疑問：

• 「Failover trigger 後新 connection 還連到舊 primary、為什麼？」
• 「Writer endpoint DNS 切換了、application 還沒重連、什麼時候會切？」
• 「Failover 期間 in-flight transaction 是全 abort 還是部分 commit？」
• 「我手動測 failover RTO 量出 90 秒、AWS 文件講 < 30 秒、誰錯？」

進一步問題：失敗模式分布在 application 端的 connection state、不只是 Aurora 端的 promotion 流程。Aurora 端的 promotion 在 storage 共享下確實 < 30 秒（不需要等 data catch-up）、但 application reconnect 受 JVM DNS cache、connection pool validation、retry policy 影響、容易把總體 RTO 拉長到 2-3 倍。

對 Standard Chartered 這種受監管銀行業務、failover 還有合規維度：受監管市場資料 不能跨境複製、Global Database 在這種場景違反合規、必須用每市場獨立 cluster 的 cross-AZ failover 吸收 RTO 預算。這個 driver 跟一般工程「跨 region failover 更好」的直覺相反。

核心機制：failover lifecycle 三段

Aurora cross-AZ failover 的 first-class concept 是 failover lifecycle 三段：detection → promotion → DNS update。每一段有自己的 SLA 跟可調維度。

Detection（10-15 秒）：

• AWS 內部 health check 每幾秒檢查 primary writer health
• 連續失敗到一定閾值才 trigger failover（避免 false positive）
• 讀者無法直接調 detection 閾值、是 AWS managed

Promotion（< 5 秒）：

• 選 PromotionTier 最低的 read replica 升 primary
• Storage 跨 AZ 共享、replica 升 primary 不需要 data catch-up（vs 傳統 PostgreSQL streaming replication 要等 WAL apply）
• Promotion 本身極快、是 Aurora storage 設計的直接受益

DNS update（5-15 秒）：

• Cluster endpoint / writer endpoint DNS 切到新 primary
• Aurora endpoint DNS TTL 是 5 秒、AWS DNS infrastructure 通常 5-15 秒 propagate 完
• 但 application 端的 DNS cache 可能 cache 更久 — JVM networkaddress.cache.ttl 預設 -1（cache forever）就會卡在這層

Endpoint 類型跟 failover 行為：

• Writer endpoint：跟著 failover 走、DNS 切到新 primary、application 寫操作用這個
• Reader endpoint：load-balance 到所有 replica；failover 期間短暫包含 promoted replica（已升 primary）、reader query 可能打到 primary、引起寫鎖競爭
• Custom endpoint：用戶自定 routing rule、failover 期間行為要驗證、不能假設自動跟隨

跟通用 failover 差在哪：Aurora 不需要 data catch-up phase、failover 主要瓶頸是 DNS propagation + application reconnect、不是 promotion 本身。傳統 PostgreSQL streaming replication failover 要等 replica WAL catch-up（heavy write 期間可能秒級延遲）、Aurora 在 storage 設計下消除這段等待。

對應 knowledge card：failover、rto、rpo。

Step-by-step 配置 / 量測

Cluster failover 配置：

 1# 確認 cluster 至少有一個跨 AZ replica
 2aws rds describe-db-clusters \
 3  --db-cluster-identifier my-cluster \
 4  --query 'DBClusters[0].DBClusterMembers'
 5
 6# 設定 PromotionTier（0 最優先、15 最不優先）
 7aws rds modify-db-instance \
 8  --db-instance-identifier my-replica-az-b \
 9  --promotion-tier 0
10
11# 跨 region replica 預設 tier 15（不優先升、避免 failover 跨 region）
12aws rds modify-db-instance \
13  --db-instance-identifier my-cross-region-replica \
14  --promotion-tier 15

Application 端 JVM 設定（最常踩雷的點）：

1# JVM 系統 property、預設 -1 = cache forever、必改
2networkaddress.cache.ttl=5
3networkaddress.cache.negative.ttl=0

Connection pool 設定（HikariCP 範例）：

1spring.datasource.hikari:
2  maximum-pool-size: 30
3  connection-test-query: "SELECT 1"
4  validation-timeout: 5000
5  max-lifetime: 1800000      # 30 分鐘、強制 recycle connection
6  keepalive-time: 30000      # 30 秒檢查 idle connection
7  connection-timeout: 30000

Retry policy：

1// 簡化範例、實際用 Resilience4j 或 Failsafe
2RetryPolicy<Object> retryPolicy = RetryPolicy.builder()
3    .handle(SQLTransientConnectionException.class, SQLNonTransientConnectionException.class)
4    .withBackoff(Duration.ofSeconds(1), Duration.ofSeconds(30))
5    .withMaxAttempts(5)
6    .build();

手動觸發 failover 量測 RTO：

1# 觸發 failover、記錄時間
2START=$(date +%s%3N)
3aws rds failover-db-cluster --db-cluster-identifier my-cluster
4echo "Failover triggered at $START ms"
5
6# 用 application heartbeat 寫入時間戳
7# application 端跑 every-second insert、failover 後第一個成功 insert 的時間 - START = RTO

驗證點：

• CloudWatch FailoverEvent counter > 0（failover 觸發訊號）
• DatabaseConnections 在 failover 期間 drop > 50%、之後 spike（reconnect 風暴）
• Application metric「first successful write after failover trigger」< 30 秒

Rollback boundary：promotion 不可逆 — 原 primary 變 replica、不會自動 fallback。要切回原 AZ 必須再做一次 failover。

故障模式 / 邊界 case

Case 1：DNS cache 把 RTO 從 30 秒拉到 120 秒

徵兆：手動 failover 後、CloudWatch FailoverEvent 1 秒內出現、但 application log 顯示寫操作 120 秒後才恢復。

原因：JVM networkaddress.cache.ttl 預設 -1（cache forever）、application JVM 把 writer endpoint DNS 永久 cache 到舊 primary IP；只有 connection pool eviction 或 application restart 才會重新 resolve。

修：

• JVM startup 加 -Dnetworkaddress.cache.ttl=5
• 或在 $JAVA_HOME/lib/security/java.security 改 networkaddress.cache.ttl=5
• Python application 通常沒這問題（DNS resolve per connection）、但要確認 SQLAlchemy 用 pool_pre_ping=True

Case 2：Connection pool cached connection 全 stale

徵兆：DNS 切換 OK、但 application 寫操作 timeout 10-30 秒後才觸發 reconnect、p99 latency spike。

原因：connection pool 的 cached connection 還指向舊 primary IP、validation 沒開或 timeout 太長、application 拿到 stale connection 才發現 backend gone。

修：

• HikariCP：connection-test-query: "SELECT 1" + validation-timeout: 5000 + keepalive-time: 30000
• SQLAlchemy：pool_pre_ping=True + pool_recycle=1800
• failover 演練後驗證 connection pool 在 30 秒內 evict 完所有 stale connection

Case 3：Reader endpoint failover 期間打到新 primary

徵兆：failover 期間 application read query 偶發出現 cannot execute SELECT in a read-only transaction 或寫鎖競爭、用戶看到 inconsistent state。

原因：reader endpoint 是 DNS-based load balance 到所有 replica、failover 期間 短暫 包含已升 primary 的 replica（DNS propagation 期間 reader 跟 writer endpoint 都指向同一台）。Read query 打到 primary 後、跟正在寫的 transaction 競爭。

修：

• Application 端 read 跟 write data source 拆分、不要假設 reader endpoint 永遠 read-only
• Failover 期間 application 端做 SQL error type 偵測、read-only transaction 錯誤觸發 retry
• 用 custom endpoint group 特定 replica、failover 期間 custom endpoint 行為更可控

Case 4：In-flight transaction 全 abort

徵兆：failover 期間正在執行的 transaction 全部 abort、application 看到 connection reset 或 server closed connection、commit 沒成功。

原因：Aurora failover 不保留 transaction 狀態、所有 in-flight transaction（包括已執行 BEGIN 但還沒 COMMIT 的）全 abort。Application 沒做 idempotent retry 就會丟失 commit。

修：

• 寫操作必須 idempotent（用 idempotency key、application 端做 deduplication）
• 在 application 層做 transaction-level retry、不在 connection 層 retry
• 重要寫入做 write-then-verify 模式：commit 後立刻 SELECT 確認、失敗才 retry

Case 5：PromotionTier 配置忽略

徵兆：failover 後 application latency 暴漲、發現升 primary 的是 cross-region replica。

原因：cross-region replica 預設 PromotionTier 是 1（或忘記改）、failover 時優先升、application 跟新 primary 跨 region、latency 從 5ms 變 100ms+。

修：

• cross-region replica --promotion-tier 15（不優先升）
• 同 region 跨 AZ replica --promotion-tier 0 或 1
• Multi-AZ deployment 至少配 2 個 same-region replica、避免 cross-region 被升

Standard Chartered 為什麼選獨立 cluster 而非 Global Database

9.C14 Standard Chartered 揭露受監管產業的 failover 設計選擇 — 案例「判讀」段第 1 點：「7 個受監管市場代表 7 個獨立 cluster（資料不能跨境）、容量規劃變成『7 個獨立規劃 × 各自合規門檻』」。

合規 driver：

• 受監管市場資料 不能跨境複製
• Aurora Global Database 是跨 region async replication、會把資料推到其他 region
• → Global Database 在這種場景 違反合規、不是 DR 選項
• 必須用每市場獨立 cluster、各自做 cross-AZ failover、各自吸收 RTO 預算

工程含義：

• 每市場 cross-AZ failover RTO < 30 秒、滿足當地監管 RTO 要求
• 跨市場 DR 不靠 Global Database、靠應用層的 市場切換（用戶從 A 市場切到 B 市場是業務決策、不是技術 failover）
• 7 個 cluster 各自獨立、operational surface area × 7（parameter group / backup / IAM / observability fan-out）、但合規要求壓倒運維成本

Fleet 拓樸：合規驅動的 fleet 設計（7 個受監管市場 = 7 個獨立 cluster）詳見 Aurora read replica scaling fleet 治理 SSoT 邊界段。本篇只展開 單 cluster cross-AZ failover 流程、不展開跨 cluster 拓樸決策。

scope warning（必明示、case 自承）：Standard Chartered case 未公開是 PostgreSQL 還是 MySQL、未公開具體 cost 數字、屬「相關 case study」匿名對照。引用時不能擴寫具體 engine。

容量與觀測

核心 metric：

1FailoverEvent           # failover 觸發 counter、> 0 立即通知
2DatabaseConnections     # failover 期間 drop、之後 spike
3AuroraReplicaLag        # failover 前 replica 是否 caught up

Application 端 metric：

1first_successful_write_after_failover  # 真實 RTO
2connection_pool_error_rate              # stale connection 訊號
3db_retry_count                          # retry policy 觸發頻率

量測 RTO 流程：

1. 跑 application 端 every-second heartbeat insert
2. 手動觸發 failover、記錄 trigger 時間戳
3. 從 heartbeat insert log 找 failover 後第一個成功 insert 的時間戳
4. 差值 = 真實 RTO（包含 detection + promotion + DNS + reconnect）

Alert：

• FailoverEvent > 0 立即通知 on-call
• DatabaseConnections 5 分鐘內 drop > 50% 警告 stale connection
• db_retry_count 短期內 spike 警告 reconnect 風暴

Failover 演練頻率：

• Non-critical workload：每季一次 planned failover drill
• 受監管產業（Standard Chartered 類）：每月一次、有合規 sign-off 記錄
• 重大版本升級前必跑一次

回路徑：8.x incident response failover playbook、9.5 瓶頸定位流程 判斷 reconnect-bound vs query-bound。

邊界與整合 / 下一步

Sibling deep articles：

• Aurora storage architecture — 理解為什麼 Aurora failover 不需要 data catch-up（storage 跨 AZ 共享）
• Aurora read replica scaling — replica 升 primary 流程跟 fleet 治理 SSoT
• Aurora Global Database — 跨 region failover RTO 不同數量級（2-15 分鐘 vs cross-AZ < 30 秒）

Migration playbook：

• PostgreSQL / MySQL → Aurora — HA redesign 是 operational redesign 主項、從 Patroni / Orchestrator 切到 Aurora cluster endpoint

1.x 章節互引：

• 1.3 Transaction Boundary — failover 期間 in-flight transaction abort 對 application 契約的影響
• 8.x incident response — failover decision log

何時不用本文：non-critical workload、RTO 預算 > 5 分鐘、Multi-AZ 預設配置足夠時可跳過、看 Aurora vendor overview 即可。

相關連結

• Aurora vendor overview — 服務定位、適用 / 不適用場景
• Failover 卡片 — 概念基底
• RTO 卡片 — RTO 量測判讀
• Vendor 深度技術文章方法論 — 本文遵循的 6 規格面寫作模板
• 官方：Aurora high availability