💡 先搞懂問題
虛構的「晴空食品」把網購訂單放在 Cloud SQL for PostgreSQL，一開始只開了一台單一可用區的執行個體。某天那個可用區出問題，網站停了好幾個小時，因為單一可用區的執行個體沒有任何可以接手的機器。之後團隊開了「高可用」，以為順便解決月底報表拖慢下單的問題，結果報表照樣卡：高可用多出來的那台待命機平常根本不接查詢。再後來他們加了讀取備用資源分擔報表，有一天工程師下錯一行 DELETE，主要執行個體、待命機、備用資源三台同步把資料刪光，最後靠的是自動備份加上時間點復原（PITR，point-in-time recovery）。
這三次事件分別對應 Cloud SQL 三組容易混在一起的機制。高可用性設定（high availability，HA）又叫區域型執行個體（regional instance）：在同一個區域（region）的另一個可用區（zone）放一台待命執行個體，寫入同步寫到兩個可用區的磁碟，主要執行個體或整個可用區故障時自動容錯移轉（failover），約 60 秒恢復、IP 不變，但待命機平常不能讀。讀取備用資源（read replica）是唯讀的複本，用來分擔讀取，可以放在同區域或其他區域，但它不會自動接手。至於誤刪資料，這些複本都會跟著刪，只能靠自動備份與時間點復原建立一個新的執行個體。
生活比喻：總店主廚、備位主廚與分店
想像晴空食品開了一家很紅的餐廳。總店主廚負責每一道菜，所有點單都經過他。為了不怕他突然倒下，餐廳在隔壁廚房安排一位備位主廚：主廚每做一步，備位主廚就在旁邊同步記下，兩邊的進度永遠一樣；但備位主廚不幫客人出菜，只有在主廚倒下時才在一分鐘左右接手，而且客人打的還是同一支訂位電話。另外，餐廳在附近開了幾家分店，照總店傳來的食譜做外帶，分擔排隊人潮；食譜是一份一份傳過去的，所以分店的菜單可能比總店晚幾分鐘更新。總店真的關門時，分店不會自動變成總店，要老闆正式宣布由哪一家接手，接手之後也就不再跟著原本的總店。
規模再大一點，餐廳在另一個城市開了分店，總店所在的城市整個停電時，可以宣布由那邊接班；更高級的方案是美食街模式，好幾個外帶窗口共用一個叫號系統，客人不用知道是哪個窗口；以及事先指定好一家「異地接班分店」，總機號碼會自動轉過去。最後，如果廚師把一整鍋醬汁加錯料，備位主廚和分店都已經照做了，這時唯一的辦法是翻出昨天存檔的食譜，再照點單流水帳重做到出錯前一刻。
這個比喻有幾個地方和實際不同。第一，備位主廚在現實裡可以順手出幾道菜，Cloud SQL 的 HA 待命機完全不接讀取，要分擔讀取只能另外建備用資源或讀取集區。第二，餐廳的備位主廚和主廚在「隔壁廚房」，代表 HA 只保護同一個區域；整個區域停擺時，HA 幫不上忙，要靠跨區域的備用資源。第三，「照食譜重做到出錯前一刻」在 Cloud SQL 是建立一個新的執行個體，不會在原本那台上倒轉，應用程式要改連新執行個體，或把資料搬回去。第四，比喻裡宣布分店接手只是一句話，實際升級備用資源後，原本的複寫關係就斷了，非同步還沒送過去的交易也可能遺失。
🎮 互動實驗室一：故障與讀寫模擬器
先選一種部署，下方會畫出主要區域的三個可用區與一個次要區域裡各有哪些執行個體（深紫是主要執行個體、虛線灰是不可讀的待命機、黃色是讀取備用資源、淡紫是讀取集區節點、紫框是 DR 備用資源）。接著觸發一個事件：主要執行個體故障、可用區故障、整個區域故障、大量報表查詢，或工程師誤刪資料。開著「先猜再看」時，會先請你回答一個是非題，答完才公布四格結果：會不會自動容錯移轉、大約多久或有什麼影響、讀取能不能分擔、需不需要時間點復原。
主要區域 asia-east1 的三個可用區＋次要區域 示意
行為依 Cloud SQL 文件「About high availability」「About replication」「About read pools」「Disaster recovery」「Editions」，查證時間 2026 年 10 月：HA 每秒心跳檢查、容錯移轉約 60 秒（會變動）、共用同一個 IP；單一可用區執行個體遇到可用區故障不會自動復原；讀取備用資源無法容錯移轉，只能升級；讀取集區與進階 DR 只限 Enterprise Plus。時間點復原的交易記錄保留期：Enterprise 最多 7 天，Enterprise Plus 預設 14 天、最多 35 天。
🎮 互動實驗室二：資料庫選擇分診台
十張虛構公司的情境卡，一次出現一張。讀完需求後，從七個選項裡挑出最適合的一個：Cloud SQL、AlloyDB for PostgreSQL、Spanner、Firestore、Bigtable、Memorystore、BigQuery。選完立刻告訴你對錯，並說明為什麼是它、為什麼不是最容易混淆的那一個。全部做完會顯示分數，可以重來再練一次。
🛠️ 操作教學：建立高可用的 Cloud SQL for PostgreSQL 與讀取備用資源
不用登入 Google Cloud，也能先把流程走一遍。左邊是簡化的雲端控制台，照步驟填表、按按鈕；右邊同步顯示等效的 gcloud CLI 與 Terraform，黃色底的那幾行就是目前這一步對應的指令。可以故意把執行個體 ID 打成大寫、把高可用的次要可用區選成和主要相同，或在 Enterprise 版本把交易記錄保留天數填成 14，看驗證訊息怎麼說明；也可以改 ID、區域或版本，看指令怎麼跟著變。範例裡不會出現任何密碼。
terraform destroy 會刪除它建立的資源，但只要 deletion_protection = true（Terraform 層級）或 settings.deletion_protection_enabled = true（API 層級）還開著，刪除就會失敗，要先改成 false 並套用。不想自己準備 Terraform 執行環境，可以用 Google 託管的 Infrastructure Manager；舊的 Deployment Manager 已在 2026 年 3 月底結束支援，新設計不要再用。
自己動手時要注意
權限方面，建立與管理執行個體需要 Cloud SQL Admin（roles/cloudsql.admin）；設定私人服務存取需要能管理 VPC 網路的角色，例如 Compute Network Admin（roles/compute.networkAdmin）。應用程式或使用者用 IAM 資料庫驗證登入時，需要 Cloud SQL Instance User（roles/cloudsql.instanceUser），透過 Cloud SQL Auth Proxy 或語言連接器連線另需 Cloud SQL Client（roles/cloudsql.client）。要先啟用 Cloud SQL Admin API（sqladmin.googleapis.com）、Service Networking API（servicenetworking.googleapis.com）與 Compute Engine API。
費用方面，Cloud SQL 依 vCPU、記憶體、儲存空間、備份與網路計費，執行個體開著就算錢；高可用的執行個體費用是單機的兩倍，每個讀取備用資源也是一台獨立計費的執行個體，跨區域備用資源還有跨區域傳輸費。新帳戶的 Free Trial 有 300 美元抵用金、期限 90 天（查證日期 2026-10-08），練習用的執行個體可以選小一點的規格、做完立刻刪除。密碼不要寫進腳本或 Terraform 檔：用 IAM 資料庫驗證、在終端機互動輸入（--prompt-for-password），或把密碼放在 Secret Manager 由應用程式讀取。
# 先關閉刪除保護，再刪除備用資源與主要執行個體
gcloud sql instances patch qingsong-orders-db --no-deletion-protection
gcloud sql instances delete qingsong-orders-replica
gcloud sql instances delete qingsong-orders-db
# 用 Terraform 建立的：先把 deletion_protection 與 deletion_protection_enabled 改成 false 並 apply，再執行
terraform destroy
# 最乾淨的做法：刪除整個練習專案
gcloud projects delete my-project-id範例裡的名稱都是示意，專案 ID 一律用 my-project-id 或 PROJECT_ID 佔位。不要下載服務帳戶金鑰檔；在自己的電腦上用 gcloud auth login 取得使用者憑證，在 CI/CD 或其他雲端用 Workload Identity Federation。應用程式連線建議用 Cloud SQL Auth Proxy 或 Cloud SQL 語言連接器，以 IAM 授權並自動加密。
📘 原理補完
五種「多一台資料庫」的正式定義
Cloud SQL 的可用性與擴充機制看起來都是「多開一台」，但每一種回答的問題不同。下表依 Cloud SQL 文件整理（查證時間 2026 年 10 月），判斷時先問：要防的是機器壞掉、可用區停擺、整個區域出事，還是讀取太多？
| 機制 | 複寫方式 | 能讀嗎 | 出事時 | 範圍 | 版本 | 主要用途 |
|---|---|---|---|---|---|---|
| 高可用（區域型執行個體） | 同步寫到兩個可用區的磁碟 | 待命機不能讀 | 自動容錯移轉，約 60 秒，IP 不變 | 同一區域 | Enterprise／Enterprise Plus | 撐過執行個體或可用區故障 |
| 讀取備用資源 | 非同步 | 唯讀 | 不會自動接手，要手動升級 | 同區域或跨區域，可串接 | 兩者皆可 | 分擔讀取 |
| 跨區域讀取備用資源 | 非同步 | 唯讀 | 手動升級成獨立主要執行個體，要改連線 | 另一個區域 | 兩者皆可 | 災難復原、當地就近讀取 |
| 讀取集區 | 非同步 | 唯讀，單一讀取端點 | 節點分散在各可用區 | 同一區域，1～20 個節點 | 只有 Enterprise Plus | 大量讀取、不想管多個端點 |
| 進階災難復原 | 非同步（DR 備用資源） | DR 備用資源可讀 | switchover（計畫性、不遺失）或 replica failover（緊急、可能遺失）；write endpoint 自動跟隨 | 跨區域 | 只有 Enterprise Plus | 區域等級災難復原、定期演練 |
版本差異也要記住：Enterprise 的 SLA 是 99.95%（不含維護時段）、交易記錄最多保留 7 天；Enterprise Plus 的 SLA 是 99.99%（含維護）、維護停機不到 1 秒、有 data cache，交易記錄預設 14 天、最多 35 天。SLA 只涵蓋設定高可用的執行個體（Enterprise Plus 另含兩個節點以上的讀取集區），共用核心機器、單一可用區執行個體與只有一個節點的讀取集區都不在保障範圍。PostgreSQL 16 以後的新執行個體，沒指定版本時預設是 Enterprise Plus。
容錯移轉時到底發生什麼事
高可用執行個體由主要與待命兩台組成，各自在一個可用區，寫入要同步寫到兩個可用區的磁碟才算完成。系統每秒送一次心跳檢查主要執行個體，連續幾次沒有回應就開始容錯移轉：待命機接手、改為對外服務，並沿用同一個固定 IP。這段期間執行個體約 60 秒無法使用，既有連線會斷，應用程式要能自動重試與重新連線；同步複寫的關係，已提交的交易不會遺失。不在故障可用區的讀取備用資源，會在待命機成為主要執行個體後連上它繼續複寫。想演練可以用 gcloud sql instances failover 手動觸發。
讀取備用資源、讀取集區：分擔讀取，不是自動備援
讀取備用資源是唯讀的執行個體，主要執行個體的變更會以接近即時的方式非同步送過去，所以讀到的資料可能比主要執行個體晚一點。它可以放在同一個區域分擔報表，也可以放在其他區域給當地使用者就近讀取；串接（cascading）讓備用資源底下再掛備用資源，連同主要執行個體最多四層，官方建議一個主要執行個體直接掛的備用資源不超過 10 個。備用資源不能設定備份，但可以另外開高可用。它最大的限制是不會容錯移轉：主要執行個體出事時，只能把它升級（promote）成獨立的主要執行個體，升級後複寫關係就斷了，連線位址也不同。Enterprise Plus 另有讀取集區：1～20 個讀取節點共用一個位址不變的讀取端點，節點輪流分散在區域內的可用區，應用程式不必自己管理一堆備用資源的位址，還能設定自動擴縮。
跨區域災難復原：手動升級與進階 DR
HA 只保護同一個區域。要撐過整個區域停擺，基本做法是在另一個區域建立跨區域讀取備用資源，災難時手動升級，並讓應用程式改連它；之後還要替新的主要執行個體開 HA、再建一個跨區域備用資源，原區域恢復後再規劃切回。Enterprise Plus 的進階災難復原把這件事變得可預期：指定一個直接連在主要執行個體下的跨區域備用資源當 DR 備用資源，平常可以做 switchover（主要執行個體先變唯讀，等 DR 備用資源追上再交換角色，不遺失資料，適合定期演練）；真正的區域故障時做 replica failover（立即升級 DR 備用資源，若有複寫延遲就可能遺失資料）。搭配 write endpoint 這個 DNS 名稱，它永遠解析到目前的主要執行個體，應用程式不必改連線字串。官方說跨區域容錯移轉的 RTO 與 RPO 是以分鐘計，而且因為非同步複寫，RPO 很可能不是零。
誤刪資料：靠自動備份與時間點復原
HA 與所有備用資源都會忠實複寫每一個變更，包括錯誤的 DELETE 或 DROP TABLE，所以「切到另一台」救不回資料。Cloud SQL 的自動備份每天在你指定的備份時段執行，保留的備份數可設 1～365 個（gcloud 的預設是 Enterprise 7 個、Enterprise Plus 15 個）；開啟時間點復原後，會另外保留交易記錄，讓你還原到保留期內的任一時間點。時間點復原一定會建立一個新的執行個體，不能覆寫原本那台；做法是先還原到出錯前一刻，確認資料後再搬回原執行個體或改連新執行個體。另外，刪除保護（deletion protection）防的是「整台執行個體被刪掉」，和資料表被誤刪是兩回事。
什麼時候不該硬撐 Cloud SQL：資料庫選擇
Cloud SQL 是單一區域、靠升級機器規格長大的標準引擎資料庫，寫入集中在一台主要執行個體。需求超出這個範圍時，換一個資料庫往往比堆疊備用資源更合適：要高效能 PostgreSQL、交易加即時分析或向量搜尋，看 AlloyDB for PostgreSQL；要水平擴充寫入、多區域強一致與最高 99.999% 的可用性，看 Spanner；行動或 Web App 的文件資料、即時同步與離線支援，看 Firestore；巨量時間序列與低延遲鍵值讀寫，看 Bigtable；次毫秒快取與工作階段，看 Memorystore；大量掃描的分析報表，交給 BigQuery。
| 資料庫 | 資料模型 | 擴充方式 | 可用性重點 | 不適合 |
|---|---|---|---|---|
| Cloud SQL | 關聯式（MySQL、PostgreSQL、SQL Server） | 升級機器規格；讀取靠備用資源 | HA 99.95%／Enterprise Plus 99.99% | 單機寫入撐不住、多區域強一致 |
| AlloyDB | PostgreSQL 相容 | 運算與儲存分離；讀取集區 | 主要執行個體預設跨可用區，99.99% | 需要 MySQL 或 SQL Server |
| Spanner | 關聯式、分散式 | 加節點或處理單元水平擴充讀寫 | Enterprise Plus 多區域最高 99.999% | 小型、預算有限、要原生引擎功能 |
| Firestore | 文件 | 無伺服器自動擴充 | 多區域設定 | 多表 JOIN、複雜報表 |
| Bigtable | 寬欄位 NoSQL | 加節點、自動擴縮 | 多叢集複寫 | 小資料量、需要 SQL 交易 |
| Memorystore | 記憶體鍵值 | 分片（Valkey、Redis Cluster） | 有複本的設定可自動容錯移轉 | 當作唯一的資料來源 |
| BigQuery | 分析倉儲（欄式） | 無伺服器 | 受管服務 | 毫秒級逐筆線上讀寫 |
判斷步驟
- 先確認資料庫選對了：分析交給 BigQuery，全球強一致看 Spanner，高效能 PostgreSQL 看 AlloyDB，其餘標準引擎用 Cloud SQL。
- 正式環境一律開高可用（區域型執行個體），主要與待命放在不同可用區；應用程式要能自動重連。
- 讀取太多：加讀取備用資源（放在和主要不同的可用區），Enterprise Plus 可用讀取集區；高可用的待命機分擔不了讀取。
- 要撐過區域故障：建立跨區域讀取備用資源並準備升級流程；需要可演練、不改連線字串的切換，用 Enterprise Plus 的進階 DR。
- 防誤刪：開自動備份與時間點復原，交易記錄保留期依需求選版本（Enterprise 最多 7 天、Enterprise Plus 最多 35 天）；再開刪除保護防止整台執行個體被刪。
- 連線安全：私人 IP、只允許加密連線，用 Cloud SQL Auth Proxy 或語言連接器加 IAM 資料庫驗證，密碼放 Secret Manager。
容易考錯的地方
高可用的待命機可以分擔讀取：不行。Cloud SQL 的 HA 待命機只為容錯移轉存在；要分擔讀取，加讀取備用資源或讀取集區。這是最常見的干擾選項。
讀取備用資源會自動接手：不會。讀取備用資源無法容錯移轉，只能手動升級；升級後是獨立執行個體、連線位址不同。需要自動切換的是 HA。
HA 可以當跨區域災難復原：不行，HA 的兩台都在同一個區域。整個區域故障要靠跨區域備用資源（Enterprise Plus 可用進階 DR 與 write endpoint）。
容錯移轉後要改連線字串：HA 容錯移轉沿用同一個 IP，不用改；升級跨區域備用資源才要改，進階 DR 則用 write endpoint 避免修改。
時間點復原會把原執行個體倒回去：不會，一定是建立新執行個體。干擾選項常寫「把原本的執行個體原地還原到 14:04」。
Enterprise 版本可以保留 30 天的交易記錄：不行，Enterprise 最多 7 天，要更長得用 Enterprise Plus（最多 35 天）。讀取集區與進階 DR 也只有 Enterprise Plus 有。
要全球多區域同時寫入就加更多 Cloud SQL 備用資源：備用資源都是唯讀的，寫入仍只在一台主要執行個體；這種需求是 Spanner。
相關考試：Associate Cloud Engineer（ACE）在「選資料庫產品」與「資料庫備份還原」點名 Cloud SQL；Professional Data Engineer（PDE）的 exam guide 點名 Cloud SQL、Spanner、Bigtable、Firestore、AlloyDB 等服務；Professional Cloud Database Engineer（PCDBE）以資料庫為主題，但 exam guide 沒有點名產品，這裡依領域推定相關。查證時間 2026 年 10 月。
✅ 自我檢測
6 題原創題，選完立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6