本文是 Cloud Spanner overview 的 migration playbook。走 vendor-article-spec Migration Playbook 規格 + migration-playbook-methodology Type E（paradigm shift）。每階段切換用 migration gate 把關 — Evidence 段列的證據是 gate 通過條件、不是 nice-to-have。

Driver：為什麼遷、什麼條件不該遷

啟動壓力

single-region Cloud SQL PostgreSQL primary 觸到容量上限（connection、write throughput、storage IOPS、region 故障風險）、產品要求跨 region active-active write、external consistency 是契約而非 nice-to-have。讀者要先確認自己面對的是「real 跨 region write residency」、不是「想用更強的技術」 — driver 段的核心責任是排除空泛動機。

主要 driver 候選

• Global write residency：用戶分散全球、各地寫入本地 region、跨 region 一致性是產品要求
• External consistency 對帳契約：跨 region 交易順序錯誤會導致對帳爆炸（金融、計費、ticketing）
• 單 primary 容量天花板：Cloud SQL 最大 instance 仍撐不住、應用層 sharding 是大工程
• 跨 region read latency：read 從各地直接打本地 replica、Cloud SQL read replica 受 single-primary 寫入 throughput 限制

No-go condition（基礎）

流量集中單 region、跨 region 只是 DR 需求 → 維持 Cloud SQL + read replica + cross-region async DR 更便宜。這條 no-go 不複雜、但團隊常被 marketing 推著跳過 — 在自家 traffic dashboard 上 audit 一遍「write 來自哪些 region、各占比多少」、若 90%+ 來自單 region、Spanner 沒有 benefit。

No-go condition（sizing barrier）

小 / 中型 PostgreSQL workload 的成本門檻 — Spanner 早期最小單位 100 processing units（≈ 1 node）對中小負載偏貴、過去是 sizing barrier；2021+ 推出 100 pu 起跳的 granular sizing 後雖然可從小開始、但 100 pu × per-pu monthly cost 加上跨 region replication 仍可能比 Cloud SQL HA 設定貴數倍。

來源 9.C10「判讀」段第 3 點：Spanner 早期 100 pu 起跳是 sizing barrier、後來推出 granular sizing 才讓中小負載可從小開始。Dogfood 邊界明示：9.C10 case 揭露的 sizing 結構是 Google 內部 dogfood 的 capacity 規劃語言、不是 customer-facing pricing 承諾；客戶實際成本要看當期 Spanner pricing + region + replication config。

觸發 sizing no-go 的條件：

觸發任一條 → 強烈建議走 Cloud SQL HA、不升 Spanner。判讀時要把 Cloud SQL HA cost vs Spanner 100 pu cost 對比清楚、避免讀者「想用新技術」而升級。

No-go condition（應用層延遲容忍）

應用層延遲容忍 < 50ms write 的 workload 不該升 Spanner — 跨 region Spanner write 在物理光速硬限下達 100-200ms（consistency-models-comparison 的 cross-region quorum 段）。延遲敏感 workload 升級後會在 p99 直接撞牆、回退時資料已經寫進 Spanner、roll back 成本巨大。

來源 9.C10「判讀」段第 2 點 + 「策略」段第 3 點：「external consistency 必須等多區 quorum、跨洲交易延遲可達 100-200ms」。Dogfood 邊界明示：9.C10 揭露的數量級是 Google internal observation、客戶實際 latency 隨 voting region 配置變化、引用時要附條件。

觸發 latency no-go 的場景：

• 實時報價系統（毫秒級回應）
• 高頻交易（HFT）
• 遊戲 leaderboard 寫入
• 低延遲 OLTP（金融下單、支付路由）

觸發任一條 → 強烈建議走 Cloud SQL 單 region、或考慮把 跨 region 一致性需求 重新審視（是否真的需要強一致、能不能改 event-driven async reconcile）。

替代方案排除

• Aurora DSQL：AWS 生態、若團隊在 GCP、跨雲不合
• CockroachDB：要自管或想 PostgreSQL wire 但不選 GCP 託管時可考慮、本 playbook 不對照
• Citus on Cloud SQL：multi-region write 不是強項、不解 cross-region external consistency 需求

Case anchor + dogfood 邊界

無強 customer case。9.C10 是 Google 內部 dogfood、不是公開遷移 case；本 playbook 用 Spanner overview 的 PostgreSQL dialect 路徑 + 官方 migration guide + 通用 pattern。引用時必須明示「9.C10 揭露的線性 scaling / line-rate 設計目標是 Spanner 設計依據、不等於客戶遷移後可獲得的 capacity」。

對照 case：9.C14 Standard Chartered Aurora 受監管 banking — 雖然是 Aurora、不是 Spanner、但揭露「受監管 OLTP 遷移要算合規 lead time」「資料駐留限制 = 容量規劃 per-市場」這兩條結論在 Spanner 遷移同樣適用。讀者若是受監管產業、跨 region instance config 還要疊上 voting region 是否落在合規市場的 audit。

Diff Audit（6 規格面 + sizing / cost 第 7 面）

Schema diff

PostgreSQL DDL → Spanner PostgreSQL dialect 對照：

interleaved table 設計參考 schema-migration-interleaved-tables。讀者要在 schema audit 階段就決定哪些 parent-child 該 interleave、避免後悔成本。

Operational diff

不再需要的 Cloud SQL 責任：vacuum、autovacuum tuning、connection pool（PgBouncer）、replication lag 監控、Patroni HA。

新增 Spanner 責任：processing unit capacity 預測、TrueTime ε 觀測（truetime-api-depth）、long-running schema operation 跟蹤、IAM 細粒度權限。

Paradigm diff

從 single-primary OLTP → 跨 region distributed SQL：

• transaction commit latency：< 5ms → 50-200ms（跨洲、含 Commit Wait + cross-region quorum）
• external consistency 是 default（不再是 isolation level 選擇題）
• transaction 上限：Cloud SQL 無硬限 → Spanner 10s timeout、要重構成短交易
• read consistency：default eventual → default strong、需顯式選 bounded staleness

詳細 consistency model 差異看 consistency-models-comparison。

Component diff

退役：

• PgBouncer / pgcat（connection pool）
• Cloud SQL HA / Patroni cluster
• pgBackRest（備份外掛）
• Citus extension（若有用）
• 各種 postgres extension（時間敏感、逐個 audit 是否 Spanner 支援等效）

新增：

• Spanner client library（Go / Java / Node / Python）
• Dataflow（用於 bulk export-import）
• Datastream / Database Migration Service（用於 CDC catch-up）
• Spanner Studio（query UI）

Application diff

ORM 兼容性是 time-sensitive claim — JPA / Hibernate / SQLAlchemy 在 Spanner PostgreSQL dialect 上的行為隨 dialect 版本演進、實作前查最新 vendor docs。讀者要把 ORM 兼容測試放 Phase 0、不能假設「PostgreSQL ORM 直接搬到 Spanner」。

Data topology diff

• Single primary（write）+ read replica → multi-region voting + read-only replica
• Primary key 設計：避免單調遞增（SERIAL）造成 hot split、改 UUID 或 bit-reversed
• Partition：PostgreSQL declarative partition → Spanner 不需要顯式 partition（自動 split）

Sizing / cost diff（第 7 規格面）

觸發 sizing audit 的時機：workload 行數、QPS、跨 region 需求都明確後、把「Cloud SQL HA monthly bill」對「Spanner 100 pu × monthly rate + egress」做 cost crossover 分析、無法 cost crossover 證明 → 不升。

Cost crossover 不是「Spanner 成本必須低於 Cloud SQL」、是「Spanner 多付的成本要對應到具體 benefit」：

• 若 benefit 是 multi-region write residency、Spanner 多付的 cost 換得跨 region 一致性 — 對齊
• 若 benefit 只是「更新的技術」、Spanner 多付的 cost 沒對應產品價值 — 不升

Type 判定

Type E（paradigm shift）、不是 drop-in。schema / app / operation / data topology / cost 五軸都動、不能用 Type B（drop-in）思路規劃 phase。詳細 type 判定方法看 migration-playbook-methodology。

Phase Plan：9 段、每段有驗證門檻

Phase 0 — Compatibility audit + sizing audit

跑 schema-converter（pgloader / Spanner migration tool）、列出 incompatible feature、決定哪些改 schema、哪些改 app。hot key 風險評估（SERIAL primary key、單調遞增 timestamp）。

同時跑 sizing audit：

• 估 target Spanner pu 數（基於 QPS、storage size、cross-region replication factor）
• 做 Cloud SQL HA cost vs Spanner cost crossover 分析
• 若 cost crossover 證明不出來 → halt migration、回到 driver 段重審

Phase 0 是 migration 的決策閘門 — 不過閘門就停、不浪費 Phase 1+ 的 engineering effort。

Phase 1 — Target schema design

• interleaved table 設計（base on Phase 0 access pattern audit）
• Index 重寫（GIN / GiST 用 STORING column 替代、其他用 B-tree）
• Primary key 反序（避免 hot split）
• Storing column 選擇（trade-off：query latency vs index size）

Output 是 target DDL、跟原 PostgreSQL schema 並排 diff 文件、給 application 團隊審。

Phase 2 — Application dual-target preparation

• 抽象 DB layer（repository pattern、避免直接呼 SQL）
• SDK 並存（go-pg + Spanner client）
• Feature flag 控制讀寫路徑（read-from-pg / read-from-spanner / dual-write）
• Transaction 模式 audit（長交易拆短）

Phase 3 — Bulk initial load

Cloud SQL → Cloud Storage（CSV / Avro）→ Dataflow → Spanner。Row count + checksum 驗證、column-level diff sample。

Phase 4 — CDC catch-up

Datastream from Cloud SQL → Dataflow → Spanner。Replication lag < 1s 為前進門檻、sustained 24h。

Phase 5 — Shadow read

Production read 同時打 Cloud SQL 跟 Spanner、diff log 異常。至少 7 天觀察、divergence rate < 0.1%、p99 latency Spanner < 1.5x Cloud SQL。

Phase 6 — Dual write

Cloud SQL 為 source-of-truth、Spanner 為 mirror。偵測 dual write divergence、評估是否提早升 source-of-truth。

Phase 7 — Cutover

read-only window（< 5 min）→ 最後 catch-up → switch source-of-truth → cutover application write。

Phase 8 — Cleanup

退役 Cloud SQL primary、保留 backup、清 PgBouncer / Patroni / 監控 dashboard。

Stage 0 variant 規劃

若 read-only window 不可接受（24/7 不能停機的金融 / 醫療系統）、Phase 6 dual write 期間做 conflict resolution（last-writer-wins + manual reconcile）、進入 fail-forward 模式、不走 read-only cutover。

Evidence：每階段驗證材料

Cost crossover 報告（Phase 0 必交付）：

 1Item                          | Cloud SQL HA | Spanner 100 pu | Delta
 2------------------------------|--------------|----------------|------
 3Compute monthly               | $X           | $Y             | $Y-X
 4Storage monthly               | $A           | (included)     | -$A
 5Cross-region replication      | $B           | (included)     | -$B
 6Egress (est)                  | $C           | $C             | $0
 7Total monthly                 | $X+A+B+C     | $Y+C           | $Y-X-A-B
 8Annual                        | 12*above     | 12*above       | -
 9Benefit (qualitative)         | -            | multi-region write residency / external consistency | -
10Crossover verdict             | -            | proceed / halt | -

Verdict = proceed 才進 Phase 1；halt → 回到 Driver 段重審 driver 是否成立。

所有 evidence 進 incident decision log、回 4.20 Observability Evidence Package。

Cutover：決策與 rollback

Cutover window

選用戶最低流量時段、< 5 min read-only freeze、預先通知。受監管產業（對照 9.C14 Standard Chartered）要算合規 lead time、每市場各自審。

Decision owner

DB lead + product lead + on-call SRE 共同 sign-off。受監管產業多加合規 owner。

Rollback condition

• cutover 後 30 min 內 p99 write latency 持續 > SLA 2x → rollback
• error rate > 1% sustained 5 min → rollback
• 對帳系統發現 divergence > 0.1% → rollback

Rollback 機制

保留 Cloud SQL 為 read-only mirror 14 天、Spanner 改 read-only、reverse CDC（Spanner → Cloud SQL）需事先準備。Reverse CDC 在 Phase 4-6 期間就要 dry-run 過、不能 cutover 才第一次試。

連結 rollback-window、rollback-condition。

Cleanup：退役清單跟保留責任

退役清單

• Cloud SQL primary instance
• PgBouncer 配置
• Patroni cluster
• pgBackRest backup job（保留歸檔 90 天、依產業合規）
• Datastream pipeline
• Dataflow job

監控清理

postgres-specific dashboard（exporter / wal lag / autovacuum）改成 Spanner dashboard（commit_latencies / clock_skew_ms / cpu_utilization_by_priority）。

文件 / runbook 更新

postgres operation runbook 標記 deprecated、Spanner runbook 上線。新 runbook 含：

• DDL long-running operation 監控
• TrueTime ε 異常處理
• Cross-region instance failover drill
• Cost monitoring alert

稽核 / 合規

保留 final pg_dump 7 年（依產業）、incident write-back 完成、合規市場各自留檔（對照 Standard Chartered case 的 per-市場合規 lead time）。

邊界與整合：sibling、對照、anti-recommendation

Sibling deep articles

• truetime-api-depth：app 對 timestamp 假設審計（Phase 2 必讀）
• schema-migration-interleaved-tables：Phase 1 target schema 設計
• consistency-models-comparison：Phase 0 應用層一致性要求釐清、Driver 段 latency no-go 的物理硬限

跟其他 migration 對照

• PostgreSQL → Aurora DSQL Migration：兩者都是 PostgreSQL → distributed SQL paradigm shift、選 GCP / AWS 看生態
• 1.12 大規模 DB 遷移實戰：通用大規模遷移方法論

跟 case 對照

• 9.C10 Cloud Spanner planetary scale：dogfood case、揭露 Spanner 設計目標、不是 customer-facing capacity reference
• 9.C14 Standard Chartered Aurora banking：受監管產業遷移要算合規 lead time、per-市場容量規劃

Anti-recommendation

讀者讀完本文應該能判斷：

• 若 driver 只是「想用新技術」→ 回 Cloud SQL
• 若 workload 小（QPS < 1000、行數 < 數百萬）→ Cloud SQL HA 更划算
• 若應用層延遲容忍 < 50ms write → Cloud SQL 單 region
• 若 cost crossover 證明不出來 → halt migration、不升

Driver 是真正跨 region write residency / external consistency 對帳契約 / 單 primary 容量天花板 → 才升。Migration playbook 的目標不是把所有 Cloud SQL workload 升到 Spanner、是把「適合升」的部分用低風險路徑遷過去。

本 playbook 不重複 Aurora overview（請看 Aurora vendor 頁）— 前置閱讀建議 Aurora storage architecture（理解為什麼 operational redesign）、Aurora cross-AZ failover RTO（HA redesign 主項）、Aurora read replica scaling（fleet 治理 SSoT、含合規 driver）。

Migration type 判定

本 playbook 是 Type C：Operational redesign hybrid：

• PostgreSQL / MySQL → Aurora wire protocol 相容、application 多數不改
• 但 operational model（HA / backup / monitoring / capacity）完全不同、需要 redesign
• 跟 Type A schema translation 差：不需要翻譯 application SQL
• 跟 Type B drop-in 差：HA / backup / monitoring / capacity 模型需要 redesign
• 跟 Type E paradigm shift 差：保留 single-primary SQL 跟 ACID transaction 語意

對照其他 Aurora-related migration playbook：

• PG → Aurora DSQL 是 Type E paradigm shift（distributed SQL、multi-region active-active）
• PG → CockroachDB 是 Type E paradigm shift + cross-cloud

Driver：為什麼遷

主要 driver

• 團隊規模成長、DBA bandwidth 飽和、backup / failover / patch 操作負擔超過產品價值
• Read replica scaling 需求（傳統 streaming replication lag 秒級、Aurora 10-30ms — 詳見 Aurora read replica scaling）
• Storage growth 痛點（local SSD 上限、resize 要 downtime、Aurora 自動 grow 到 128 TB）

次要 driver

• HA model 簡化（Patroni / Orchestrator → Aurora cluster endpoint、見 cross-AZ failover RTO）
• Backup 自動化（pgBackRest / xtrabackup → Aurora automated backup + PITR）
• Multi-region DR 需求（Aurora Global Database、但合規場景例外）

No-go condition（嚴格遵守）

跨雲 / on-prem 需求觸動 vendor lock-in — Aurora storage layer 是 AWS 專屬、wire protocol 相容不代表退出成本低、long-term 跨雲策略未定時 self-managed PG / MySQL 反而保留路徑。

合規禁止跨境複製 no-go（9.C14 Standard Chartered 揭露）：

受監管市場資料不能跨境複製、Aurora Global Database 在這種場景違反合規。讀者規劃 Aurora migration 時不能假設「Aurora 一定有 Global Database 選項」— 要改用每市場獨立 cluster（fleet 拓樸吸收合規邊界、見 Aurora read replica scaling fleet SSoT）。

替代方案

• RDS PostgreSQL / MySQL：更接近 upstream、單 AZ 便宜、不重寫 storage
• 自管 + Patroni HA + pgBackRest：保留控制、跨雲可用
• CockroachDB / Aurora DSQL：multi-region active-active write 需求

Case anchor

• 9.C23 Netflix Aurora consolidation：多套 RDBMS 統一到 Aurora、driver 是 operational consolidation、不是純效能
• 9.C4 DraftKings：200 個 cluster、按業務切分（不是一個大 cluster + 200 schema）
• 9.C14 Standard Chartered：受監管場景、合規 lead time 是時程主項

Netflix scope warning（必引用）：

• case「需要警惕」段第 2 點原文：「Netflix 數據層遠不止 Aurora — 還有 Cassandra（playback metadata）、EVCache（cache layer）、Iceberg（data warehouse）。Aurora 主要是『需要 ACID 的 OLTP 工作負載』、不是『all-purpose store』」
• 工程含義：consolidation 是 ACID OLTP 整合到 Aurora、不是 所有 store 整合到 Aurora
• 讀者規劃整合範圍時要明示什麼 workload 不在範圍（cache、analytics、time-series、search、KV 高峰）
• 「+75% performance improvement 是跨多 workload 的最大改善幅度、不是『每個 workload 都 +75%』。實際每個 workload 改善幅度從 10% 到 75% 不等」（case「需要警惕」段第 1 點）

Diff audit：6 維 source / target 差異盤點

主導差異：Operational layer（HA / backup / monitoring）、不是 schema 或 application。

Schema diff 細節

PostgreSQL → Aurora PostgreSQL：

MySQL → Aurora MySQL：

Operational diff 細節

Application diff 細節

1# Self-managed PostgreSQL
2jdbc:postgresql://primary.internal:5432/mydb?ssl=true&sslmode=verify-full&sslrootcert=/etc/ssl/postgresql.crt
3
4# Aurora PostgreSQL
5jdbc:postgresql://my-cluster.cluster-xxx.us-east-1.rds.amazonaws.com:5432/mydb?ssl=true&sslmode=verify-full&sslrootcert=rds-ca.pem

Application 改動量小：connection string 換 endpoint、SSL CA 換 RDS CA、driver 不變。

對應 knowledge card：failover、replication-lag。

Phase plan：階段切換

Phase 0：Pre-migration audit（2-4 週）

工作：

• Extension audit：SELECT * FROM pg_extension / SHOW PLUGINS、列出 source 使用的 extension
• Parameter audit：postgresql.conf vs Aurora parameter group、列差異
• Application connection string audit：所有服務的 DB connection 點位
• Benchmark baseline：write QPS / read QPS / p99 latency
• Cost baseline：current self-managed monthly cost vs Aurora estimate

Output：

• Migration feasibility report（含 no-go condition check）
• Aurora cluster sizing 估算
• Extension migration plan（each extension 對應的策略）

Phase 1：Aurora infra 準備（1-2 週）

工作：

• Aurora cluster 開設（dev / staging / prod）
• Parameter group 對位（從 source postgresql.conf / my.cnf 翻譯到 Aurora parameter group）
• SG / subnet / IAM 設定
• RDS Proxy 配置（如需要）
• CloudWatch dashboard + Performance Insights baseline
• Backup retention 設定（1-35 天）

Output：

• Aurora cluster 待 data load
• Monitoring 已 ready、能對照 source 跟 target

Phase 2：Data migration（2-8 週、依資料量）

三條 path、依場景選：

Path A：AWS DMS full load + CDC

• 適合：< 1 TB、可接受 read-only 短窗口
• 流程：DMS full load → DMS CDC → application cutover
• 優點：managed、validation 工具齊全
• 缺點：CDC lag 受 DMS task config 影響、bulk DDL 不友善

Path B：pg_dump / mysqldump + logical replication catch-up

• 適合：> 1 TB、要長 CDC 期、預算敏感
• 流程：snapshot → pg_dump / mysqldump → restore to Aurora → logical replication catch-up → application cutover
• 優點：成本低、可控性高
• 缺點：手動步驟多、要自己管 CDC lag

Path C：Snapshot restore

• 適合：已在 RDS PostgreSQL / MySQL
• 流程：RDS snapshot → Aurora restore-from-snapshot → catch-up → application cutover
• 優點：最快、AWS-internal 操作
• 缺點：只適用 RDS source、不適用 self-managed

Phase 3：Dual-read validation（1-2 週）

工作：

• Application read 50/50 split source / target
• 比對 query 結果（per-table checksum + sampling）
• 量測 latency（Aurora p99 ≤ source × 1.2）
• 確認 stale read 比例 < 0.01%

Output：

• Validation report：query 結果差異、latency 對照
• Go/no-go decision for cutover

Phase 4：Cutover（< 1 小時 window）

工作：

• Source set read-only
• CDC catch-up final（lag → 0）
• Application switch endpoint（DNS / service discovery / config flag）
• Smoke test（critical path query + write）
• Monitor error rate + latency 1 小時

Output：

• Cutover complete
• Source 切到 read-only、保留作為 rollback 餘地

Phase 5：Cleanup（4-8 週）

工作：

• Source 保留 1 個月 read-only（rollback window）
• 確認穩定後 snapshot → S3 archive → decommission
• 舊 monitoring / backup / runbook archive

Output：

• Source decommissioned
• 新 runbook + monitoring 為 SSoT

本 phase plan 適用範圍

Non-regulated workload（一般 SaaS / e-commerce / 內部系統）。受監管場景（銀行 / 保險 / 醫療）請見下方「合規驅動遷移的時程模型」段、技術 phase 不變但 lead time 完全不同。

合規驅動遷移的時程模型

受監管產業遷移的關鍵時程是 合規審查 lead time、不是技術遷移時間 — 本段是補充給銀行 / 保險 / 醫療讀者、避免照本 playbook 走嚴重低估時程。

Standard Chartered 揭露的時程模型

9.C14 Standard Chartered case 「判讀」段第 3 點 + 「策略」段第 3 點原文：「每個受監管市場的審查可能 3-12 個月、合計遷移時程是『市場數 × 平均審查月份』、不是『技術遷移月份』」。

工程含義：

• 技術 phase plan 假設 2-8 週 data migration + < 1 小時 cutover
• 合規 lead time 是 獨立軸、可能比技術時程長一個數量級
• 不同市場合規進度不同步、可能要分批上線

合規時程組合

讀者判讀

• 受監管場景 不能 用本 playbook 的「2-8 週 data migration + < 1 小時 cutover」估時程交付給管理層 — 合規 lead time 是時程主項
• 受監管場景 不能 假設 Aurora Global Database 是 multi-region DR 選項 — 合規禁止跨境複製場景下 Global Database 違反合規（見 global-database-multi-region），要改用每市場獨立 cluster
• 合規場景的 phase plan 要把每市場當成獨立 mini-migration、用 市場批次 推進、不是一次 big bang

scope warning（必明示、case 自承）：Standard Chartered case 未公開是 PostgreSQL 還是 MySQL、未公開具體 cost 數字 — 引用時不能擴寫「Standard Chartered 用 Aurora PostgreSQL」這類細節（case 用「相關 case study」匿名標明）。

合規時程 scope 警示：「3-12 個月、7 市場 × 6 個月 ≈ 3.5 年」是 Standard Chartered case 揭露範圍。實際合規 lead time 隨產業（銀行 / 保險 / 醫療）跟國家（東南亞 / 歐盟 / 北美 / 中東）差異大、不是恆定數字。讀者要把自家對應監管框架的實際 lead time 算進來、不是直接套 Standard Chartered 數字。

Evidence：每階段驗證資料

受監管追加 evidence：

• 每市場合規 sign-off 文件（central bank / 金融監管機關）
• 跨境複製禁令審查記錄
• Data residency 驗證測試（資料未流出受監管市場 boundary）
• Audit log 連續性驗證（source / target audit log 銜接）

回路徑：4.20 Observability Evidence Package 抽 CDC / latency evidence。

Cutover：切流決策

Cutover window：

• 建議 4 AM local time（lowest traffic）
• 預留 4 小時 buffer
• 受監管場景可能要在合規規定的 maintenance window（例如某些央行規定週日凌晨）

Rollback condition：

• error rate > baseline × 5
• write latency p99 > baseline × 3 持續 10 分鐘
• data corruption signal（checksum mismatch、unexpected row count drop）

Rollback path：

• Application connection string 切回 source
• Source 仍 read-write（cutover 前留 read-write 路徑、若已 read-only 要先解凍）
• CDC 反向同步（Aurora → source）catch-up

Decision owner：

• DBA lead + service owner + on-call SRE 三方 sign-off
• 受監管場景追加 compliance officer sign-off
• Cutover decision log 記錄（rollback window / rollback condition 文件化）

對應 knowledge card：rollback-window、rollback-condition。

Cleanup：雙軌退役

不可逆 cleanup 邊界：

• Source decommission 後資料只能從 backup restore
• 確保 backup 可用性測試通過再 decommission
• 受監管場景要保留 source backup 到合規 retention（金融 7 年、可能更長）

案例對照

Netflix Aurora consolidation：operational consolidation 的價值

9.C23 Netflix 多套 RDBMS（PostgreSQL / MySQL / Oracle）→ Aurora、+75% 效能 / -28% 成本。

驗證的 driver：

• DB 種類太多本身是規模化的成本（每多一種 DB 多一套 DBA 知識 / backup / monitoring）
• 整合到 Aurora 釋放工程資源、不是純效能改善

case 自帶警示（必引用）：

• 「+75% 是跨多 workload 最大改善幅度、不是每 workload 都 +75%」（case「需要警惕」段第 1 點）
• Aurora 非 all-purpose store 邊界：「Netflix 數據層遠不止 Aurora — 還有 Cassandra（playback metadata）、EVCache（cache layer）、Iceberg（data warehouse）。Aurora 主要是『需要 ACID 的 OLTP 工作負載』」（case「需要警惕」段第 2 點）

工程含義：consolidation 是「ACID OLTP 整合到 Aurora」、不是「所有 store 整合到 Aurora」。讀者規劃整合範圍時要明示什麼 workload 不在範圍：

DraftKings：fleet 拓樸 redesign

9.C4 DraftKings 200 個獨立 Aurora cluster、按業務切分（不是一個大 cluster + 200 schema）。

驗證的 driver：

• Migration 不只是技術切換、也是 cluster 拓樸 redesign
• 業務本身可切分（每體育類別 / 每地理 / 每產品線）就在 migration 時順便拆 cluster
• Blast radius 隔離跟容量規劃分散一起獲得

Fleet 拓樸決策：詳見 Aurora read replica scaling 邊界段 SSoT。本 playbook 提醒 migration 是拆 cluster 的好時機、不展開拓樸決策本身。

Standard Chartered：合規 lead time + 跨境複製禁令

9.C14 Standard Chartered 受監管場景揭露：

• 合規 lead time 是時程主項（3-12 個月 / 市場）
• 跨境複製禁止讓 Global Database 變反指標
• 每市場獨立 cluster + cross-AZ failover 是合規場景的標準解

反例：Aurora 不適合的場景

• Multi-region active-active write：見 PG → Aurora DSQL Migration
• 跨雲：見 PG → CockroachDB Migration
• 極端寫入吞吐（> 100K WPS）：考慮 sharding、CockroachDB、或 DynamoDB

邊界與整合 / 下一步

Sibling playbook：

• PG → Aurora DSQL — paradigm shift、Type E、multi-region active-active
• PG → CockroachDB — cross-cloud、paradigm shift
• PG → Aurora — 既有 PG-specific playbook、可對照本 playbook 的 vendor-neutral 版本

Sibling deep article：

• Aurora storage architecture — 理解 storage 設計才知道為什麼 operational redesign
• Aurora cross-AZ failover RTO — HA redesign 主項
• Aurora read replica scaling — fleet 治理 SSoT、含合規 driver
• Aurora Global Database — 合規禁止跨境複製的 anti-recommendation

1.x 章節互引：

• 1.12 大規模 DB 遷移實戰 — migration 上游 framework

何時不用本 playbook：

• 從 Aurora 遷到別處（反向、走對應的反向 playbook）
• 從 RDS PostgreSQL 升 Aurora PostgreSQL 是 in-place upgrade、用 RDS console「Convert to Aurora」即可、不需要這套 playbook
• 跨雲遷移：本 playbook 不涵蓋 GCP / Azure SQL → Aurora 流程

相關連結

• Aurora vendor overview — 服務定位、適用 / 不適用場景
• Failover 卡片 — 概念基底
• Replication Lag 卡片 — operational diff 主軸
• Rollback Window 卡片 — cutover decision
• Rollback Condition 卡片 — rollback trigger
• 9.C23 Netflix — operational consolidation 跟 Aurora 非 all-purpose store 邊界
• 9.C4 DraftKings — fleet 拓樸 redesign
• 9.C14 Standard Chartered — 合規 lead time + 跨境複製禁令
• Migration Playbook 寫作方法論 — 本文遵循的 6 規格面寫作模板
• 官方：Aurora migration documentation

概念位置

Playbook 位在 incident command system、rollback-strategy 與 post-incident-review 之間。復盤後的改進常會沉澱成新的 playbook。

可觀察訊號與例子

系統需要 playbook 的訊號是某類事故反覆出現且處置步驟可預期。consumer lag 持續擴大、憑證即將過期、單區域流量異常等場景都適合建立專用 playbook。

設計責任

Playbook 要定義觸發條件、必要查詢、操作步驟、停止條件與回復驗證。內容應保持短而可執行，並在每次演練或真實事故後更新。