本文是 KeyDB overview 的 implementation-layer deep article。選型層（KeyDB vs Redis / DragonflyDB / Valkey、為何選 fork）見 overview；本文只處理「決定用 KeyDB active-active 後，衝突與一致性怎麼判」。命令實機驗證於 eqalpha/keydb image、最後檢查日 2026-06-16；複製機制以 KeyDB active-replication 文件 為準。

兩邊都能寫，聽起來太美好

Redis 的複製是單向的：一個 master 寫、replica 唯讀。要跨區讓兩邊都能就近寫入，Redis 本身做不到（得靠應用層分區或外部工具）。KeyDB 的 active-active 把這個限制拿掉——兩個（含以上）KeyDB 節點都是 master、都能接受寫入、互相把寫入同步給對方。對「兩個 region 都要低延遲寫入同一份 cache」的場景，這聽起來解決了所有問題。

問題藏在「兩邊同時寫同一個 key」的那一刻。active-active 沒有全域協調者來仲裁誰對誰錯，它用 last-write-wins（LWW）：比較兩筆寫入的時間戳，留下較晚的、默默丟掉較早的。多數時候沒事，但當兩個 region 在幾毫秒內各自更新同一個 key，其中一筆寫入會無聲消失——沒有錯誤、沒有日誌、application 以為自己寫成功了。

理解 KeyDB active-active 就是理解這個取捨：它用 LWW 換到了「兩邊都能寫」的可用性，代價是放棄了強一致與「不丟寫入」的保證。本文展開複製機制、衝突語意，以及哪些資料放得進這個模型、哪些放進去就是 bug。

核心概念：active-active 的複製與衝突語意

active-active 不是「分散式交易」，它是「雙向非同步複製 + LWW 衝突解決」。理解它要抓三個點：

每個節點都是 active-replica。一般 Redis replica 是唯讀的；KeyDB 的 active-replica 既接受本地寫入、又接收對方的複製流。兩個節點互相設定對方為 master，形成雙向複製環。實機看到的 role 就是 active-replica（不是 master / slave）。

複製是非同步的。本地寫入立即回 OK 給 client，之後才非同步傳給對方節點。這意味著兩個節點之間永遠有一個複製延遲窗口——在這個窗口內，兩邊看到的資料可能不同。這是 active-active 是 AP（可用性 + 分區容忍）而非 CP 的根本原因。

衝突用 last-write-wins 解決。同一個 key 在兩個節點被並發修改時，KeyDB 比較版本，保留較晚的寫入、丟棄較早的。沒有 merge、沒有 vector clock、沒有 application callback——就是比誰較晚。KeyDB 用 hybrid logical clock（HLC）排序、不是純 wall-clock，但 HLC 仍綁節點實體時鐘——時鐘不同步（clock skew）會直接影響哪一筆被判定為「較晚」。同步的是 key 的「值」不是「操作」，這也是為什麼並發 INCR 會互相覆蓋而非累加（見故障演練 Case 1）。

每筆寫入帶來源標記避免無限迴圈。A 的寫入同步給 B 後，B 不會再把它當成新寫入傳回 A（否則會無限循環）。KeyDB 用來源標記處理這個，但複製拓樸設計錯（例如環狀多節點）仍可能放大流量。

配置：兩節點 active-active 的設定路徑

實機驗證的最小雙主設定（兩個節點互相複製）：

1# 節點 A 與 B 都開 active-replica + multi-master
2docker run -d --name kdb-a --network kdbnet -p 6401:6379 \
3  eqalpha/keydb keydb-server --active-replica yes --multi-master yes
4docker run -d --name kdb-b --network kdbnet -p 6402:6379 \
5  eqalpha/keydb keydb-server --active-replica yes --multi-master yes
6
7# 互相指向對方（形成雙向複製）
8keydb-cli -p 6401 replicaof kdb-b 6379
9keydb-cli -p 6402 replicaof kdb-a 6379

實機驗證雙向同步（最後檢查日 2026-06-16）：

 1# 寫 A、讀 B
 2keydb-cli -p 6401 SET fromA hello   # → OK
 3keydb-cli -p 6402 GET fromA         # → hello   （A 的寫入同步到 B）
 4
 5# 寫 B、讀 A（雙向）
 6keydb-cli -p 6402 SET fromB world   # → OK
 7keydb-cli -p 6401 GET fromB         # → world   （B 的寫入同步到 A）
 8
 9# 確認 role 與複製鏈路
10keydb-cli -p 6401 INFO replication | grep -E "role|master_link_status|connected_slaves"
11# role:active-replica
12# master_link_status:up
13# connected_slaves:1

兩個節點都回報 role:active-replica（不是傳統的 master / slave），master_link_status:up 確認複製鏈路健康。寫入任一節點、另一節點都讀得到，這就是 active-active 的核心行為。

Production 故障演練

Case 1：並發寫同一 key、一筆寫入無聲消失

徵兆：兩個 region 的 application 各自更新同一個 user 的 cache（例如 profile），事後發現其中一個 region 的更新「沒生效」——但寫入時 application 收到的是 OK，沒有任何錯誤。

根因：active-active 的 LWW。兩筆寫入在複製延遲窗口內並發發生，KeyDB 比較時間戳保留較晚的、默默丟棄較早的。application 兩邊都以為自己寫成功了（本地確實 OK），但同步後只有一筆存活。

修法：

1. 不要讓同一個 key 被多個 region 並發寫——按 key 分區（user X 的寫入永遠路由到 region A），把多主退化成「就近讀 + 單點寫」
2. 真的需要多點寫的計數器類資料，用 CRDT 語意的結構（KeyDB 的 LWW 不適合 counter，並發 INCR 會互相覆蓋而非累加）
3. 接受 LWW 是 cache 的取捨——可重建的 cache 副本丟一筆寫入可回源重算，不可重建的資料不該放 active-active
4. 衝突無聲是最危險的——加應用層的寫入審計（不靠 KeyDB 告警）

Case 2：clock skew 讓「較晚」的判定錯亂

徵兆：明明 region B 後寫的值，最後存活的卻是 region A 先寫的值——LWW 的「後寫者勝」失效。

根因：LWW 比較時間戳，但兩個節點的系統時鐘若沒同步（clock skew），「較晚」的判定就錯了。B 的時鐘慢了 200ms，B 後寫的值帶的時間戳反而比 A 早，被判定為「較舊」丟棄。

修法：

1. 所有 KeyDB 節點強制 NTP 時鐘同步，把 skew 壓到毫秒級
2. 監控節點間的時鐘偏差，skew 超過複製延遲就有 LWW 判定錯亂風險
3. 對時間敏感的衝突，LWW 本質不可靠——時鐘永遠無法完美同步，這是 LWW 模型的固有弱點
4. 需要正確衝突解決的場景，不要用 LWW 的 active-active，改強一致儲存

Case 3：複製延遲下的 stale read

徵兆：region A 寫入後，立刻有請求打到 region B 讀同一 key，讀到舊值；幾百毫秒後再讀才是新值。

根因：active-active 是非同步複製，A 的寫入要經過網路傳到 B 才可見。在這個複製延遲窗口內，B 讀到的是 stale 值。跨 region 的延遲窗口比同 AZ 大得多。

修法：

1. 寫後需要立即一致讀的路徑，讀同一個寫入的節點（read-your-writes 綁定到寫入 region）
2. 監控節點間複製延遲，跨 region 的延遲是 stale window 的下界
3. 接受最終一致——這是 active-active 的本質，cache 場景多數可容忍短暫 stale
4. 不可容忍 stale 的資料不適合 active-active，走單寫入點 + 跨區唯讀 replica

Case 4：複製拓樸設計錯、流量放大或迴圈

徵兆：加了第三個 active 節點組成環狀後，節點間流量異常放大、CPU 升高，甚至同一筆寫入被反覆傳遞。

根因：active-active 多節點（> 2）的拓樸需要小心設計。全互連（full mesh）下每筆寫入要傳給所有其他節點、流量隨節點數平方成長；環狀拓樸若來源標記處理不當可能放大傳遞。

修法：

1. 多節點 active-active 優先用 full mesh 但控制節點數（active-active 不適合大量節點）
2. 監控節點間複製流量，異常放大代表拓樸或來源標記問題
3. 大規模多區優先考慮「每區單寫入點 + 跨區唯讀」而非全 active-active
4. active-active 的甜蜜點是 2-3 個區的雙向就近寫，不是大規模 mesh

Case 5：節點重連後的全量重同步衝擊

徵兆：一個節點短暫斷線後重連，重連瞬間 CPU / 網路尖峰，期間延遲升高。

根因：節點斷線時間過長、超過複製 backlog 能覆蓋的範圍，重連時要做全量重同步（full resync）——對方節點要產生快照（fork、見 Redis persistence 的 fork 成本，KeyDB 繼承 Redis 的 fork 機制）並傳輸整個 dataset。

修法：

1. 設足夠大的 repl-backlog-size，讓短暫斷線走部分同步（partial resync）而非全量
2. 重同步的 fork 成本跟記憶體 headroom 相關，節點要留 fork 空間
3. 監控 master_link_status，頻繁 down / up 代表網路不穩、要先修網路
4. 跨 region 的 active-active 對網路穩定性敏感，不穩的鏈路會頻繁觸發重同步

Capacity / cost 邊界

active-active 的容量判讀，核心在衝突率與複製健康：

撞牆後的路由判斷：

• 需要正確的衝突解決 / 不能丟寫入：LWW 不保證，走強一致儲存（database 模組 的 multi-region 一致性方案）或單寫入點架構。
• 需要 counter / 累加語意的多點寫：LWW 會讓並發 INCR 互相覆蓋，KeyDB active-active 不適合，改 CRDT 或單點 counter。
• 跨 region 但可接受單寫入點：用 Redis / Valkey 的單向複製（一區寫、其他區唯讀），比 active-active 簡單且無衝突。
• 大規模多區：active-active 的甜蜜點是 2-3 區，更大規模走 managed 的跨區方案（ElastiCache Global Datastore 的 active-passive）。

整合 / 下一步

active-active 是 KeyDB 區別於 Redis 的核心能力之一，但它的取捨跨多個子系統：

• 跟 KeyDB overview：overview 點到 active-active 是 last-write-wins、本文展開它什麼時候默默丟資料。
• 跟 Redis persistence / fork latency：KeyDB 繼承 Redis 的 fork 機制，節點重連的全量重同步付 fork 成本。
• 跟 cache copy boundary：active-active 的 stale window 與 LWW 丟寫入，本質是「cache 副本的新鮮度與一致性邊界」議題的多主版本。
• 跟 Snap KeyDB cross-cloud case：Snap 用 KeyDB 的主因是 cross-cloud latency 治理（cache 與 application 共置），active-active 的雙向就近寫是這類 multi-cloud 場景的工具，但要按 key 分區避開 LWW 衝突。

相關連結

• 上游 vendor 頁：KeyDB
• 對照 vendor：DragonflyDB 多核架構、Redis Sentinel failover（單向複製的 HA）
• 上游概念：2.7 cache copy boundary
• Methodology：Vendor 深度技術文章寫作方法論

本文是 Kafka overview「Replication 與 exactly-once 升級」段的 implementation-layer deep article。Overview 已給出 partition / replication 的選型定位、本文展開 寫入承諾 跟 處理語義 兩條獨立軸線怎麼設、邊界在哪、成本是什麼。對應反例 3.C9 Queue 語義誤配。

寫入承諾與處理語義是兩條獨立軸線

Kafka 的可靠性拆成兩個彼此正交的問題、混在一起談是多數誤配的起點。第一條軸線是 寫入承諾：一筆訊息寫進 broker 後、在多少 replica 落地才算「成功」、broker 掛掉時這筆訊息會不會消失。這條軸線由 replication factor、ISR、acks 與 min.insync.replicas 共同決定、屬於 broker 端的耐久性保證。第二條軸線是 處理語義：同一筆訊息在 producer 重送、consumer 重啟、partition rebalance 等情境下、會不會被寫進去兩次或被處理兩次。這條軸線由 producer idempotence、transaction 與 consumer 端的 commit 設計決定、屬於端到端的正確性保證。

兩條軸線可以獨立調整：可以有「寫入承諾很強但處理語義是 at-least-once」的配置（acks=all + 非冪等 consumer）、也可以有「寫入承諾較弱但已開冪等」的配置。把 exactly-once 當成單一開關去找、是因為沒看出這兩條軸線存在。本文先講第一條（replication / ISR / acks）、再講第二條（idempotence / transaction）、最後談兩者疊起來能達成什麼、達不成什麼。

這個拆分對映 delivery semantics 與 idempotency 兩張知識卡：前者描述 broker 承諾的送達次數、後者描述處理端怎麼讓「送達多次」不等於「生效多次」。

ISR：誰算「跟得上」的副本

ISR（in-sync replica、同步副本集）是一個 partition 當前「跟得上 leader」的 replica 集合、是 Kafka 把 replication factor 這個 靜態配置 轉成 動態保證 的關鍵概念。Replication factor = 3 只說明這個 partition 有 3 份 replica；但任一時刻真正跟得上 leader 的可能只有 2 份或 1 份。ISR 就是這個「當前實際同步」的集合、寫入承諾的判斷都基於 ISR、不是基於 replication factor。

一個 follower 留在 ISR 內的條件是：它在 replica.lag.time.max.ms（預設 30 秒）內持續向 leader 拉取資料、且追上 leader 的 log end offset。當 follower 因為 broker 慢、網路抖動、GC 停頓或 disk 壓力而落後超過這個時間窗、leader 會把它移出 ISR — 這就是 ISR shrink（收縮）。當它恢復、重新追上、再被加回 ISR — 這是 ISR expand（擴張）。

ISR 收縮本身不是故障、是 Kafka 對「這個 follower 暫時不可信」的誠實表態。真正的風險在於：ISR 收縮到某個程度後、acks=all 的寫入承諾會無法滿足 min.insync.replicas 而開始拒絕寫入。下一段的 acks 取捨直接建立在 ISR 這個概念上。

實機看 ISR 的方式是 kafka-topics.sh --describe、Isr 欄位列出當前同步的 broker id：

1# RF=3、min.insync.replicas=2 的 topic、三 broker 都同步時
2kafka-topics.sh --describe --topic repl-demo --bootstrap-server kafka1:9092
3# Topic: repl-demo  PartitionCount: 1  ReplicationFactor: 3  Configs: min.insync.replicas=2
4#   Topic: repl-demo  Partition: 0  Leader: 2  Replicas: 2,3,1  Isr: 2,3,1

Replicas 欄位是 配置上 的 3 份副本、Isr 欄位是 當前實際同步 的集合。兩者一致代表健康；Isr 比 Replicas 短代表有副本落後。日常巡檢用 kafka-topics.sh --describe --under-replicated-partitions 直接列出 Isr 短於 Replicas 的 partition。

acks 與 min.insync.replicas：寫入承諾的兩個旋鈕

寫入承諾由 producer 端的 acks 跟 broker / topic 端的 min.insync.replicas 共同決定、兩者必須一起設才有意義。acks 決定 producer 在收到「成功」回應前、要等多少 replica 確認；min.insync.replicas 決定 broker 在 ISR 不足時是否拒絕寫入。前者是 producer 的等待策略、後者是 broker 的拒絕底線。

acks 三個值對應遞增的耐久性與遞增的延遲成本：

acks=0 適用「丟一兩筆無所謂」的場景、例如高頻 metric 上報、log shipping 的非關鍵層。它把網路往返成本壓到最低、代價是 producer 完全不知道 broker 有沒有收到。任何牽涉金流、訂單、狀態變更的訊息都不該用 acks=0。

acks=1 是一個容易被誤以為安全的中間值。它只等 leader 寫入本地、不等 follower 同步。多數時候運作正常、但存在一個明確的資料遺失窗口：leader 回了成功、follower 還沒拉到這筆訊息、此時 leader 所在 broker 崩潰、新 leader 從 follower 中選出 — 那筆「已回成功」的訊息在新 leader 上不存在、producer 卻以為寫成功了。這個窗口在正常運行時很窄、但在 broker 滾動重啟、硬體故障、AZ 中斷時會被放大。

acks=all 是耐久性配置的正解、但只有搭配 min.insync.replicas ≥ 2 才完整。單獨設 acks=all、若 min.insync.replicas=1、那麼當 ISR 收縮到只剩 leader 一份時、acks=all 等同 acks=1 — 「所有 ISR 確認」這個條件在 ISR 只剩 1 份時形同虛設。min.insync.replicas=2 補上這個漏洞：它要求 ISR 至少有 2 份才接受 acks=all 寫入、否則直接拒絕、把「靜默遺失」轉成「明確拒絕」。

min.insync.replicas 是 topic-level 可動態調整的配置、不需重啟 broker：

1# 動態調整單一 topic 的 min.insync.replicas
2kafka-configs.sh --alter --topic repl-demo \
3  --add-config min.insync.replicas=2 \
4  --bootstrap-server kafka1:9092
5
6# 查當前值、synonyms 會顯示 topic override 蓋過 broker default
7kafka-configs.sh --describe --topic repl-demo --bootstrap-server kafka1:9092
8# min.insync.replicas=2 synonyms={DYNAMIC_TOPIC_CONFIG:min.insync.replicas=2,
9#   DYNAMIC_DEFAULT_BROKER_CONFIG:min.insync.replicas=1, DEFAULT_CONFIG:min.insync.replicas=1}

RF=3 + acks=all + min.insync.replicas=2 是業界對「不能丟資料」topic 的標準三件組：3 份副本提供冗餘、acks=all 要求同步確認、min.insync=2 在容忍一台 broker 掛掉的同時仍保證每筆寫入落在至少兩份 replica。容忍度的算術是 RF - min.insync.replicas：3 - 2 = 1、代表可以掉一台 broker 仍正常寫入、掉兩台則寫入被拒（但已寫入的資料不丟）。

Producer idempotence：去掉重送造成的重複

Producer idempotence（冪等生產者、enable.idempotence=true）解決的是 producer 重送 造成的 broker 端重複。它讓「producer 因為沒收到 ack 而重送同一筆訊息」這件事、在 broker 端被去重、不會寫進兩筆。這是處理語義軸線的第一塊、獨立於前面的寫入承諾。

問題的根源是：producer 送出訊息後、若因網路超時沒收到 broker 的 ack、它無法分辨是「訊息沒送到」還是「訊息送到了但 ack 在回程丟了」。預設行為是重送。在沒有冪等保護時、若實際是後者、broker 就收到兩筆相同訊息、partition 裡出現重複。

冪等機制的做法是給每個 producer 分配一個 producer ID（PID）、並為每個 partition 維護一個遞增的 sequence number。Broker 記住每個 (PID, partition) 已接受的最大 sequence；重送的訊息帶相同 sequence、broker 認出是重複、直接丟棄並回成功。這個保證的範圍是 單一 producer session 內、單一 partition 的精確一次寫入。

開啟方式是 producer 端設 enable.idempotence=true。在較新版 Kafka 這已是預設值、且它會隱含要求 acks=all、retries > 0、max.in.flight.requests.per.connection ≤ 5 — 因為冪等去重依賴這些前提。冪等的成本極低（broker 多維護 PID/sequence 的少量 metadata）、幾乎沒有理由關閉。

需要明確的邊界是：冪等只覆蓋 同一個 producer session。Producer 重啟後拿到新的 PID、broker 無法把新舊 session 的訊息關聯起來。跨 session 的去重、以及「寫多個 partition 要嘛全成功要嘛全失敗」的需求、要靠下一段的 transaction。

Kafka transaction 與 read_committed：跨 partition 的原子寫入

Kafka transaction（交易）解決的是 跨多個 partition 的原子寫入 與 consume-process-produce 的原子提交。它讓一組寫入（可能跨多個 topic / partition）以及對應的 consumer offset commit、要嘛全部對下游可見、要嘛全部不可見。這是處理語義軸線的第二塊、建立在冪等之上。

典型場景是 stream processing 的 consume-process-produce 迴圈：consumer 讀入一批訊息、處理後產出結果寫到另一個 topic、然後 commit 讀取進度。若這三步不是原子的、崩潰時可能出現「結果已產出但 offset 沒 commit」（重啟後重複處理、重複產出）或「offset 已 commit 但結果沒寫成功」（訊息遺失）。Transaction 把「產出結果」跟「commit offset」綁成一個原子操作、消除這個窗口。

啟用 transaction 需要 producer 設一個穩定的 transactional.id、並在程式碼中走完整的 transaction 生命週期：

1producer.initTransactions()      // 向 transaction coordinator 註冊、fence 掉舊 session
2producer.beginTransaction()
3  producer.send(record1)          // 跨多個 topic/partition 的寫入
4  producer.send(record2)
5  producer.sendOffsetsToTransaction(offsets, groupMetadata)  // consumer 進度也納入交易
6producer.commitTransaction()      // 全部原子提交；失敗則 abortTransaction()

transactional.id 提供跨 session 的 fencing（隔離）：同一個 transactional.id 的新 producer 啟動時、coordinator 會 fence 掉舊的、避免「殭屍 producer」在崩潰後復活還繼續寫。這是冪等的 PID 機制做不到的跨 session 保證。

實機限制：kafka-console-producer.sh 帶 --producer-property transactional.id=... 不會自動呼叫 initTransactions()、會直接報 IllegalStateException: Cannot add partition ... before completing a call to initTransactions。完整 transaction 生命週期只能在 client code 中驗證、無法用 console 工具演示。本文的 transaction 行為描述依官方 producer API 語義、生命週期程式碼未經本地 client 實機跑通。

Transaction 的另一半在 consumer 端：isolation.level=read_committed。預設的 read_uncommitted 會讀到尚未 commit、甚至最終被 abort 的 transactional 訊息。設成 read_committed 後、consumer 只會看到已 commit 的 transactional 訊息、abort 的訊息對它不可見、未 commit 的訊息會被擋在 last stable offset（LSO）之前等待。

1# consumer 以 read_committed 隔離級別讀取、只看已 commit 的 transactional 訊息
2kafka-console-consumer.sh --topic repl-demo --from-beginning \
3  --isolation-level read_committed \
4  --bootstrap-server kafka1:9092

需要注意：對非 transactional 的普通訊息、read_committed 跟 read_uncommitted 行為相同 — 普通訊息一律可見。隔離級別只對 transactional 訊息產生差異。這也是為什麼若上游沒有任何 transactional producer、把 consumer 改成 read_committed 不會有任何可觀察的效果。

端到端 exactly-once 的邊界與成本

端到端 exactly-once 的意思是：訊息從 producer 到 consumer 處理結果、整條路徑上「不重不漏」。它由前面所有零件疊出來、但有明確的適用邊界、不是萬用保證。

Kafka 原生能提供 exactly-once 的範圍是 Kafka-to-Kafka 的封閉迴圈：consume from Kafka、process、produce to Kafka、commit offset、整個用 transaction 綁定。Kafka Streams 框架把這套封裝成 processing.guarantee=exactly_once_v2 一個配置、底層就是 transaction + 冪等 + read_committed 的組合。在這個封閉迴圈內、exactly-once 是真實成立的。

邊界出現在 離開 Kafka 的那一刻。當處理結果要寫進外部系統（資料庫、HTTP API、第三方服務、寄信、扣款）、Kafka 的 transaction 管不到外部系統的提交。一筆訊息「已扣款但 offset commit 前崩潰」這種跨系統不一致、Kafka transaction 無法消除 — 它只保證 Kafka 內部的原子性。跨系統的 exactly-once 要靠外部系統自己的冪等鍵（idempotency key）、或 outbox pattern、或兩階段提交、由應用層補上、不是 Kafka 送的。

成本方面、exactly-once 不是免費的耐久性升級：

務實的判斷是：先確認需求真的是 exactly-once、還是「at-least-once + 下游冪等」就夠。多數業務（包括金流）用 at-least-once 送達 + 下游用業務冪等鍵去重、就達到了「效果上不重複」、且吞吐與複雜度成本遠低於完整 transaction exactly-once。完整的 Kafka transaction exactly-once 留給 Kafka-to-Kafka 的 stream processing pipeline、那是它的甜蜜點。這個取捨對映 3.6 processing-recovery-semantics 對「在哪一層放冪等」的判讀。

故障演練

可靠性配置的價值在故障時才顯現。以下演練在 3-broker KRaft 叢集（RF=3、min.insync.replicas=2）上跑、用停 broker 製造 ISR 收縮、觀察各配置的真實行為。

ISR 收縮到低於 min.insync.replicas 時 acks=all 被拒

演練：起 3-broker 叢集、建 RF=3 / min.insync.replicas=2 的 topic、初始 ISR = 三台全在。依序停掉兩個 follower broker、觀察 ISR 收縮、再用 acks=all produce。

初始狀態（ISR 三份全在、acks=all 正常）：

1Topic: repl-demo  Partition: 0  Leader: 2  Replicas: 2,3,1  Isr: 2,3,1
2# acks=all produce → exit=0

停一個 follower（broker 3）、ISR 收縮到 2 份、仍滿足 min.insync=2：

1Topic: repl-demo  Partition: 0  Leader: 2  Replicas: 2,3,1  Isr: 2,1
2# acks=all produce → exit=0（ISR=2 仍 >= min.insync=2、寫入接受）

再停一個 follower（broker 1）、ISR 收縮到只剩 leader 1 份、低於 min.insync=2：

1# acks=all produce → broker 拒絕：
2[Producer] Got error produce response ... Error: NOT_ENOUGH_REPLICAS, retrying
3org.apache.kafka.common.errors.NotEnoughReplicasException:
4  Messages are rejected since there are fewer in-sync replicas than required.

判讀：這正是 min.insync.replicas 的設計意圖在運作。ISR 不足時、broker 選擇 明確拒絕寫入（NOT_ENOUGH_REPLICAS）、而不是降級成 acks=1 默默接受。對 producer 而言、寫入失敗會觸發 retry、retry 耗盡後拋例外、上游應用感知到「現在寫不進去」、可以 fail-fast 或 backpressure — 而不是寫了一筆只在單一 broker 上、隨時可能隨那台 broker 一起消失的「假成功」訊息。把資料遺失轉成可觀測的寫入拒絕、是這個配置的全部目的。

恢復：重啟兩個 broker、ISR 自動 expand 回三份、acks=all 恢復接受寫入：

1Topic: repl-demo  Partition: 0  Leader: 2  Replicas: 2,3,1  Isr: 1,2,3

附帶觀察：在 KRaft 模式下、controller 也是 quorum（本演練三台都兼任 controller）。同時停掉兩台、controller quorum 失去多數、kafka-topics.sh --describe 對 metadata 的查詢會 timeout（DisconnectException）。production 叢集應把 controller 數量與 broker 故障域分開規劃、避免 broker 故障連帶打垮 metadata 平面。

Unclean leader election 的取捨

當一個 partition 的所有 ISR replica 都不可用、只剩一個 曾經落後、已被踢出 ISR 的 replica 還活著、Kafka 面臨一個無法兩全的選擇。unclean.leader.election.enable=false（預設）會選擇 不選 leader：這個 partition 進入不可用狀態、拒絕讀寫、直到某個 ISR replica 恢復。unclean.leader.election.enable=true 會選擇 把那個落後的 replica 提為 leader：partition 立刻恢復可用、代價是那個 replica 上缺失的訊息（leader 掛掉前已 commit 但它還沒同步到的部分）永久遺失。

判讀：這是一個 可用性 vs 耐久性 的直接取捨、沒有正確答案、只有對映業務的選擇。對金流、訂單、審計這類「丟一筆都不行」的 topic、保持 false、寧可 partition 短暫不可用也不接受靜默資料遺失。對 metric、log、可重算的衍生資料、開 true 換可用性、丟幾筆可接受。預設 false 是合理的安全預設、但要意識到它的代價是「所有 replica 都不在 ISR 時、partition 會卡住不可用」、這在多 broker 同時故障時會發生。

Idempotent producer 對重送去重

演練：producer 開 enable.idempotence=true、acks=all、模擬 ack 丟失導致的重送。

判讀：冪等開啟後、producer 因網路超時重送的訊息帶相同 (PID, partition, sequence)、broker 認出 sequence 重複、丟棄重送並回成功、partition 內不出現重複。實機上 enable.idempotence=true 的 produce 寫入正常（exit=0）、消費端讀回的訊息數等於實際送出的邏輯訊息數、重送不放大。要記住的邊界仍是：這只覆蓋單一 producer session；producer 重啟換 PID 後、跨 session 的重複要靠 transaction 或下游冪等鍵處理。

Transaction 中途失敗的 read_committed 隔離

演練：transactional producer 在 beginTransaction 後寫入若干訊息、然後 abortTransaction（模擬處理中途失敗）；consumer 分別用 read_uncommitted 與 read_committed 讀取。

判讀：read_committed 的 consumer 看不到被 abort 的訊息 — 中途失敗的 transaction 對它等於沒發生過、不會讀到「處理一半的髒資料」。read_uncommitted 的 consumer 則會讀到這些最終被 abort 的訊息、若據此處理就產生了不該發生的副作用。這是 transaction 隔離的核心價值：把「transaction 失敗」的可見性控制在 commit 邊界內。

本段的 abort 行為依官方 transaction 語義描述。本地以 kafka-console-consumer.sh --isolation-level read_committed 驗證了隔離級別參數可用、且對已 commit 的普通訊息 read_committed 與 read_uncommitted 輸出一致（普通訊息一律可見、隔離級別只對 transactional 訊息產生差異）；完整的 begin/abort transaction 生命週期需 client code、未用 console 工具跑通。

Capacity / cost

各配置的容量與成本影響、決定它適用的規模與 topic 類別：

務實 default：

• 業務 topic 一律 RF=3 + acks=all + min.insync.replicas=2、idempotence 預設開
• 容忍度算術 RF - min.insync.replicas 要 ≥ 1、否則單台 broker 維護就會中斷寫入
• 完整 transaction exactly-once 只給 Kafka-to-Kafka pipeline；跨系統用 at-least-once + 下游冪等鍵
• unclean.leader.election 保持 false、除非該 topic 明確可丟資料換可用性

整合 / 下一步

跟 processing-recovery-semantics 對位

寫入承諾保證訊息留在 broker、但 處理 的不重不漏在 consumer 端。3.6 processing-recovery-semantics 展開 consumer 的 commit 時機、崩潰恢復的 replay 範圍、以及「冪等放在哪一層」的判讀 — 跟本文的 transaction exactly-once 邊界互補：本文界定 Kafka 能送什麼、那篇界定處理端怎麼接才不放大重複。

跟 event-contract-replay-boundary 對位

Exactly-once 的封閉迴圈假設訊息格式穩定、replay 可重現。3.7 event-contract-replay-boundary 展開 schema 演進與 replay 邊界 — 當 transaction 提供的原子性遇上 schema 變更、replay 舊訊息的可重現性會受 contract 影響、是 exactly-once 在時間維度上的延伸限制。

對應反例 3.C9

3.C9 Queue 語義誤配 是本文兩條軸線混淆的真實後果：broker 遷移後「名稱上相近的 delivery semantics」在失敗重播時產生不同結果、出現重複扣款與狀態漏更新。判讀路徑正是本文的拆分 — 先確認是寫入承諾（acks / ISR）還是處理語義（idempotence / commit 時機）出問題、不要用 queue depth 這種寫入承諾層的指標去判斷處理語義層的故障。

對應案例 3.C21 Goldman Sachs MSK 遷移

3.C21 Goldman Sachs MSK 遷移 揭露遷移時可靠性配置的細節風險集中在 client 端的 timeout / flush / LB 配置、而非 broker 本身。本文的 acks=all 在 ISR 不足時拒絕寫入、若 client 端的 retry 與 timeout 沒對齊（如 flush timeout 太短）、會把「broker 正常的 backpressure」誤判成「遷移失敗」。可靠性配置與 client 容錯參數要一起驗證。

下一步路由

• 上游概念：delivery semantics、idempotency 知識卡
• 同 vendor：Kafka overview 的 producer / consumer 設計段
• 下游能力：3.6 processing-recovery-semantics、3.7 event-contract-replay-boundary、6.12 idempotency / replay
• 方法論：Vendor 深度技術文章的寫作方法論

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 replication topology — 從 single primary 到 multi-replica 部署的 3 個 trade-off 軸跟 5 段配置。

Replication 的 3 個 trade-off 軸 + mode 選擇

Replication mode 選擇看起來是「選 async 還是 semi-sync」、但決策實際是 3 個獨立 trade-off 軸的權衡、async / semi-sync 是這些軸的兩個常見組合 名稱：

「async vs semi-sync」實際上是 durability + latency 兩軸 的選擇、不影響 consistency 軸（consistency 在 read routing 層決定）。Group Replication / MySQL Cluster（synchronous multi-primary）會同時改三軸、是另一個故事、不在本文 scope。

跟這三軸獨立的、是 replication 機制本身的可維護性。binlog position-based replication 用 (file, position) 標 replica 進度、failover 時要對齊 position 容易出錯；GTID（Global Transaction Identifier）用全域 transaction ID 標進度、failover / re-pointing 不必算 position。GTID 是 跨 mode 的 infrastructure、不是第三種 mode。

Async replication：default + 高 throughput 的代價

Async 是 MySQL 預設、行為：

1. Primary 寫 binlog、立刻 commit、回應 client OK
2. Replica 的 IO thread 從 primary pull binlog event 到 local relay log
3. Replica 的 SQL thread apply relay log（單 thread 或 multi-thread parallel）

Trade-off：

• Durability：primary 寫完 commit、replica 還沒 pull = primary 在這瞬間 crash + 永久故障 → data loss（已 commit 的 transaction 在 replica 不存在）
• Latency：client 不等 replica、寫入延遲 = primary 自身寫 binlog 的時間（通常 < 1ms with innodb_flush_log_at_trx_commit=1）
• Consistency：replica 可能 lag、application 讀 replica 會 stale；用 SHOW SLAVE STATUS 看 Seconds_Behind_Master

適用：

• 主流選擇（90% 場景）
• Failover loss 在容忍範圍（多數 web 應用容忍 1-2 秒 data loss）
• Read scaling 為主要 driver、絕對 durability 非首要

不適用：

• 金融交易 / 訂單系統、不允許 any data loss
• Compliance 要求 zero data loss（PCI-DSS / 部分監管場景）

Semi-sync replication：至少一個 standby ack 才 commit

Semi-sync 在 async 基礎上加 primary 等至少 N 個 replica ack 才 commit 的步驟：

1. Primary 寫 binlog
2. Primary 發送 binlog event 到所有 replica
3. Primary 等至少 N 個 replica 回 ack（N 是 rpl_semi_sync_master_wait_for_slave_count、預設 1）
4. Primary commit、回應 client

Trade-off：

• Durability：至少 N 個 replica 收到 binlog（不一定 apply）、primary crash 後 replica 還有 binlog 可 promote、保證 zero data loss（但是 binlog-level、不是 applied-level）
• Latency：client 等 primary + 一輪 replica ack RTT；跨 AZ 通常 +1-3ms、跨 region 可能 +50-200ms
• Consistency：跟 async 一樣、replica apply 仍 async、application 讀 replica 仍可能 stale

MySQL 5.7+ 區分 standard 跟 Loss-Less semi-sync：

• Standard semi-sync（5.5-5.6）：primary 先 commit 再等 ack、ack 超時 fallback 成 async — 仍可能 lose data
• Loss-Less semi-sync（5.7+、rpl_semi_sync_master_wait_point=AFTER_SYNC）：primary 寫完 binlog 但 先等 ack 再 commit、ack 超時 fallback async 之前已寫 binlog 仍保證 durable

Production 場景必須用 Loss-Less semi-sync、不是 standard。

適用：

• 金融交易 / 訂單 / payment ledger
• 不允許 data loss、可接受寫入延遲 +1-3ms
• 已有 multi-AZ / multi-region 部署、replica 物理上可靠

不適用：

• 跨 region semi-sync（RTT 50-200ms）通常不划算 — 寫吞吐砍半、改用 region-local sync replica + cross-region async chain
• 寫吞吐 > 50K WPS 且容忍 sub-second loss — async 即可

GTID-based replication：機制升級、跨 mode 都需要

GTID 把每個 transaction 標一個全域 ID：<server_uuid>:<transaction_id>。Replica 紀錄「已 apply 的 GTID set」、不再用 (binlog_file, position)。

為什麼 GTID 比 binlog position 好：

• Failover re-pointing 簡單：promote 新 primary 後、其他 replica 重新 attach 不必算 MASTER_LOG_FILE + MASTER_LOG_POS、用 CHANGE MASTER TO MASTER_AUTO_POSITION=1 即可
• Multi-source replication 可行：一個 replica 從多個 primary 拉、各 primary 的 GTID set 獨立 track
• Consistency check 容易：兩個 server 對 GTID set、就知道誰落後、有無 gap
• 跟 group replication / MySQL Cluster 必需：5.7+ 多 primary 場景 GTID 是前提

設定流程（兩階段、不能直接開）：

1. Phase 1 (預備、所有 server 同 mode)：

   1gtid_mode = ON_PERMISSIVE  -- 接受 GTID 跟 non-GTID transaction
   2enforce_gtid_consistency = ON  -- 拒絕無法用 GTID 表達的 statement（CREATE TABLE...SELECT 等）

2. Phase 2 (rolling、全部 server 都 Phase 1 後)：

   1gtid_mode = ON  -- 只接受 GTID transaction

跳 phase 直接 gtid_mode=ON 會讓 replication break（既有 non-GTID transaction 無法處理）。Production 啟用 GTID 要排 maintenance window、跑完 phase 1 觀察 1-2 天再進 phase 2。

配置 step-by-step（Loss-Less semi-sync + GTID 組合）

實務最常見組合：Loss-Less semi-sync + GTID。配置順序：

Step 1：Primary + replica 都開 GTID（兩 phase 跑完）

1# my.cnf on primary AND replica
2gtid_mode = ON
3enforce_gtid_consistency = ON
4log_bin = mysql-bin
5log_slave_updates = 1  -- replica 也記 binlog (chained replication 需要)
6binlog_format = ROW    -- ROW 比 STATEMENT 安全
7sync_binlog = 1        -- 每次 commit fsync binlog
8innodb_flush_log_at_trx_commit = 1  -- 每次 commit fsync InnoDB log

Step 2：Primary 安裝 semi-sync plugin

1INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
2SET GLOBAL rpl_semi_sync_master_enabled = 1;
3SET GLOBAL rpl_semi_sync_master_wait_for_slave_count = 1;  -- 至少 1 個 ack
4SET GLOBAL rpl_semi_sync_master_wait_point = AFTER_SYNC;   -- Loss-Less
5SET GLOBAL rpl_semi_sync_master_timeout = 10000;           -- 10s timeout、超時 fallback async

Step 3：Replica 安裝 semi-sync plugin

1INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
2SET GLOBAL rpl_semi_sync_slave_enabled = 1;
3STOP SLAVE IO_THREAD;
4START SLAVE IO_THREAD;  -- 重啟 IO thread 啟用 semi-sync

Step 4：Replica attach primary

1CHANGE MASTER TO
2  MASTER_HOST='primary.example.com',
3  MASTER_PORT=3306,
4  MASTER_USER='repl',
5  MASTER_PASSWORD='...',
6  MASTER_AUTO_POSITION=1;  -- 用 GTID auto-position
7START SLAVE;

Step 5：驗證

 1-- Primary: 確認 semi-sync 啟用 + 有 active client
 2SHOW STATUS LIKE 'Rpl_semi_sync_master_status';      -- ON
 3SHOW STATUS LIKE 'Rpl_semi_sync_master_clients';     -- ≥ 1
 4SHOW STATUS LIKE 'Rpl_semi_sync_master_yes_tx';      -- > 0 (有 transaction 走 semi-sync)
 5SHOW STATUS LIKE 'Rpl_semi_sync_master_no_tx';       -- 應該 = 0 (沒有 fallback 成 async)
 6
 7-- Replica: 確認 GTID + IO thread 正常
 8SHOW SLAVE STATUS\G
 9-- Slave_IO_Running: Yes
10-- Slave_SQL_Running: Yes
11-- Retrieved_Gtid_Set: 跟 primary Executed_Gtid_Set 接近
12-- Seconds_Behind_Master: 觀察 lag

5 個 Production 踩雷

1. Replication lag 暴衝 — 單 SQL thread bottleneck

預設 replica 的 SQL thread 是 單 thread apply、primary 多 thread 寫入時 replica 跟不上、lag 從 < 100ms 飆到分鐘級。常見觸發：批次 UPDATE / DELETE、大 transaction、index rebuild。

修法：

• 啟用 multi-thread replication：slave_parallel_workers = 8（per database 或 per logical clock parallel）
• 5.7+ 用 slave_parallel_type = LOGICAL_CLOCK：依 primary 上的 group commit 並行度自動 parallel
• 8.0+ 的 writeset-based parallel：binlog_transaction_dependency_tracking = WRITESET、更細粒度並行

監控：Seconds_Behind_Master 是 表面指標、實際看 Executed_Gtid_Set 跟 primary 對比的 GTID gap 更準。

2. Semi-sync timeout fallback 成 async（沒監控就看不見）

rpl_semi_sync_master_timeout 預設 10000ms（10 秒）、超時後 自動 fallback async、直到 replica 重連。Application 視角看不到任何 error、但 durability guarantee 已失效。

修法：

• 監控 Rpl_semi_sync_master_status — fallback 後變 OFF
• 監控 Rpl_semi_sync_master_no_tx — fallback 期間每個 transaction 都計數
• Alert 規則：5 分鐘內 no_tx 增加 > 0 即告警
• Timeout 設太短（< 5s）容易 false positive、設太長（> 30s）crash 時 data loss 風險增

3. GTID gap — replica 無法 attach

Replica 重新 attach primary 時報 ERROR 1236: ... transactions you need from master are purged、原因是 primary 的 binlog_expire_logs_seconds 過短、需要的 binlog 已被清掉。GTID 模式下這個錯誤更明顯（直接看 GTID gap）、但 binlog position 模式下也一樣。

修法：

• binlog_expire_logs_seconds = 604800（7 天）作為 baseline
• 大流量 server 確認 disk 容量能撐 7 天 binlog（一個高峰小時 binlog 可能 GB 級）
• 真的 gap 太大時用 base backup + replay binlog 重建 replica、不要硬 reset GTID

4. Loss-Less semi-sync 不一定真的 loss-less

AFTER_SYNC 模式 primary 寫 binlog → 等 ack → commit、看起來 zero loss。但 primary 寫完 binlog 還沒等 ack 時 crash + replica 剛好沒收到那個 binlog event + replica promote — 這個 binlog event 在新 primary 不存在、但舊 primary 的 binlog 仍紀錄為 已寫 binlog 未 commit。client 收到 connection lost、不知道 transaction 是否成功。

修法：

• 接受這個 edge case unknown state、application 用 idempotency key + retry 處理
• Loss-Less semi-sync 保證的是 已 commit transaction 不會丟、不是 所有寫入都 ack-and-tell
• 真的 zero unknown state 需要 group replication / Galera Cluster / MySQL Cluster（synchronous multi-primary）

5. Chained replication 雪崩

Topology 是 primary → replica1 → replica2 → ...（hub-and-spoke 之外的選擇、節省 primary 出口頻寬）。Replica1 SQL thread 卡住、replica2 跟 replica3 都被 block、整條 chain 雪崩。

修法：

• 避免超過 2 層 chain（primary → tier1 replica → tier2 replica 是上限）
• 用 parallel binary log relay（5.7+ slave_pending_jobs_size_max + parallel workers）讓 chain 中段不阻塞
• 規模真的大、改用 binlog server（如 Maxwell / MaxScale）解耦 chain dependency
• 跨 region 用 region-local hub + cross-region async、不是長 chain

容量 / cost 對照

跨 AZ semi-sync 通常加 1-3ms、跨 region 加 50-200ms — 寫密集 workload 跨 region semi-sync 通常不划算、改用 region-local sync + cross-region async chain。

整合 / 下一步

Aurora MySQL

Aurora MySQL 用 AWS-managed storage layer、storage 自動 replicate 6 份跨 3 AZ、不需要應用層配 semi-sync。從自管 MySQL 遷 Aurora 時、上方所有 semi-sync 配置 消失、改成 Aurora storage quorum（4 of 6 write、3 of 6 read）。

trade-off 軸的 durability 完全交給 Aurora、application 只關心 latency + consistency。詳見 Aurora vendor page。

Vitess（sharding layer）

Vitess shard 內部仍用 MySQL replication（async or semi-sync）、Vitess 不取代 replication topology、是 上層 routing。Vitess vttablet 每個 shard 有自己的 primary + replica、跟本文 topology 設計一致。

Vitess 比較大議題在 cross-shard transaction（VReplication 跨 shard binlog stream）、不是 replication topology — 詳見 MySQL backlog 中 Vitess sharding 設計 篇（待寫）。

ProxySQL（read replica routing）

ProxySQL 是 MySQL 生態的 connection pool + query routing 標準、按 query type（SELECT vs DML）跟 replica lag 自動 route。寫入路 primary、讀走 replica、replica lag > N 秒時暫時退路 primary 維持 consistency。

ProxySQL 跟本文 replication topology 是 互補不重疊 — replication 設定哪些 server 有什麼資料、ProxySQL 設定 query 怎麼分配。詳見 MySQL backlog 中 ProxySQL 配置 篇（待寫）。

Orchestrator（HA failover）

Orchestrator 是 MySQL HA topology 管理 + 自動 failover 工具、用 GTID 偵測 replica 進度、failover 時自動 promote 最新 replica。對比 PostgreSQL 的 Patroni（詳見 Patroni HA）— 兩者角色相同、Orchestrator 需要 GTID + 對 MySQL 行為熟、Patroni 需要 DCS（etcd / Consul）+ 對 PG 行為熟。

詳見 MySQL backlog 中 Orchestrator failover 設計 篇（待寫）。

CDC（Maxwell / Debezium）

Maxwell（Zendesk 出品、MySQL-only）跟 Debezium（Red Hat、MySQL / PG / MongoDB 都支援）都讀 MySQL binlog 轉成 event stream（Kafka / Kinesis / Pulsar）。Binlog 必須 ROW format、GTID 啟用後 exactly-once delivery 更好維護（不需算 binlog position）。

跟 PG logical replication + Debezium 對比、MySQL 用 binlog（physical / row-level）不是 logical decoding、所以 schema change 時 CDC consumer 要 schema-aware 處理。詳見 MySQL backlog 中 Binary log + Maxwell / Debezium CDC 篇（待寫）。

相關連結

• MySQL vendor overview
• PostgreSQL Replication Topology（PG sibling、streaming + LSN + slot 機制 vs MySQL binlog 對位）
• PostgreSQL Patroni HA（PG sibling、不同 HA 機制）
• PostgreSQL Logical Replication + Debezium（PG CDC sibling、不同 replication 抽象層）
• PostgreSQL Replication Slot Management（PG slot 治理、MySQL 無對應概念）
• Aurora vendor page（managed MySQL、replication 交給 storage layer）
• 1.3 Transaction Boundary（transaction 行為跟 replication 互動）
• 1.10 KV / Document DB 容量規劃 / 1.11 全球分散式 OLTP（替代路徑）
• quorum 卡片 / eventual consistency 卡片 / stale read 卡片
• 官方：MySQL Replication / Semi-Sync / GTID

本文是 PostgreSQL overview 的 implementation-layer deep article。Overview 已說明 PG 在 OLTP 譜系的定位、本文聚焦 streaming replication topology — 從 single primary 到 multi-standby 部署的 3 個 trade-off 軸 + LSN + replication slot 機制。

Replication 的 3 個 trade-off 軸 + mode 選擇

PG streaming replication mode 選擇看起來是「async 還是 sync」、實際是 3 個獨立 trade-off 軸的組合、async / sync / quorum-based sync 是這些軸的常見組合 名稱：

跟這三軸獨立的、是 replication 機制本身的可維護性：

• LSN（Log Sequence Number）：PG 用全域 byte offset 標 WAL 進度、所有 standby 同步用 LSN 對齊、不像 MySQL 早期 binlog position + file 雙欄
• Replication slot：primary 紀錄每個 standby 已接收的 LSN、防 standby 失聯期間 WAL 被清掉、是 streaming replication 的 持久化進度追蹤

跟 MySQL Replication Topology 對比、PG 的 LSN + replication slot 直接內建 standby 進度追蹤、不像 MySQL 5.7- 要靠 binlog position + GTID 雙機制；但 slot 是 primary 紀錄、orphan slot 是 PG-specific 議題（slot 留 WAL 直到 standby 重連、standby 永久失聯 → primary disk 爆）。

Async streaming：default + 高 throughput 的代價

Async 是 PG 預設、行為：

1. Primary 寫 WAL 進 pg_wal/ 目錄、commit、回應 client OK
2. WAL sender process 把 WAL stream 給 standby
3. Standby WAL receiver 寫 standby 的 pg_wal/、startup 進程 redo 套用

Trade-off：

• Durability：primary commit 後 standby 還沒收 → primary 永久故障 → data loss（已 commit 的 transaction 在 standby 不存在）
• Latency：client 寫入延遲 = primary 自身 fsync WAL 的時間（fsync=on + synchronous_commit=on 預設、通常 < 1ms 在 SSD / NVMe）
• Consistency：standby 可能 lag、application 讀 standby 會 stale；用 pg_stat_replication.write_lag / flush_lag / replay_lag 看

配置：

1# postgresql.conf on primary
2wal_level = replica          # 至少 replica（logical 是 superset）
3max_wal_senders = 10         # 並行 WAL sender process 數（依 standby 數量）
4wal_keep_size = 1024MB       # WAL 保留量（slot 為主、但 backup buffer）
5synchronous_commit = on      # 預設、primary 自己 fsync WAL
6# synchronous_standby_names 留空 = async

適用：

• 主流選擇（90% 場景）
• Failover loss 在容忍範圍（多數 web 應用容忍 1-2 秒 data loss）
• Read scaling 為主要 driver、絕對 durability 非首要

Sync streaming：至少一個 standby flush WAL 才 commit

Sync mode 在 async 基礎上加 primary 等指定 standby flush WAL 才回 client：

1. Primary 寫 WAL、send to standby
2. Standby 收到 WAL、寫進 pg_wal/、fsync、回 ack
3. Primary 等 ack → commit → 回 client

synchronous_commit 有 5 個 level、不是 binary：

配置（synchronous）：

1synchronous_commit = on
2synchronous_standby_names = 'FIRST 1 (standby1, standby2)'
3# 'FIRST 1' = 第一個 active standby ack 即可
4# 'ANY 2 (s1, s2, s3)' = 任 2 個 ack 即可（quorum-based）

Quorum-based sync：用 ANY N 語法、達到 N 個 ack 就 commit、提高 latency stability（不依賴特定 standby）：

1synchronous_standby_names = 'ANY 2 (standby1, standby2, standby3)'
2# 3 個 standby 中任 2 個 ack 即 commit

適用：

• 金融交易 / 訂單 / payment ledger（不允許 data loss）
• 已有 multi-AZ deploy、replica 物理上可靠
• 可接受寫入延遲 +1-3ms (跨 AZ)

不適用：

• 跨 region sync（RTT 50-200ms）— 寫吞吐砍半、改用 region-local sync + cross-region async
• 寫吞吐 > 50K WPS + 容忍 sub-second loss — async 即可

LSN + Replication Slot：PG 的進度追蹤機制

PG 每個 WAL 寫入都標 LSN（64-bit byte offset）。Standby 紀錄 已收到 / 已 flush / 已 replay 的 LSN、primary 透過 streaming protocol 知道每個 standby 進度。

Replication slot 是 primary 端的 standby 進度紀錄：

1-- 建 physical replication slot（給 streaming replication 用）
2SELECT * FROM pg_create_physical_replication_slot('standby1_slot');
3
4-- 查 slot 狀態
5SELECT slot_name, active, restart_lsn, confirmed_flush_lsn,
6       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS lag
7FROM pg_replication_slots;

Slot 的核心責任：

• 防 WAL premature deletion：standby 失聯（restart / network blip）、primary 仍保留 slot 對應 LSN 之後的 WAL、standby 重連可繼續 stream
• 無需 base backup re-build：跟沒 slot 的 standby 對比、有 slot 的 standby 失聯後重連、不用重建

Slot 跟 wal_keep_size：

• wal_keep_size（PG 13+）/ wal_keep_segments（< 13）：minimum WAL 保留量、不依賴 slot
• Slot 是 動態保留：直到 slot 的 standby 推進 LSN 才釋放對應 WAL
• 兩者組合：wal_keep_size 是底線、slot 是 standby-specific 動態保留

Standby 配置（用 slot）：

1# standby1 postgresql.conf
2primary_conninfo = 'host=primary.example.com port=5432 user=replication password=...'
3primary_slot_name = 'standby1_slot'   # 用 primary 上預先建的 slot
4hot_standby = on                       # 讓 standby 接受 read query

standby.signal 空檔案在 PG_DATA 內、告訴 PG 這是 standby、進入 recovery mode。

配置 step-by-step（sync streaming + slot）

實務最常見組合：sync streaming + replication slot + cross-AZ replica。

Step 1：Primary 配置

 1# postgresql.conf
 2wal_level = replica
 3max_wal_senders = 10
 4max_replication_slots = 10
 5synchronous_commit = on
 6synchronous_standby_names = 'FIRST 1 (standby1, standby2)'
 7wal_keep_size = 1024MB
 8
 9# pg_hba.conf — 允許 replication 連線
10host replication replication 10.0.0.0/16 scram-sha-256

Restart primary 套用。

Step 2：建 replication user + slot

1CREATE USER replication WITH REPLICATION PASSWORD '...';
2SELECT * FROM pg_create_physical_replication_slot('standby1_slot');
3SELECT * FROM pg_create_physical_replication_slot('standby2_slot');

Step 3：Standby base backup

1# 在 standby 上跑
2pg_basebackup -h primary.example.com -D /var/lib/postgresql/data \
3  -U replication -P -X stream \
4  -S standby1_slot -R
5# -R: 自動生成 standby.signal + primary_conninfo
6# -X stream: 邊 backup 邊 stream 增量 WAL（避免 backup 期間 WAL gap）

Step 4：Standby 啟動

1# standby /var/lib/postgresql/data/postgresql.auto.conf 已有：
2# primary_conninfo = 'host=primary.example.com user=replication password=... application_name=standby1'
3# primary_slot_name = 'standby1_slot'
4
5pg_ctl -D /var/lib/postgresql/data start

Step 5：驗證

1-- Primary: 確認 standby 連上
2SELECT application_name, state, sync_state, write_lag, flush_lag, replay_lag
3FROM pg_stat_replication;
4-- 應顯示 standby1 / streaming / sync / 各 lag
5
6-- Standby: 確認在 recovery + 收到 WAL
7SELECT pg_is_in_recovery(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();

5 個 Production 踩雷

1. Standby lag 暴衝 — Single replay process bottleneck

PG standby 是 single startup process 套用 WAL（不像 MySQL multi-thread replication）、primary 高並發寫入時 standby 跟不上、lag 從 < 100ms 飆到分鐘級。常見觸發：批次 UPDATE / DELETE、大 transaction、index 建立、autovacuum 大量 dead tuple cleanup。

修法：

• Parallel WAL apply（PG 14+）：max_parallel_workers_per_gather 增加 background worker、但仍受 startup process 主導
• 對 read scaling 場景接受 standby lag、application 用 primary read 對 latency-critical query
• Cascading replication 對 high-fan-out 解決 sender CPU bottleneck、但 standby replay 仍 single-thread

監控：pg_stat_replication.replay_lag 是 最後一個 commit 到 standby replay 的時間差、超過 threshold 即告警。

2. Sync standby 失聯時 primary commit 卡住

synchronous_standby_names = 'FIRST 1 (standby1)' + standby1 down → primary commit 等永遠。Application 全部 timeout。

修法：

• 用 ANY N quorum：synchronous_standby_names = 'ANY 1 (standby1, standby2)' — 任一 standby ack 即可
• 設多 standby、防單一失聯
• 監控 sync standby 健康、自動 failover 切 sync mode 到其他 standby（Patroni 自動做）
• 緊急情況：在 primary 跑 ALTER SYSTEM SET synchronous_standby_names = ''; SELECT pg_reload_conf(); 暫時退 async（接受 data loss risk）

3. Orphan replication slot — Primary disk 爆

Standby 失聯（永久故障 / 重 decommission 但忘了 drop slot）、primary slot 持續保留 WAL、pg_wal/ 累積到 disk 滿、primary 也掛。

修法：

• 監控 pg_replication_slots.active — false 持續 > N 小時是警訊

• 監控 slot lag：

  1SELECT slot_name, active,
  2       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
  3FROM pg_replication_slots WHERE retained_wal > 10GB;

• 設 max_slot_wal_keep_size（PG 13+）— slot 對應 WAL 超過 limit 自動 invalidate slot（standby 之後要 base backup 重來）

• DR runbook 紀錄 standby 退役流程 必須包含 pg_drop_replication_slot('xxx')

4. Cascading replication 雪崩

Topology primary → standby1 → standby2 → ...（每層遞迴 stream）。Standby1 startup process 卡住、後續 standby 都被 block、整條 chain 雪崩。

修法：

• 避免超過 2 層 cascade（primary → tier1 → tier2 是上限）
• 跨 region 用 region-local tier1 + cross-region tier2、不是長 chain
• 真的大規模、改用 binlog server style：Citus / PgCat 等中介、或 logical replication 解耦

5. Failover 後 timeline 分歧

Primary 失敗、standby1 promote 為新 primary、其他 standby（standby2 / 3）原本連舊 primary、必須重新連 standby1。但 PG 用 timeline（每次 promotion 增 1）標 WAL 分支、原 standby 的 timeline 跟新 primary 不同。重連時看到 timeline mismatch、報錯。

修法：

• pg_rewind 工具：對比新 primary 跟舊 standby 的 timeline 分歧點、把舊 standby 上 新 primary 沒有的 WAL 倒退、然後從分歧點重新跟新 primary 同步
• Base backup re-build：對舊 standby 重建 — 慢但保證乾淨
• Patroni 自動處理 pg_rewind / base backup 選擇

容量 / cost 對照

跨 AZ sync 通常加 1-3ms、跨 region 加 50-200ms — 寫密集 workload 跨 region sync 通常不划算、改用 region-local sync + cross-region async chain。

整合 / 下一步

Patroni HA

Patroni 是 PG HA 自動 failover 標準、依賴 DCS（etcd / Consul）+ 本文 replication topology。Patroni 自動：

• 偵測 primary 失聯、promote 適合 standby
• 處理 timeline 分歧（pg_rewind）
• 重配 sync standby（避免 sync standby 失聯卡 primary）

Logical Replication + Debezium

Logical replication + Debezium 是 跟 streaming replication 共用 WAL 但不同 abstraction — logical decoding output event、streaming replication output physical bytes。Logical replication slot 跟 physical slot 共存、各自獨立 retention。

PITR + WAL Archiving

PITR + WAL Archiving 用 archive_command 把 WAL ship 到 S3、跟 streaming replication 並行：

• Streaming：給 活的 standby（real-time read scaling / HA）
• Archive：給 PITR + 新 standby base backup source

兩者使用同一 WAL stream、不衝突。

Connection 路由（PgBouncer + read/write split）

PgBouncer 不做 read/write split（transaction pool 不看 SQL）。Read replica routing 通常用 application-level 或 HAProxy 監控 standby health。

跟 MySQL Replication Topology 對比

兩者 high-level 對等、低層機制有顯著差異。詳見 MySQL Replication Topology。

相關連結

• PostgreSQL vendor overview
• PG Patroni HA（HA failover、依賴本文 replication topology）
• PG Logical Replication + Debezium（不同 abstraction、共用 WAL）
• PG PITR + WAL Archiving（streaming + archive 並行）
• PG PgBouncer（connection pool、不做 read/write split）
• MySQL Replication Topology（sibling、不同機制）
• quorum 卡片 / stale-read 卡片 / eventual-consistency 卡片
• 官方：PG Streaming Replication / pg_basebackup

本文不是 Aurora overview（請看 Aurora vendor 頁）— 而是 storage-level 設計的實作層教學。覆蓋 quorum-based replication 的工程含義、「韌性即性能」frame 為什麼成立、OLTP workload 在 storage 設計下的讀寫雙峰錯位、跟容量規劃的判讀槓桿。

問題情境

典型觸發場景：團隊從 RDS PostgreSQL / 自管 PostgreSQL 遷到 Aurora、看到「跨 AZ replication lag 從秒級降到毫秒級」、但讀文件「quorum」「4-of-6」「分散式 storage」訊息密集、不知道哪些設計決策要相信、哪些是 marketing 詞。

讀者常見的具體疑問：

• 「為什麼 Aurora 寫入比 RDS 還低、不是該因為跨 AZ network round-trip 而變慢？」
• 「Storage layer 跟 compute layer 分離具體怎麼影響 backup、failover 跟 read replica？」
• 「6 個 storage node 失去 2 個還能寫嗎？失去 3 個呢？」
• 「Aurora 文件講『韌性』跟『性能』都用 storage 設計解釋、是同一件事還是兩件事？」

進一步問題：傳統工程文化把可靠性跟性能視為對立 — HA 投資（跨 AZ replication、failover 演練）通常被當成性能成本、不被視為性能來源。Aurora 設計反這個直覺、但讀者需要看到具體機制才能信。Standard Chartered case 揭露這個 frame 在受監管銀行業務（要求兩者同時達標）的價值；DraftKings 揭露具體數字（讀 < 1ms、寫 6ms）。

核心機制：quorum-based 分散式 log

Aurora storage 的 first-class concept 是 quorum 寫入 + 6-way 跨 AZ replication。傳統 PostgreSQL primary 把 storage 跟 CPU / RAM 綁定、storage 擴容要換 instance、replication 在 compute 層做（streaming replication、logical replication）。Aurora 把 storage 拉到分散式 log service、6 個 storage node 各自獨立、application 看到的仍是 single primary SQL。

Storage layout：每個 storage segment 跨 3 AZ × 2 node、共 6 個 storage node。一個 cluster 的 storage 被切成多個 10GB segment、每個 segment 6-way 複製。

Quorum 設定：

• Write quorum：4-of-6（4 個 storage node 確認寫入才算 commit）— 容忍 1 AZ 失效 + 1 node 失效仍能寫
• Read quorum：3-of-6（讀 3 個 node 取最新版本）— 比 write 小、降低 read latency
• 算術不對稱：寫嚴讀鬆是設計選擇、不是 marketing — durability 由寫端保證、讀端可以放寬

Write path 跟傳統 PostgreSQL 的差異：

• PostgreSQL primary：寫 WAL 到 local disk + dirty page flush + 透過 streaming replication 推到 replica
• Aurora compute node：只送 redo log records 到 storage、不送整個 page；storage node 自己 apply redo log 重建 page、自己 checkpoint、自己 backup
• 工程含義：compute node 寫量小、CPU 不被 dirty page flush 佔用、寫入路徑變短

「韌性即性能」frame（9.C14 Standard Chartered 揭露）：

Aurora 把 HA 從 application-level（Patroni promotion + WAL catch-up）下推到 storage-level。設計含義是：storage 投資（6-way 跨 AZ replication）自動成為 read replica 的容量基底 — read replica 不需要 catch-up WAL、直接從共享 storage 讀、HA 預算同步轉成讀分流預算。

對 Standard Chartered 受監管銀行業務這代表：合規要求的 RPO / RTO 不能放棄、但業務也要求每秒 4000 TPS、兩者必須同時達成。傳統路徑要分別投資 HA（複雜的 streaming replication topology）跟性能（read replica catch-up tuning）、且兩個投資互相干擾。Aurora 讓 同一份 storage 投資 同時提供兩件事 — case「判讀」段第 2 點原話：「Aurora 的多 AZ storage + replica 同時提供性能（讀分流）跟韌性（故障切換）、達成 韌性即性能 的目標」。

對應 knowledge card：quorum、replication-lag。

跟通用 quorum 概念差在哪：Aurora quorum 是 storage-level（不是 application-level Cassandra 風格）、application 看到 single primary SQL、不用感知 quorum；vs Cassandra application 要選 consistency level（ONE / QUORUM / ALL）。

OLTP workload shape：讀寫雙峰錯位

Aurora 設計的工程含義在 application 層落地時、要看 workload 形狀。9.C4 DraftKings 揭露一個 OLTP 容量規劃的典型 pattern。

DraftKings 揭露的雙峰錯位（case「觀察」段最後一行原文）：「write workloads spike up significantly around payout events, but opening the app during the game also activates a lot of balance queries」— 比賽進行時是讀爆量（balance query）、payout event 時是寫爆量（ledger write）、兩個峰不在同一時刻。

工程含義：

• 讀寫資源規劃要分開、不能用「峰值總 TPS」單一數字規劃容量
• 讀峰拉 read replica 容量、寫峰靠 primary instance class 跟 commit batching、兩條路徑獨立預配
• 預估 headroom 也要分開：讀的 headroom 可以靠 auto-scale replica 接、寫的 headroom 要靠 primary 提前升 instance class（不能 auto-scale）

Application-level boundary：雙峰錯位是 application 層 拆讀寫 datasource 的決策訊號、storage layer 本身不解。Aurora 共享 storage 提供 lag 上限可預測（10-30ms）— 這是 read replica 變成「production-grade 可用」的前提、但讀寫分流要 application 端拆 read / write data source 才能落地。Storage 設計給的是「可預測的 lag 上限」、不是「自動讀寫分離」。

跨 case 對照：

9.C28 FanDuel 揭露另一種雙峰 — 直播 + 投注 兩種服務 同時峰、不是同服務讀寫錯位。這兩種雙峰類型要分清楚：

• 同服務讀寫錯位（DraftKings）：解法是 read / write data source 拆分、共享 Aurora cluster
• 跨服務雙峰（FanDuel）：解法是不同服務各自獨立擴容、betting 走 Aurora、streaming 走 CDN

雙峰類型不同、容量規劃策略不同。

Step-by-step 配置 / 觀測

Aurora storage 是 cluster-level、不暴露 segment-level config。讀者能影響的維度是 instance class、storage type、backup retention 跟 monitoring。

Cluster 建立：

1aws rds create-db-cluster \
2  --db-cluster-identifier my-cluster \
3  --engine aurora-postgresql \
4  --engine-version 15.5 \
5  --master-username admin \
6  --master-user-password "$(aws secretsmanager get-secret-value --secret-id db-password --query SecretString --output text)" \
7  --storage-type aurora-iopt1 \
8  --backup-retention-period 7

關鍵欄位：

• --storage-type aurora-iopt1：Aurora I/O-Optimized、月費高 30% 但無 I/O 收費；write-heavy + scan-heavy workload 才划算
• --storage-type aurora（預設）：Standard storage、按 I/O 計費；read-light workload 划算
• --backup-retention-period 7：1-35 天、影響 PITR 範圍

觀測 storage 狀態：

1aws rds describe-db-clusters \
2  --db-cluster-identifier my-cluster \
3  --query 'DBClusters[0].{StorageType:StorageType,AllocatedStorage:AllocatedStorage,Status:Status}'

CloudWatch metric（cluster-level）：

1VolumeBytesUsed           # 當前 storage 用量、接近 128 TB 上限要警告
2VolumeReadIOPs            # storage 層讀 IOPS、判斷 I/O-Optimized ROI
3VolumeWriteIOPs           # storage 層寫 IOPS、跟 compute 層 WriteIOPS 對照
4AuroraVolumeBytesLeftTotal # 剩餘可用 storage

Performance Insights wait event：

1db.IO.aurora_redo_log_flush   # quorum write 等待訊號、p99 > 10ms 要看
2db.IO.aurora_storage_xx       # storage layer I/O 細節

驗證點：

• 寫入 latency p99：PostgreSQL primary 1-3ms vs Aurora 3-6ms、跨 AZ network round-trip 是物理下界
• Read latency p99：Aurora < 1ms（從共享 storage 讀、不跨 AZ）
• Storage autoscale event：128 TB 上限前自動 grow per 10GB

Rollback boundary：Aurora storage 是 cluster-level、無法回滾 storage 設計；唯一 rollback 是切回 RDS / 自管（走 migration playbook、不是配置層 rollback）。

故障模式 / 邊界 case

Case 1：誤以為 Aurora 寫入一定比 PostgreSQL primary 快

徵兆：團隊期待 Aurora 寫入比自管 PostgreSQL 快、實測 p99 寫入 latency 沒明顯改善、甚至小 row + 單筆 commit 場景 Aurora 反而慢。

原因：跨 AZ network round-trip 是 3-5ms 物理下界、4-of-6 quorum 至少要等 4 個 storage node ack、單筆小寫場景 local SSD primary 仍有 latency 優勢。Aurora 的寫入優勢在 壓力下 才顯現 — write throughput 高峰時 PostgreSQL primary 受限於 dirty page flush + WAL fsync + replica catch-up、Aurora 的 storage layer 各自獨立處理 redo log apply。

數字口徑：「跨 AZ round-trip 3-5ms」屬通用工程估算（光速下界 + AWS 區內 AZ 物理距離）、case 未直接量化、實際值依 region / AZ pair / instance 類型而異、要看 AWS 官方 latency table 或自家 benchmark 校正。下方 DraftKings 6ms 寫入是 case 揭露的 production reference、可作為對照基線。

修：

• benchmark 要跑壓力測試、不能只測單筆 latency
• 寫入 latency 不是 Aurora 的核心賣點、是 可預測的 read replica lag + 韌性 才是
• DraftKings 6ms 寫入是 production reference：跨 AZ quorum 的物理下界、不是 Aurora 慢

Case 2：AZ-level outage 期間寫入 latency spike

徵兆：1 個 AZ 失效後、寫入 p99 從 6ms spike 到 30-50ms、application timeout 增加。

原因：失去 1 AZ 後 quorum 仍成立（4-of-6 → 用剩 4 個 node 寫）、但 storage node fault 期間需要等 timeout 才確認；單一 storage node 額外 fault 會把寫推到 timeout。Aurora 在 AZ outage 期間 能寫、但不是 性能不變。

修：

• 監測 AuroraVolumeBytesLeftTotal 跟 storage IOPS 分布、AZ outage 期間自動切到剩餘 AZ
• application 端做 retry + circuit breaker、不要假設寫入永遠 6ms
• 確認 cluster 至少跨 3 AZ deploy、單 AZ outage 才有 quorum 餘地

Case 3：I/O-Optimized 費用誤判

徵兆：team 看 Aurora I/O-Optimized「無 I/O 收費」直接切過去、月帳變高 25%、沒看到 ROI。

原因：Standard storage 按 I/O 收費、I/O-Optimized 月費比 Standard 高 30%。只有 write-heavy + scan-heavy workload（I/O 月費接近 instance 費用）才划算；read-light + write-light workload 反而吃虧。

修：

• 先量測 baseline I/O：VolumeReadIOPs + VolumeWriteIOPs × $0.20 per million I/O vs Standard 月費
• I/O 費用 > instance 費用 30% 才切 I/O-Optimized
• DraftKings 用 I/O-Optimized 是因為金融帳本 write-heavy + balance query scan-heavy、ROI 明顯

Case 4：Storage autoscale 假設

徵兆：TRUNCATE / DROP 大表釋放 50% storage、但下月帳單沒回落。

原因：Aurora storage 自動 grow、但 不自動 shrink。已分配的 storage 持續計費、TRUNCATE / DROP 只釋放 logical space、physical storage 仍占用。要 shrink 必須走 logical migration（dump / restore 到新 cluster）。

修：

• 大量 DROP 操作前先評估是否值得做 logical migration
• 用 partition + DETACH 而非 DROP TABLE、partition 可以單獨 archive
• 接受 storage 用量是 peak watermark 而非 current usage

Case 5：Replication lag 誤解

徵兆：read replica lag 10-30ms 看起來夠快、application 假設 read-after-write consistency、用戶下注後立刻查 balance 偶發看到舊資料。

原因：10-30ms 是 typical、heavy write + slow query 期間可能秒級。Aurora 共享 storage 設計讓 lag 可預測（不會像 PostgreSQL streaming replication unbounded）、但 可預測 不等於 zero。Read-after-write 場景仍需要 application 端處理。

修：

• 用戶寫操作後 N 秒內走 primary（N 由 lag p99 決定、典型 100ms）
• Aurora 提供 session pinning：寫完同 session 短期內走 primary
• 不能假設「Aurora replication lag 小到可以忽略」、要看 application 容忍度

容量與觀測

核心 metric：

1VolumeBytesUsed           # storage 用量、128 TB 上限預警
2AuroraReplicaLag          # replica lag、判斷讀寫分流可行性
3db.IO.aurora_redo_log_flush # quorum write 等待、storage 瓶頸訊號

Production reference number（9.C4 DraftKings 揭露、case「觀察」段表格）：

這個 production reference 取代用「typical 3-5ms」籠統說法。讀寫 6x 差距是 OLTP 容量規劃槓桿 baseline — 寫延遲是 quorum 4-of-6 + 跨 AZ network round-trip 的物理下界、不是 storage 設計能再壓低。引用時要明示是 DraftKings production reference、不是 Aurora marketing。

容量上限：

• 128 TB / cluster（超過要拆 cluster、見 Aurora read replica scaling fleet 治理 SSoT）
• 15 read replica / region（Aurora read replica scaling 展開）
• Storage 自動 grow per 10GB

跨 region replication：Aurora Global Database 用 AuroraGlobalDBReplicationLag 監測、< 1 秒 typical。

回路徑：4.20 Observability Evidence Package 抽 CloudWatch evidence、9.5 瓶頸定位流程 判斷 storage-bound vs compute-bound。

Netflix +75% 效能改善的根因

9.C23 Netflix consolidation 案例揭露 storage 設計的具體效能含義。Netflix 把多套 RDBMS（PostgreSQL / MySQL / Oracle）統一到 Aurora、拿到 up to 75% 效能改善、-28% 成本。

+75% 的根因：

• 傳統 PostgreSQL primary 寫 WAL + dirty page flush + 透過 streaming replication 推到 replica
• Compute 大量 CPU 用在 dirty page flush + replication encoding、不是用在 query processing
• Aurora compute 只送 redo log records、storage 自己 apply page、自己 checkpoint
• → 同樣 instance class 下、Aurora compute 能處理更多 query

這不是 marketing 的「分散式儲存讓效能提升」籠統說法、而是具體的 compute 不再 flush dirty page。

scope warning（必明示、case 自帶警示原話）：

「effective 75% improvement 是跨多 workload 的最大改善幅度、不是『每個 workload 都 +75%』。實際每個 workload 改善幅度從 10% 到 75% 不等」（case「需要警惕」段第 1 點）。

引用 Netflix 時不能把 75% 套到單一 workload — 容量規劃要看自家 workload 形狀（write-heavy / read-heavy / scan-heavy）、預估改善幅度範圍而非單一數字。

Fleet 治理（cross-link、不展開）

Production scale 不是「單一巨型 Aurora cluster」而是 fleet of clusters — 5 case 揭露同一 frame：

• DraftKings 200 個獨立 cluster（按業務切分）
• Netflix 多 cluster（微服務私有 store）
• Standard Chartered 7 個 cluster（受監管市場 boundary）

跨 case 合成的 fleet 拓樸 3 條 driver（business sharding / microservice ownership / 合規市場 boundary）跟「何時拆 cluster vs 加 replica」的判讀順序、SSoT 在 Aurora read replica scaling 邊界段。Storage 設計本身不解 fleet 邊界決策 — Aurora 解 single-cluster scaling（quorum / 共享 storage / 共享 backup）、但「拆幾個 cluster」是業務拓樸決策。

邊界與整合 / 下一步

Sibling deep articles：

• Aurora cross-AZ failover RTO — storage 設計如何加速 failover（replica 不需要 catch-up）
• Aurora read replica scaling — 共享 storage 為什麼能養 15 replica + fleet 治理 SSoT
• Aurora Global Database — 跨 region storage replication 設計

Migration playbook：

• PostgreSQL / MySQL → Aurora — storage 設計差是 operational redesign 的核心 driver

1.x 章節互引：

• 1.3 Transaction Boundary — quorum 寫入 vs single-primary transaction 邊界
• 1.11 全球分散式 OLTP — Aurora storage 是 single-region scaling、不是 distributed SQL

何時不用本文：single-region OLTP 用 RDS 仍足夠、storage architecture 細節不影響容量規劃時可跳過、看 Aurora vendor overview 即可。

相關連結

• Aurora vendor overview — 服務定位、適用 / 不適用場景
• Quorum 卡片 — 概念基底
• Replication Lag 卡片 — 對照通用 replication lag 模型
• Vendor 深度技術文章方法論 — 本文遵循的 6 規格面寫作模板
• 官方：Aurora storage architecture

本文不重複 MongoDB vendor overview 已寫過的 replica set 簡介 — 而是 production 部署 + 跨層協作 + 失敗修復的實作層教學。

進本文前先確認 MongoDB 已通過適配判讀：workload 是否落在 MongoDB 適用區（document shape 主導 / contract layer 該放哪 / 跨雲 hedging 是否需要）— 判讀軸見 schema-design-pattern 開頭 3 軸前置判讀。Read scaling 是 已選 MongoDB 後 的容量決策、判讀通不過時 read preference 修補無法救回 vendor 選錯。

問題情境：read scaling 撞牆的兩種長相

典型觸發場景：primary 寫入飽和、TL 提議「讀都打 secondary」想橫向擴容。改完後幾個 production 徵兆連環出現：

• User 看到「我剛下的訂單怎麼還沒出現」— write 進 primary、立刻 read 打 secondary、secondary 還沒 apply 該寫入、user 看到 stale data
• 跨 region replica set：app server 在 Tokyo、primary 在 Singapore、每筆讀走 70ms 跨海 RTT；改 nearest 後 latency 降但 stale read 出現
• Replication lag 在 backup 期間飆到分鐘級、secondary read 拿到幾分鐘前的資料、前端報表時間軸對不上
• Failover 期間 read preference 沒寫好、client 一直連舊 primary、SocketTimeout 直到 driver retry 邏輯介入

第二類議題、規模更大：把所有 read 打 secondary、replica 數量加到 5-7 仍撐不住 sustained 高 read（>500K reads/sec）；replication lag 升 + secondary CPU 飽和。這時 read preference 已不夠、必須加 cache + 跨層 freshness 機制。

讀者徵兆：rs.printSecondaryReplicationInfo() 顯示 lag 分鐘級、application log 出現「我剛寫的資料讀不到」客訴、failover 演練後 connection error 持續 30s+、cache hit rate 跟 read latency 反向相關。

Case anchor：9.C36 Coinbase 揭露「document model 撐 1.5M reads/sec 靠 cache + freshness token」、含警示「1.5M reads/sec 是 users 服務 加上 cache 的數字、不是 MongoDB cluster 純讀取數字」。跨 region read preference 改 nearest 後 stale read 的具體 incident 細節需未來 case 補完、本文以「常見 failure pattern」處理。

核心機制

MongoDB read preference + read concern 兩軸

Read preference 五種：

• primary（預設）：只打 primary、強一致、primary 飽和時無路可走
• primaryPreferred：先 primary、primary 不可用 fallback secondary
• secondary：只打 secondary、永遠拒 primary、failover 期間若所有 secondary 都不行就拋錯
• secondaryPreferred：先 secondary、secondary 不可用 fallback primary
• nearest：不是「最近的 secondary」、是「ping latency 最低的 member」（可能是 primary）；driver 用 latency window（預設 15ms）內隨機挑

Read concern 是另一軸：

• local：讀本地最新（含未確認）、效能最佳、可能讀到後來 rollback 的資料
• available：跟 local 類似但對 sharded cluster 有差異
• majority：讀到「已寫到多數 member」的資料、寫入 commit 後在多數 member 確認後才看得到
• linearizable：強制最新、必須打 primary、最高 latency

Write concern w: "majority" 保證寫入確認後在多數 member 上、但不保證 secondary 馬上 visible — 兩個概念分開。

Causal consistency session（DB 層機制）

Causal consistency session 解的是 單 client 在 MongoDB cluster 內部 的因果一致：

• Client session 帶 clusterTime + operationTime
• Driver 把 read 路由到「已 apply 該 operationTime」的 member
• 實現 read-your-own-write（自己剛寫的、自己讀得到）

機制只在「同一 client session」內生效。跨 client 的因果一致（A 寫 → B 讀）不在範圍內。

其他輔助機制：

• Tag set：member 標 {region: "ap-tokyo", role: "analytics"}、read preference 帶 tag 把流量路由到特定 member
• Hidden / delayed secondary：不參與 election、不接 client read、做 backup / DR 用
• Election：primary 失聯後 majority 投票選新 primary、預設 10s 內完成；election 期間所有 primary read 失敗

Freshness token（cache 層機制）

9.C36 Coinbase 揭露的 跨層 機制 — 解的是 MongoDB + cache 跨層 的 read-after-write、不是 cluster 內部。對應 Freshness Token 卡片的 application-level 版本協議定義：

觸發條件：直接打 MongoDB 不可能撐 1.5M reads/sec（口徑：users 服務應用層觀察、含 cache、非 MongoDB cluster 純讀取）。Coinbase 在 users 服務前加 Memcached query cache、單 document query 先查 cache。

跨層一致性問題：write 進 MongoDB primary、cache 還是舊資料、client 下次 read 從 cache 拿到舊版。

freshness token 機制：

1. Write 成功後、server 給 client 一個 token（包含 OCC version / clusterTime）
2. Client 之後 read 帶這個 token
3. Server 保證返回的資料版本 ≥ token
4. 若 cache 的版本 < token、bypass cache 直接打 DB

跟 causal consistency session 的關係：兩者解決同一類問題（read-after-write）但作用範圍不同。Causal session 是 DB 層、保證在同一 cluster 內 read-your-own-write；freshness token 是 DB + cache 兩層共用的版本協議、保證跨層 read-your-own-write。

跨層協作三選一

讀者真實系統的 read 一致性需求要選哪層處理：

對應 knowledge card：stale-read、replication-lag、session-consistency、eventual-consistency。

操作流程

Step 1：read shape 分類。把所有 read 分成四類：

• (a) 強一致必須 read-your-own-write（訂單詳情、帳戶餘額）
• (b) 容忍秒級 lag（個人資料、商品詳情）
• (c) 容忍分鐘級 lag（報表、analytics）
• (d) 大規模 read scaling 需 cache + freshness token（用戶資料 / 高頻 product query）

Step 2：依分類對映機制。

Step 3：driver config（Node.js / Java / Python 都類似）：

1mongodb://host1:27017,host2:27017,host3:27017/db?
2  replicaSet=rs0&
3  readPreference=secondaryPreferred&
4  readPreferenceTags=region:ap-tokyo&
5  readPreferenceTags=&
6  maxStalenessSeconds=90&
7  readConcernLevel=majority

readPreferenceTags 寫多個 = fallback chain（先 tokyo 失敗 fallback 任意）。maxStalenessSeconds=90 拒絕 lag > 90s 的 secondary。

Step 4：causal consistency session：

1with client.start_session(causal_consistency=True) as s:
2    coll.insert_one(doc, session=s)
3    # 下面這個 find 自動路由到能讀到剛才寫的 member
4    coll.find_one({"_id": doc["_id"]}, session=s)

Session 結束後因果關係結束、下個 session 不繼承。

Step 5：freshness token 設計（9.C36 Coinbase 模式）：

• Write API 返回 {result, version_token} — token 含 OCC version 或 MongoDB clusterTime
• Read API 接受 optional If-Version-≥ header / parameter
• Cache lookup 比對 cache entry version 跟 token、低於 token 就 invalidate + bypass 到 MongoDB
• DB 層 read 用 readConcern: "majority" 保證返回的 version ≥ token

Step 6：staging 驗證。灌入 replication lag（暫停 secondary apply）驗證 application 行為；灌入 stale cache 驗證 token bypass 邏輯；模擬 failover 驗證 driver retry。

驗證點：

• rs.printSecondaryReplicationInfo() lag < SLO
• driver metric readPreferenceUsageCount 分布符合預期
• failover drill 後 read recovery < 15s
• cache hit rate vs freshness bypass rate 比例監控

Rollback boundary：read preference 是 driver-side config、可以 hot-swap；causal consistency session 需 application code 改、需灰度；freshness token 是 application + cache + DB 三方協議、回退需協調。

失敗模式

Read-after-write 不一致（DB 層）：寫 primary → 立刻 secondary read、應用 race condition 顯示「資料消失」。修法是 causal consistency session、driver 自動路由到已 apply 該寫入的 member。

Read-after-write 不一致（跨層）：寫 primary → cache 還是舊資料 → user 看到舊資料。causal session 解不了（cache 在 MongoDB 外）、必須走 freshness token 跨層協議。

Stale read 在 lag 高峰：backup / DDL / 大量寫入導致 secondary lag 分鐘級、secondary read 拿到舊資料。修法設 maxStalenessSeconds 拒舊 member、driver 自動轉到較新的 member 或 primary。

nearest 在跨 region 不穩：latency 抖動讓 driver 在 primary / secondary 跳、寫一致性與 read latency 同時惡化。修法是不要用 nearest 解跨 region 議題、應該用 tag set 明確路由。

Failover 期間 primary read 全失敗：election 10s 內所有 primary read 拋錯。修法改 primaryPreferred + driver retry 邏輯吃掉短暫失敗、application 端配 retry policy。

Tag set 失準：把 region: "ap-tokyo" 的流量路由到 tag 為 tokyo 的 member、但該 member 故障時沒 fallback、流量直接停。修法是 tag 設多層 fallback chain、最後一層留空 tag 表示「任意 member」。

Analytical query 跑 OLTP secondary：secondaryPreferred 把報表打 OLTP secondary、報表 query 拖垮 OLTP read latency。修法是 analytical workload 用 tag set 路由到專屬 analytics secondary、跟 OLTP read 隔離。

Freshness token 漏寫：write 沒帶 token 給 client / client 沒帶 token、token 機制 silently 失效、read 走 cache 拿舊資料。修法 token 必須 e2e 強制（middleware 自動帶 / 自動驗證）、不能靠 application 自覺。

Cache bypass 比例失控：所有 read 都 bypass cache、cache 等於沒裝。修法是 token 失敗率要監控、過高表示 cache invalidation 設計有問題（cache 沒在 write 後 update / invalidate）。

Anti-recommendation：

• read-heavy 但有強一致需求的場景不要為了 scale 改 secondary read；該換 SQL + read replica 加 application-level cache、或加 sharding 把 primary 寫散開
• 大規模 OLTP（>500K reads/sec）想單靠 MongoDB read preference 撐 = 拿不到那個量級。Coinbase 案明示「直接打 MongoDB 不可能撐 1.5M reads/sec」、必須 cache + freshness token

容量與觀測

關鍵 metric：

• Replica health：每個 member 的 opcounters 分布、rs.status().members[].optimeDate 推算 lag
• Read preference 命中：driver-side readPreferenceTags 命中率
• 一致性 SLO：stale read 比例（causal consistency 拒絕重試次數）
• 跨層 freshness：cache hit rate vs freshness bypass rate

Mongo command：

• rs.status()：replica set 整體
• rs.printSecondaryReplicationInfo()：lag 概況
• db.serverStatus().repl：詳細 replication metric
• db.adminCommand({replSetGetStatus:1})：完整 status

Application observability：APM 看「同一 session 內 write + read 順序對 latency / error 的影響」、SLO 是 read-your-own-write 命中率；跨層還要看 freshness token 流動完整性（write 是否發 token、read 是否帶 token、cache 是否驗 token）。

Lag alarm：lag > 30s 預警、> 90s 觸發 driver maxStalenessSeconds 自動拒讀。

回到 4.20 observability evidence：把 read preference 命中分布、replication lag time series、failover drill recovery time、freshness token bypass rate 列為 evidence。

回到 9.5 bottleneck localization：read latency 異常時要區分 (a) primary 飽和 (b) secondary lag 高 (c) tag routing 把流量集中到單一 member (d) cache hit rate 下降 / bypass 率上升。

邊界與整合

Frame 5：合規邊界 — MongoDB 用 cluster-per-region 吸收

MongoDB / Atlas 沒有 row-level locality 機制（不像 CockroachDB 可把單 row pin 在合規 region）— 跨境合規必須以 cluster-per-region 拓樸吸收：每個合規市場開獨立 cluster、application 層做 routing、不靠 replica set / sharded cluster 機制跨 region。

跨 vendor 對照：

MongoDB 在這 frame 的退化點：read preference 機制本身不解合規 — 即使 readPreferenceTags={region:eu} 把流量路由到歐洲 secondary、但 primary 在亞洲時跨境 replication 仍在跑、合規 audit 不會放行 路由層 控制當作 資料邊界 控制。合規市場必須整 cluster 分離、再用 application 層 routing 把 user 帶到對應 cluster。

Atlas 在合規場景的 fit：Atlas global cluster（zone sharding 把 shard 鎖在 region）是「跨 region 但 資料 pin 在 zone」的中介選項、適合 GDPR 軟條款（資料在歐洲 EEA 內可流動）；strict 條款（資料不能離開單一國家）仍須走 cluster-per-region。

Sibling 與 cross-link

Sibling deep articles：

• shard key selection — read preference 解決不了 write 飽和、要切 shard
• change streams + Kafka — change stream 預設打 primary、放 secondary 的 trade-off
• aggregation pipeline optimization — 把 analytical aggregation 路由到專屬 secondary
• connection management and cache layer — freshness token 是該篇的核心議題之一、本文聚焦 DB 層 vs cache 層機制對照、不展開 cache 部署架構

Migration playbook：

• 跨 region 強 consistency 需求 → → Cosmos DB MongoDB API（5 consistency level）
• 跨 region 想保留原生 MongoDB → → Atlas global cluster

跟 1.x 互引：1.1 高併發資料存取 處理 read scaling pattern；1.11 全球分散式 OLTP 處理跨 region 一致性升級路徑。

相關連結

• MongoDB vendor overview — 本文是該頁尾「replica set + read preference」backlog 的深度展開
• Vendor 深度技術文章方法論
• 9.C36 Coinbase — freshness token + 1.5M reads/sec（含 cache）
• 官方：MongoDB Read Preference、Read Concern、Causal Consistency

本文的判讀錨點是：multi-source replication 是 consolidation pattern，而非 multi-primary conflict resolution。每個 replication channel 要有獨立 source、schema scope、lag、error handling 與 ownership。

Use Cases

Use cases 的核心責任是確認 multi-source 解決的是整併需求。

Multi-source target 通常應 read-only。若 target 同時接受 application write，就要設計 conflict 與 ownership，複雜度會大幅提高。

Channel Design

Channel design 的核心責任是把每個 source 隔離成可觀測單位。

Channel 命名要可讀。Incident 時看到 channel 名稱，就要知道哪個 source、哪個 team、哪個用途與是否可暫停。

Conflict Boundary

Conflict boundary 的核心責任是避免多個 source 寫同一份邏輯資料。Multi-source 沒有自動解決業務 conflict 的能力。

最安全的 pattern 是每個 source 寫自己的 schema 或帶 source namespace 的 table。若多 source 寫同一 table，必須先設計 key space 與 conflict policy。

Monitoring

Monitoring 的核心責任是讓每個 channel 的狀態可見。

1SHOW REPLICA STATUS FOR CHANNEL 'source_a'\G
2SHOW REPLICA STATUS FOR CHANNEL 'source_b'\G

要觀測：

1. IO thread / SQL thread status。
2. Seconds behind source。
3. Last IO error / SQL error。
4. Relay log growth。
5. GTID executed / retrieved。
6. Channel credential expiry。

Lag 要分 channel 告警。總體 replica 健康不足以定位哪個 source 卡住。

Migration Pattern

Migration pattern 的核心責任是把 multi-source 用在可回退的搬遷。

Migration target 若只是 reporting，cutover 風險較低；若要成為 new primary，還要處理 write freeze、conflict、application route 與 rollback。

Failure Modes

Failure modes 的核心責任是把 multi-source 事故分 channel 處理。

Channel failure 要避免全局操作。只停問題 channel，保留其他 channel，能降低 blast radius。

下一步路由

Multi-source replication 完成後，基本拓撲讀 Replication Topology；failover 讀 Orchestrator Failover；CDC 與 binlog 讀 Binlog CDC。

本文的驗收標準是：你能記錄 replication status、lag、promotion timeline、client error sample、validation query 與 incident decision log。

Baseline Replication

Baseline replication 的核心責任是先保存 source / replica 狀態。實際建立 replication 依 GTID、binlog file position、Docker topology 或 managed service 而異；本文聚焦演練 evidence。

1SHOW REPLICA STATUS\G
2SHOW BINARY LOG STATUS;

Baseline 要記錄：

1. Source host / replica host。
2. GTID executed / retrieved。
3. IO thread / SQL thread。
4. Seconds behind source。
5. Read endpoint / write endpoint。

Client Workload

Client workload 的核心責任是讓 failover 對 application 可見。

1while true; do
2  mysql -h "$MYSQL_WRITE_HOST" -u app_user -papp_pw appdb \
3    -e "INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key) VALUES (1, 1, UUID());"
4  sleep 1
5done

這個 synthetic workload 產生成功、timeout、duplicate、read-only 或 connection error。正式演練要避免碰 production side effect。

Promotion Frame

Promotion frame 的核心責任是把 failover action 寫成可審查步驟。

1failover_start:
2old_source:
3candidate_replica:
4lag_before:
5promotion_method:
6accepted_data_loss:
7operator:

Managed service、Orchestrator 或手動 promotion 都要留下同樣欄位。工具不同，決策證據一致。

Validation

Validation 的核心責任是確認 promoted instance 可讀寫且資料符合預期。

1SELECT COUNT(*) FROM ledger_entries;
2SELECT MAX(created_at) FROM ledger_entries;
3SHOW VARIABLES LIKE 'read_only';
4SHOW VARIABLES LIKE 'super_read_only';

若使用 GTID，還要比較 source / replica 的 GTID set。若有 external side effect，要用 idempotency key 做 reconciliation。

Client Route

Client route 的核心責任是確認 application、ProxySQL、DNS 或 secret 已指向新 writer。

檢查項目：

1. Write endpoint 是否更新。
2. ProxySQL writer hostgroup 是否切換。
3. Application pool 是否清掉舊連線。
4. Retry 是否有 backoff。
5. Read replica 是否重新掛到新 source。

Failover 完成標準包含資料庫 promotion 與 client route 穩定。只 promote 成功，application 仍可能寫到舊 endpoint。

Incident Log

Incident log 的核心責任是把演練結果保存。

1Drill id:
2RTO observed:
3RPO / accepted data loss:
4Client errors:
5Validation:
6Follow-up:

完成本篇後，拓撲設計讀 Replication Topology；自動化工具讀 Orchestrator Failover；routing 讀 ProxySQL Routing Lab。

本文的判讀錨點是：cross-region DR 是恢復策略，而非自動等同 multi-region active-active。PostgreSQL 可以透過 backup / WAL archive、physical standby、logical replication、managed service replica 或 application-level replication 支援不同 RPO / RTO；每種路線都有資料延遲、切換與回切成本。

DR Strategy

DR strategy 的核心責任是把恢復目標和技術路線對齊。

RPO 要由業務定義。若付款、訂單、庫存只允許秒級遺失，backup-only 路線通常成本不足；若是內部報表或可重建資料，backup + WAL archive 可能足夠。

Physical vs Logical

Physical vs logical 的核心責任是區分 byte-level recovery 與 row-level replication。Physical replica 保留 PostgreSQL cluster 層級狀態；logical replication 提供 table / publication 層級彈性。

Physical standby 適合整體 DR。它的 runbook 要處理 WAL archive、replication lag、promotion、timeline、DNS / connection string 切換與回切。

Logical replication 適合局部資料或跨版本轉換。它的 runbook 要處理 publication、subscription、replication slot、schema migration ordering 與資料 diff。

Failover Runbook

Failover runbook 的核心責任是把災難切換變成可演練步驟。最小流程包含 incident declare、source freeze、replica health check、promote、traffic switch、data validation 與 rollback / rebuild。

Failover 決策要有 owner。自動化可以執行步驟，但是否接受資料遺失、是否凍結寫入、是否 promote，仍需要明確責任人與 tripwire。

Data Reconciliation

Data reconciliation 的核心責任是處理 cross-region 切換後的資料差異。只要 replication lag 存在，failover 後就可能有未套用交易。

Reconciliation 要先定義 critical table。所有表都做 full diff 成本高；付款、訂單、權限、ledger、mutation log 等高風險資料要有專用 validation query。

Drill Design

Drill design 的核心責任是定期驗證 RPO / RTO。DR 文件只有在演練後才可信。

演練至少包含：

1. 從 backup + WAL 還原到指定時間。
2. Promote standby 到 isolated environment。
3. Application 使用 DR endpoint 跑 smoke test。
4. 計算實際 RPO / RTO。
5. 記錄失敗點、人工步驟與下一次修正。

演練應避開 production destructive action。使用 isolated VPC、staging app、read-only validation 與 mock external side effect。

No-Go Conditions

No-go conditions 的核心責任是指出 PostgreSQL cross-region DR 的邊界。

Cross-region DR 要誠實面對延遲。把每個 region 都變成 writer 需要 distributed transaction 模型；PostgreSQL DR 路線主要提供恢復與切換。

下一步路由

Cross-region DR 完成後，恢復實作讀 PITR / WAL Archiving；replication 架構讀 Replication Topology；跨區 rollout 的資料政策讀 Multi-region GDPR Rollout。

本文的判讀錨點是：replicated SQLite 要先說明 replica 的服務責任。它可能是 continuous backup、warm restore source、read replica、primary failover helper 或 deployment topology；每一種責任都有不同的 RPO、RTO、freshness 與 incident runbook。

Replication Taxonomy

Replication taxonomy 的核心責任是把「有複本」拆成可操作的幾種能力。SQLite 周邊工具常用 replication 這個字，但 operator 需要知道它到底保護哪個風險。

Continuous backup 的語言是 RPO 與 RTO。它關心最近一次成功送出的 WAL、snapshot freshness、object storage credential、restore 指令與演練結果。

Read replica 的語言是 freshness。Replica 能降低 read latency 或保護 primary workload，但讀者要知道 stale window、read-after-write policy、fallback to primary 與 cache invalidation。

Primary lease 的語言是 writer ownership。SQLite 的服務形狀仍適合 single writer；工具可以協助 deployment 切換，但 application 要配合 fencing、retry 與 promotion evidence。

Litestream Boundary

Litestream boundary 的核心責任是把 SQLite WAL 變成可持續複製的 backup stream。Litestream 官方說明把它定位為 SQLite streaming replication tool，並在 How it works 與 restore command 文件中強調 replica 與 restore workflow。

Litestream 適合下列情境：

1. 單節點 SQLite app 要降低資料遺失窗口。
2. 系統可接受 restore 後重新啟動 service。
3. Object storage credential、retention、restore drill 可以被管理。
4. Write pattern 適中，WAL stream 與 snapshot 維護成本可控。

Litestream 的設計重點是 backup evidence。Runbook 要記錄 replica destination、last replicated generation、last restore test、expected RPO、expected RTO、restore target path、credential rotation 與 corruption triage。

1litestream restore -o /var/lib/app/restored.db s3://example-bucket/app.db
2sqlite3 /var/lib/app/restored.db "PRAGMA integrity_check;"

這段命令是 restore drill 的最小骨架。正式 runbook 要補上 service stop、database path、sidecar file、permission、checksum、application smoke test 與 rollback decision。

Litestream 的風險集中在 restore path。備份存在和服務可恢復是兩件事；每次 release 或 schema migration 後，都應用 staging data 跑一次 restore、integrity check、row count 與 application smoke test。

LiteFS Boundary

LiteFS boundary 的核心責任是支援 replicated deployment topology，而非只做 backup。LiteFS 在 Fly.io 文件中被定位為 SQLite replication layer，透過 FUSE filesystem 與 primary lease 模型協助應用在多個 instance 間運作。

LiteFS 適合下列情境：

1. App 仍希望使用 SQLite file 與 local SQL path。
2. Deployment 有多個 instance，但 write authority 可以集中到 primary。
3. Read replica freshness 可以被產品接受。
4. Team 願意把 filesystem layer、primary lease、promotion 與 platform operation 納入 runbook。

LiteFS 的設計重點是 primary ownership。Application 要知道 write request 到哪裡執行、primary 切換時如何重試、read replica 讀到舊資料時如何回應，以及 promotion 完成前哪些 endpoint 要進入 degraded mode。

LiteFS 的 incident route 要從 writer ownership 開始查。若出現 write error、stale read 或 suspected split brain，先查看 primary lease、instance health、replication lag、pending writes 與 platform network，再處理 application retry。

Failure Modes

Failure modes 的核心責任是把 replicated SQLite 的事故從「資料庫壞了」拆成可排查訊號。SQLite file、WAL、object storage、filesystem layer、deployment platform 與 application retry 都可能是問題來源。

Replica lag 要接到 alert。對 Litestream，它意味著 RPO 正在擴大；對 LiteFS，它可能同時影響 read freshness 與 failover confidence。

Restore lag 要接到 release gate。若 restore time 已超過目標 RTO，就要調整 snapshot frequency、資料保留策略或搬到 server database。

Stale read 要接到產品語言。使用者看到舊資料時，系統可以顯示 sync state、重讀 primary、限制 critical action 或提供 refresh；這些策略要在設計階段決定。

No-Go Conditions

No-go condition 的核心責任是避免把 replicated SQLite 推到 distributed OLTP 的位置。SQLite 周邊 replication 工具可以強化單節點與 read replica，但高寫入、多 writer、強一致跨 region transaction 需要不同資料庫模型。

No-go 條件要在 design review 階段列出。SQLite replication 的好處是低成本與低元件數；當核心需求變成跨節點一致性寫入，繼續調工具會把風險藏在 incident 時刻。

Decision Route

Decision route 的核心責任是把資料保護、讀擴展與高可用分開選型。Litestream / LiteFS 位置清楚時，SQLite 可以保持簡潔；位置混淆時，系統會同時缺 backup evidence 與 transaction guarantee。

選擇 Litestream 時，完成標準是能在 staging 從 replica restore 出可用 DB。選擇 LiteFS 時，完成標準是能演練 primary 切換、read freshness、write retry 與 degraded mode。

下一步路由

Litestream / LiteFS replication 完成後，下一步要回到 SQLite operation evidence。File copy、backup API 與 WAL sidecar 請讀 file lifecycle / backup boundary；busy、lock 與 writer 壓力請讀 WAL concurrency / locking；完整 runbook 請讀 SQLite observability / runbook。