本文不是 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

本文是 CockroachDB vendor overview 的 implementation-layer deep article。Overview 已界定 CockroachDB 的 multi-region 能力、本文聚焦 survival goal 配置怎麼從業務 SLO 倒推、怎麼避開「cross-region = 更快」的動機誤判。Raft replica 分佈機制屬前置、見 HLC + Raft consensus。

Multi-region 上線前的兩個錯誤期待

multi-region CockroachDB cluster 上線時、團隊最常踩的兩個錯誤期待：

• 「default 配置應該就好、上線後再說」：default 是 SURVIVE ZONE FAILURE、一旦遇到 region failure 整 cluster 變 read-only、客訴湧入才發現要重新配
• 「跨 region 應該會讓全球用戶都更快」：跨 region quorum 物理上必然 增 寫入 latency、把 multi-region 動機誤判成 latency 優化會在 production 撞牆

讀者進來最常問：

• SURVIVE ZONE FAILURE 跟 SURVIVE REGION FAILURE 差在哪？
• 為什麼 region survival 寫入 latency 是 zone survival 的 3 倍？
• Default 配置是什麼、上線前該不該改？

要回答這三題、必須先把 survival goal 跟業務 SLO 的對應關係講清楚。

9.C41 Hard Rock Digital 提供最 concrete 的 SLO 倒推路徑：sportsbook 中 bet placement 不能 lose — 玩家下注後系統 crash 沒紀錄、對博彩牌照是合規事故。CockroachDB Raft 3-replica + 跨 AZ + survival goal 配置是把這個業務不可丟事件翻譯成 DB 層保證。

9.C40 Netflix 則提供反直覺判讀：60+ multi-region cluster 主要動機是 region failure 0 downtime、不是降 latency。Gaming cluster 48-node 跨 4 region 就是為了「region failover 不停服」、不是讓玩家延遲變低。

對照 9.C14 Standard Chartered 走另一條路：銀行受監管市場資料 不能跨境、不可用 region survival、必須拆每市場獨立 Aurora cluster + zone survival。這個 anti-recommendation 提醒「survival goal 不是越強越好、合規邊界優先於技術 HA 配置」。

核心機制：兩種 survival goal + replica placement

兩種宣告式配置

CockroachDB 把 HA 配置抽象成兩個 database-level（或 table-level）宣告：

• SURVIVE ZONE FAILURE（default）：失去 1 個 AZ 仍能寫入。replica 跨 AZ 分佈、但可能集中在同一個 region 內。對應 RTO ~ 數秒（Raft + Leaseholder 自動 failover）、RPO = 0（已 commit 資料不丟）
• SURVIVE REGION FAILURE：失去 1 個整個 region 仍能寫入。voting replica 強制跨 region、需要至少 3 個 region。對應 RTO ~ 數秒、RPO = 0、但寫入 latency 因跨 region quorum 結構性增加

survival goal 是 宣告式 配置 — application 端不用手動指定 Range Sharding 的 replica placement、Raft 根據 survival goal + locality 自動分佈、用 Hybrid Logical Clock 串接 commit ordering。對比通用 HA 設計（如 PostgreSQL streaming + Patroni manual failover）、CockroachDB 把這層邏輯壓進系統內。

Voting vs non-voting replica

region survival 模式下、CockroachDB 區分兩種 replica：

• Voting replica：參與 Raft majority 決策、commit 必須等 voting majority ack。region survival 下 voting replica 強制跨 region — 這就是 Cross-Region Quorum 拓樸、commit latency 受跨洲 RTT 物理硬限主導
• Non-voting replica：只用來 serve Follower Read、不參與 Raft commit。可以放在「不想列入 quorum 但希望本地 read 快」的 region

實務影響：region survival 下、跨 3 region 配置最少 3 voting replica（每 region 1 個）、寫入要等其中 2 個 region 的 ack。若想讓第 4 個 region 也能本地 read、可以加 non-voting replica、不影響 commit latency 但增加 storage cost。

配置語法

1-- Database-level
2ALTER DATABASE mydb SURVIVE REGION FAILURE;
3
4-- Table-level（覆蓋 database 設定）
5ALTER TABLE orders SURVIVE ZONE FAILURE;
6
7-- 驗證
8SHOW SURVIVAL GOAL FROM DATABASE mydb;
9SHOW ZONE CONFIGURATION FOR DATABASE mydb;

對應 quorum 卡、rto 卡、rpo 卡、blast radius 卡 的具體機制實現。

為什麼選 region survival 是業務動機判讀、不是技術 fact（F4.8）

Netflix 60+ multi-region cluster 揭露的反直覺結論：主要動機是 region failure 0 downtime、不是降 latency。跨 region quorum 物理上必然增 latency — 跨洲 round trip 物理 ~70-80ms、Raft majority 需要 2 個 region ack、寫入 p99 因此被光速下界限制。

Gaming cluster 48-node 跨 4 region 就是為了「region failover 不停服」、不是讓玩家延遲變低。Scope warning：case 沒揭露 Gaming cluster 具體 p99 數字、只揭露「48-node、跨 4 region、region failure 不停服」這個拓樸 fact 跟業務動機釐清。

引用時若提到「region survival 怎麼提升用戶體驗」、要 釐清成 survival、不是 latency 優化。讓讀者誤把跨 region 當成 latency 解法、是這條決策最常見的源頭錯誤。

操作流程：從業務 SLO 倒推 survival goal

配置前置

region survival 的最小可運行配置：

• cluster 至少 3 個 region
• 每 region 至少 3 個節點（保證單一 region 內也能扛 AZ failure）
• locality tag 配齊（region + zone）

1# Region us-east1 的節點
2cockroach start --locality=region=us-east1,zone=us-east1-a ...
3
4# Region us-west2 的節點
5cockroach start --locality=region=us-west2,zone=us-west2-a ...
6
7# Region eu-west1 的節點
8cockroach start --locality=region=eu-west1,zone=eu-west1-a ...

從業務 SLO 倒推（9.C41 Hard Rock 揭露、F4.11）

Hard Rock Digital sportsbook 揭露的 5 步倒推流程：

1. 列業務「不能丟」事件清單：bet placement、payment、order commit、settlement 等業務事件
2. 對每個事件決定 RPO：bet placement → RPO = 0（不可丟）、log audit → RPO = 1 分鐘（可接受 short-window 丟失）
3. 對 RPO = 0 事件決定故障域容忍：Hard Rock 案例 Outpost 或 AZ 失敗不丟 是業務要求、跨 region failure 不是 sportsbook 的硬需求（因為各州各自合規邊界）
4. 故障域容忍翻譯成 survival goal：
   • Outpost / AZ 失敗 → SURVIVE ZONE FAILURE 即可
   • region 失敗也不丟 → SURVIVE REGION FAILURE
5. 反過來驗 replica 分佈：survival goal 配置產出的 replica 分佈是否覆蓋業務故障域。Hard Rock CockroachDB Raft 3-replica + 跨 AZ → Outpost 失敗時其他 replica 在、自動 failover、滿足 bet placement RPO = 0

跟業務動機釐清的互補

Netflix 從技術配置 反推「為什麼選 region survival」（survival 動機、不是 latency）、Hard Rock 從業務不能丟事件 正推 該選哪個 survival goal。兩個方向是同一條路徑：

• 正推（Hard Rock）：業務不能丟 → RPO → 故障域 → survival goal
• 反推（Netflix）：survival goal 配置 → 揭露的不是「會變快」而是「region failover 不停服」

兩個方向互相驗證、避免把跨 region 配置誤解成 latency 工具。

升級流程跟 rollback 邊界

zone survival → region survival 是 非破壞性 配置變更、Raft 自動 rebalance replica。但要注意：

• rebalance 期間 cross-region traffic 暴增、p99 短期波動
• replication factor 增加 → storage 用量 × 新 RF
• 升級後 application 寫入 latency 結構性上升、要先在 staging 量過

監控 rebalance：

1-- 看 range 數量變化跟 rebalance queue
2SELECT range_count, used FROM crdb_internal.kv_store_status;
3
4-- CockroachDB Console「Rebalance queue size」應該歸零

Rollback：survival goal 可即時降級（region → zone）、replica 自動 rebalance、無不可逆動作。但 application 端如果已經依賴 region failover 0 downtime、降級回 zone survival 後 region failure 會讓 cluster 變 read-only — 配置 rollback 容易、業務 SLO rollback 不容易。

失敗模式：5 種典型錯配

Default zone survival 期待 region survival

最常見：上線後一個 region 掛、cluster 變 read-only、客訴。要在 production 前 明確選 survival goal、不依賴 default。

Region survival 但只配 2 region

Raft majority 需要 3 個獨立 fault domain。2 region 配置實際是 zone survival — 任一 region 失敗剩 1 region 拿不到 majority。要 region survival 至少 3 region。

Cross-region cost 暴漲

region survival 強制 voting replica 跨 region、每次 write 跨 region traffic × 3。AWS / GCP 的 cross-region data transfer 是高 markup、月費可能 2-3 倍。

production 前必須估：

• 寫 QPS × row size × 3 = cross-region traffic GB/day
• 對應 cloud provider 定價（AWS 跨 region $0.02/GB、GCP 類似量級）
• 月度 traffic cost 加總、跟 single-region 配置比

Locality 跟 survival goal 衝突

業務想把 user data partition by region 留 local（locality 配置）、但 survival goal 要求跨 region replica、結果 replica 仍跑遠端。這是 locality + survival 的互動議題、見 locality-aware schema 詳細展開。

合規邊界 violation

受監管市場（金融 / 醫療 / 博彩）資料 不能跨境、但 region survival 強制 voting replica 跨 region — 這直接違反合規。對照 9.C14 Standard Chartered 走的是「每市場獨立 Aurora cluster + zone survival」、不是 region survival。

合規邊界判讀：

• 跨境合規 禁止 跨 region replica → 不可用 region survival、走 cluster-per-市場
• 跨州合規 允許 跨州但要求資料留國內 → 可用 region survival、選同國內的 region
• 業務邏輯要求跨 boundary（如 Hard Rock 跨州統一帳戶）→ 不可拆獨立 cluster、必須 locality + placement

容量與觀測

必看 metric

• Raft replicas per node：replica 分佈均勻度
• Range count by survival mode：region survival 配置的 range 數量
• Cross-region write latency p99：跨 region quorum 實測 latency
• Rebalance queue size：rebalance 是否完成
• Network traffic by direction：cross-region 流量、cost signal

容量公式

• region survival 最小：region count × 3 nodes
• replica factor 預設 3、storage 用量 × replication factor
• cross-region traffic = write QPS × row size × (region count - 1)

Write latency 預算（屬通用工程估算、case 未揭露具體 latency 數字）

Scope warning：以下數字屬通用工程估算（跨 region 物理光速下界推導）、Netflix / Hard Rock case 都沒揭露 zone / region survival 的 p99 latency 數字。引用時必須明示來源層次：

• zone survival single-region 寫入 p99 5-10ms（跨 AZ Raft round trip）
• region survival 同洲跨 region p99 30-60ms（跨 region round trip × Raft majority）
• region survival 跨洲 p99 100-150ms（跨洲光速下界 ~70-80ms × 2）

數字屬「合理的工程估算量級」、不是 case 揭露的 p99。讀者用這些做容量規劃時應該自己 benchmark、不要直接套。

賽季型容量擺盪（9.C41 Hard Rock）

sportsbook 業務年度循環：NFL / NBA 季初季末流量結構性差異 — Hard Rock 100 nodes ↔ 33 nodes 擺盪是 計畫內、不是異常事件。CockroachDB 加減節點靠 range rebalance、不停服。

容量規劃要點：

• NFL / NBA / 國際賽事曆塞進預測模型、不要當 surprise
• scale up 提前 1-2 週執行、留 rebalance 時間
• scale down 在淡季低流量時段執行、避免 rebalance 期間 p99 spike

回路徑

• 9.6 容量規劃模型 survival goal 對 replica count / cost 影響
• 9.11 高峰事件準備 event-driven scaling
• latency budget 卡 cross-region 預算

邊界與整合

Sibling deep articles

• HLC + Raft consensus：Raft 機制是 survival goal 的基礎
• locality-aware schema：locality + survival 一起決定 placement
• transaction retry pattern：cross-region latency 加長 retry window

跟 Aurora 對照

• Aurora cross-AZ failover：zone-level survival 等價、但只在 single-region 內
• Aurora Global Database：跨 region async replication、不是 sync — region failure 仍會丟 last seconds
• CockroachDB region survival：sync majority、region failure RPO = 0

Aurora 沒有 row-level locality 配置、跨 region 強一致要走 Aurora DSQL（AWS 2024 GA）。

Aurora DSQL / Spanner 對比

完整三家 distributed SQL 在 multi-region survival 的取捨、見 aurora-dsql-spanner-decision-tree。

1.x 章節互引

• 1.11 全球分散式 OLTP 上游
• 1.3 Transaction Boundary distributed transaction

何時不用 region survival

• single-region 已滿足業務 SLO → zone survival 即可
• 預算敏感、cross-region traffic cost 不划算
• 合規禁止跨境 → 必須拆每市場獨立 cluster + zone survival

相關連結

• CockroachDB vendor overview
• 9.C41 Hard Rock Digital（bet placement RPO=0 倒推）
• 9.C40 Netflix（Gaming 48-node 跨 4 region survival）
• 9.C14 Standard Chartered（anti-recommendation、為何 不用 region survival）
• quorum 卡 / rto 卡 / rpo 卡 / blast radius 卡
• 官方：CockroachDB Multi-Region Survival Goals / Multi-Region Capabilities Overview

概念位置

RTO 連接 downtime、failover 與 rollback-strategy。更短 RTO 通常需要更高操作準備與基礎設施成本。

可觀察訊號與例子

系統需要 RTO 的訊號是停機時間會直接影響收入或合約責任。付款服務若目標 RTO 為 15 分鐘，值班流程與切換能力都要圍繞這個目標設計。

設計責任

RTO 要對應分級、責任角色、演練頻率與驗證方式。設定後需用演練與真實事故資料驗證是否達成。