MySQL replication failover lab 的核心責任是讓讀者觀察 source / replica 拓撲在 promotion 時的資料與 client route。這篇承接 Replication Topology 與 Orchestrator Failover。

本篇整理 source / replica failover 演練要留的 evidence：replication status 與 lag、promotion timeline、client error sample、validation query 與 incident log；replication 本身怎麼建立不在範圍內。

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 可見。

1# MYSQL_WRITE_HOST：application 寫入用的 endpoint（直連 source、ProxySQL writer 或 DNS 名稱）
2i=0
3while true; do
4  i=$((i+1))
5  # idempotency key 由迴圈計數產生，validation 時可以逐號比對
6  mysql -h "$MYSQL_WRITE_HOST" -u app_user -papp_pw appdb \
7    -e "INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key) VALUES (1, 1, 'failover-drill-$i');"
8  sleep 1
9done

這個 synthetic workload 在 failover 期間會出現成功、timeout、read-only 或 connection error。idempotency key 由 client 端的迴圈計數產生（failover-drill-1、failover-drill-2……），validation 時比對新 source 上有哪些編號，就知道哪幾筆寫入沒有進去；同一個編號重送時撞到 uk_ledger_idempotency，回 ERROR 1062，這就是 duplicate error 的來源。key 由 server 端的 UUID() 產生時，每次送出都是新值，同一筆寫入重送也不會撞到 unique key。正式演練要避免碰 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。