本文是跨 vendor migration playbook、cross-link 到 MySQL 跟 PostgreSQL。本文是 Migration playbook methodology Type A 的標準形態實證。

三類 SQL dialect diff sample：先看具體差距

 1-- 1. Auto increment / sequence
 2-- MySQL
 3CREATE TABLE users (id INT AUTO_INCREMENT PRIMARY KEY);
 4-- PostgreSQL
 5CREATE TABLE users (id SERIAL PRIMARY KEY);
 6-- 或 PG 10+:
 7CREATE TABLE users (id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY);
 8
 9-- 2. String concatenation
10-- MySQL: CONCAT(a, b) 或 a || b 在 ANSI mode
11SELECT CONCAT(first_name, ' ', last_name) FROM users;
12-- PostgreSQL: a || b 或 CONCAT(a, b)
13SELECT first_name || ' ' || last_name FROM users;
14-- 注意: PostgreSQL 對 NULL || x = NULL、MySQL CONCAT 對 NULL 處理不同
15
16-- 3. UPSERT
17-- MySQL
18INSERT INTO users (id, name) VALUES (1, 'Alice')
19ON DUPLICATE KEY UPDATE name = VALUES(name);
20-- PostgreSQL (9.5+)
21INSERT INTO users (id, name) VALUES (1, 'Alice')
22ON CONFLICT (id) DO UPDATE SET name = EXCLUDED.name;
23
24-- 4. Index hint / FORCE INDEX
25-- MySQL
26SELECT * FROM orders FORCE INDEX (idx_created_at) WHERE created_at > '2025-01-01';
27-- PostgreSQL: 沒對應 syntax、依賴 planner + statistics
28-- 必要時用 enable_seqscan=off 或 pg_hint_plan extension
29
30-- 5. JSON path
31-- MySQL 5.7+
32SELECT data->'$.name' FROM events;
33-- PostgreSQL
34SELECT data->'name' FROM events;
35SELECT data->>'name' FROM events;  -- 取出 text

5 個 sample 看出 MySQL → PostgreSQL 主要工作是 SQL dialect translation；不是 5-10 個函數差、是 跨整個 application SQL surface 的 audit + 改寫。對應 diff dimension audit 結果：

主導維度 Schema = High、走 Type A 6-phase playbook 標準結構。

Phase 0：rule audit + SQL surface 盤點

 1-- 1. 列所有 stored procedure
 2SELECT routine_schema, routine_name, routine_type
 3FROM information_schema.routines
 4WHERE routine_schema NOT IN ('mysql', 'sys', 'information_schema', 'performance_schema');
 5
 6-- 2. 列所有 trigger
 7SELECT trigger_name, event_object_table, action_statement
 8FROM information_schema.triggers;
 9
10-- 3. 列所有 view
11SELECT table_name, view_definition
12FROM information_schema.views;
13
14-- 4. 列所有 index 含 prefix length
15SHOW INDEX FROM users;
16-- PostgreSQL 對 prefix index 處理不同、要逐個 audit

Audit 主要產出三類清單：

• Direct port：標準 SQL feature、PG 直接接受
• Translate：MySQL-specific syntax、需要改寫（UPSERT / CONCAT NULL 行為 / index hint）
• Refactor：MySQL-specific behavior（auto_increment session-level / SELECT FOUND_ROWS / GROUP BY 寬鬆 / TEXT 隱性 cast）— 不能直接 port、application code 也要改

Phase 1：schema 對位

Schema 對位表存版控、application code refactor 時對照。

Phase 2：Translation pipeline（3-tier 跟 Splunk → Elastic 類似）

Tier 1：vendor / community tool

1# pgloader：成熟工具、cover ~70-80% schema + data
2pgloader mysql://user:pass@mysql-host/dbname \
3         postgresql://user:pass@pg-host/dbname
4
5# 或 AWS DMS（managed、適合 RDS / Aurora target）
6# DMS task: Full Load + CDC

Tier 2：自家 SQL refactor

對 ORM 不能 cover 的 raw SQL：

• Manual grep application code 找 auto_increment / ON DUPLICATE KEY / FORCE INDEX / FOUND_ROWS() / CONCAT NULL
• 寫 codemod / lint rule、CI 強制 check（PG-incompatible SQL block PR）

Tier 3：tricky case manual

例：MySQL SELECT * FROM t1, t2 WHERE t1.id = t2.id GROUP BY t1.id（implicit GROUP BY 寬鬆）— PG 嚴格 GROUP BY 必須 list 所有 non-aggregate column；application code refactor 必要。

Phase 3：Parallel run

雙寫 + 雙讀比對 1-2 個月：

1Application ──→ MySQL (write + read primary)
2            └─→ PostgreSQL (write only + read shadow)
3                                    ↓
4                            Diff checker (latency / result diff)

pt-table-checksum (MySQL) + 自家 checksum scanner 對 sample table 跑 daily checksum、找 schema 對位錯。

Phase 4：Cutover

• 設 application maintenance window（30 分鐘）
• Drain MySQL write、等 last LSN propagated to PG
• Application switch connection string → PG
• 解除 maintenance、monitor 24-48 hours

Phase 5：Cleanup

• MySQL read-only 1-2 週（fallback window）
• 之後 stop replication、decommission MySQL

Production 故障演練

Case 1：Auto_increment vs SERIAL 跨 transaction 行為差

徵兆：cutover 後某 batch job 跑得比 MySQL 慢 5-10x、PG log 顯示 sequence 競爭。

根因：MySQL AUTO_INCREMENT 取值受 innodb_autoinc_lock_mode 控制（8.0 預設 mode=2 interleaved 可並行、mode=0 才是 table-level lock；詳見 Lock contention）、PG SERIAL 是 sequence-level non-transactional；mode=0 場景跟 PG SERIAL 差異最大、mode=2 跟 PG SERIAL 行為較接近（皆可亂號、皆可並行）。

修法：

1. 改 UUID v7 / bigserial：消除 sequence 競爭
2. bigserial + cache：CREATE SEQUENCE ... CACHE 100、batch 預取 100 個 ID 降 contention
3. 批量 insert 改 COPY：COPY t FROM STDIN 是 PG 對 batch 最快路徑

Case 2：Charset / collation 跑出 unicode 異常

徵兆：cutover 後某些用戶名 / 中文文字 query 對不到結果、SELECT * WHERE name = '張三' 返回空。

根因：MySQL default utf8mb3（3-byte UTF-8、不能存 emoji / 部分 unicode）、PG default UTF8 全 unicode；資料遷移時 MySQL 端的 utf8mb3 column 帶到 PG 後 bytes 不變 但 collation rule 變；string comparison 結果差。

修法：

1. Pre-migration audit：MySQL 強制 utf8mb4、avoid utf8mb3 data
2. Collation 對位：MySQL utf8mb4_unicode_ci → PG LC_COLLATE = 'C.utf8' 或 ICU collation
3. Application encoding contract：明示 UTF-8 全範圍、不接受 utf8mb3-only client

Case 3：Case sensitivity 反轉

徵兆：cutover 後 application query SELECT * FROM users 報錯 relation does not exist；但 SELECT * FROM "Users" works。

根因：MySQL Linux default table name case-sensitive、Windows case-insensitive、配置 lower_case_table_names 影響；PG all identifier folded to lowercase unless quoted。MySQL on macOS 開發環境是 case-insensitive、PG 嚴格 case-sensitive、application code 端可能用 mixed case。

修法：

1. Schema migration 階段強制 lowercase：所有 table / column name 統一 lowercase
2. Application code refactor：grep raw SQL 找 mixed case identifier、改 lowercase
3. ORM 端設定 naming_strategy：JPA / Hibernate 等明示 lowercase mapping

Case 4：Replication 行為差、CDC pipeline 失效

徵兆：MySQL 端 binlog-based CDC（Debezium MySQL connector）跑得好好的、cutover 後 PG 端要重建 CDC pipeline、初期 1-2 週 message 模式異常。

根因：MySQL binlog row format vs PG logical replication slot 完全不同 protocol；Debezium 對兩家連接器是 獨立 binary、message schema 部分對等但不直通。

修法：

1. Pre-cutover 建 PG 端 CDC：Debezium PG connector 提前部署、初期跟 MySQL CDC 並存比對
2. Schema registry 同步：Avro schema 從 MySQL 端 export、註冊 PG 端 connector 用同 schema
3. Consumer 端 idempotent：cutover 期間 dual-source、consumer 必須 idempotent 避免 duplicate

Case 5：FULLTEXT INDEX 對應 tsvector、application search broken

徵兆：cutover 後 application 全文搜尋功能失效、MATCH(name) AGAINST('xxx') 不被 PG 認；application 端 raw SQL 對 search 寫死。

根因：MySQL FULLTEXT INDEX + MATCH ... AGAINST syntax PG 不支援；PG 用 tsvector + ts_rank + to_tsquery、概念對等但 syntax 完全不同。

修法：

1. Pre-migration：列 application 用到的 fulltext search 場景、改寫成 tsvector pattern
2. 大型 search 改 Elasticsearch / Meilisearch：fulltext 是專門 search engine 的本職、不該用 RDBMS 解
3. 降級為 LIKE：簡單 case WHERE name ILIKE '%xxx%'、performance 較差但相容性好

Capacity / cost

Migration 主要 cost 在 application code refactor + dual-write window operational、不是 DB itself。

整合 / 下一步

跟 PostgreSQL → Aurora migration 串接

部分組織走 MySQL → PostgreSQL → Aurora 兩段：

• 先 MySQL → self-managed PostgreSQL（schema 對位 + application 改）
• 穩定後 self-managed PostgreSQL → Aurora（operational simplification）

不要一次跑 MySQL → Aurora PostgreSQL compat、認知負擔太大、failure mode 互相干擾。

跟 Logical Replication + Debezium 對位

PG 端 CDC pipeline 在 cutover 完成後立刻可用；可作為 downstream CDC 重建 的契機、設計 outbox pattern 更穩。

下一步議題

• MySQL 8 vs PostgreSQL 16 feature gap：MySQL 8 加了 CTE / window function / generated column；2025+ feature parity 漸高、migration ROI 評估會變
• Reverse migration（PG → MySQL）：少見、通常是 application 端 dependency lock-in（用了 MySQL-specific stored procedure）
• MariaDB → PostgreSQL：跟 MySQL → PG 類似、MariaDB 部分 syntax 略接近 PG（如 RETURNING）

相關連結

• Source / target vendor：MySQL / PostgreSQL
• 後續路線：PostgreSQL → Aurora
• 平行 migration playbook：Splunk → Elastic（同為 Type A 高 schema 差）
• Methodology：Migration playbook methodology（本文驗證 Type A 標準形態）

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

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 online schema change — gh-ost 跟 pt-online-schema-change 兩條工具路徑的機制對比。

兩工具最終結果一樣（ghost table 取代原表）、但 過程中對 production 的影響非常不同。選哪個取決於：trigger overhead 可不可接受、是否有 foreign key、是否需要 resume/throttle 能力、團隊熟悉哪條工具鏈。

為什麼 ALTER TABLE 需要 online path

MySQL 8.0 之前的 ALTER TABLE 多數情況下 rebuild 整張表 — 過程中 primary key 之外的 read/write 都 block。100 GB 表 ALTER 跑 hours、production write 全部失敗。

MySQL 8.0 加 Instant DDL（部分 ALTER 不 rebuild、只改 metadata、毫秒級完成）、但 能用 instant 的 ALTER 是 subset：

• 支援：ADD COLUMN（末尾）、DROP COLUMN（部分情境）、RENAME COLUMN
• 不支援：ADD INDEX、CHANGE COLUMN type、ADD/DROP PRIMARY KEY、ADD FOREIGN KEY

不支援 instant 的場景仍要走 ghost table。Percona 跟 GitHub 各自從 production 痛點出發、產出 pt-osc（2011）跟 gh-ost（2016）。

pt-online-schema-change：用 trigger 同步寫入

pt-osc 流程：

1. CREATE ghost table（跟原表同 schema + 你要的 ALTER）
2. 在原表上 建 3 個 trigger：INSERT / UPDATE / DELETE
3. 任何寫入原表的 transaction 同時觸發 trigger 寫對應 ghost
4. 背景 chunk-by-chunk copy 既有 row 到 ghost
5. 全部 copy 完後 RENAME TABLE：原表 → archive、ghost → 原表名（atomic、metadata lock 毫秒級）
6. Drop trigger、drop archive

Trade-off：

• 寫入 overhead：每個 primary 寫入 transaction 都多一次 trigger 執行、寫吞吐降 10-30%
• Replica lag：trigger 跟原寫入同 transaction、replica 上每個 row 也跑 trigger、replica lag 可能暴增（缺少主動 throttle）
• Roll back 困難：tool 跑到一半失敗、trigger 已建、要手動清掉才能 retry
• FK 處理：原表有 FK 指向時、ghost table 要先 drop FK 再 recreate、操作複雜

適用：

• 寫吞吐 < 50% capacity（有 buffer 撐 trigger overhead）
• 無 FK 或 FK 簡單
• 沒有 replica lag 敏感的 read（trigger 在 replica 也跑）

不適用：

• 高寫吞吐（> 80% capacity）— trigger overhead 直接 saturate
• 大量 FK 結構
• 需要 throttle / pause / resume

gh-ost：用 binlog stream 同步寫入

gh-ost 流程：

1. CREATE ghost table
2. 從 replica 讀 binlog（不在 primary 加 trigger）
3. 同步 primary 上的寫入 透過 binlog event 寫到 ghost
4. 背景 chunk-by-chunk copy 既有 row 到 ghost
5. 全部 copy 完後 swap：RENAME TABLE
6. Drop archive

Trade-off：

• 寫入 overhead：0（binlog 已經寫了、gh-ost 只是 consumer）
• Replica lag 影響：gh-ost 可監測 replica lag、超過 threshold 自動 throttle copy（不影響 primary 寫入）
• Roll back 容易：取消時直接 drop ghost table、原表完全沒被改動
• FK 不支援：gh-ost 設計上不處理 FK、有 FK 必須先 drop / restructure

適用：

• 高寫吞吐 production（trigger overhead 不可接受）
• 需要 throttle / pause / resume（gh-ost interactive command 可動態調 chunk size、cut-over 時點）
• 已用 GitHub-flavored MySQL operations workflow

不適用：

• 有複雜 FK 結構、不想動 schema
• Replica 跑不了 binlog（極少數場景）

配置 step-by-step（gh-ost）

實務 production 多用 gh-ost（GitHub / Slack / Booking.com 等）。pt-osc 用於有 FK 或舊系統。

gh-ost 一個 ALTER 命令

 1gh-ost \
 2  --host=replica.example.com \           # 從 replica 讀 binlog
 3  --user=ghost \
 4  --password=... \
 5  --database=production \
 6  --table=orders \
 7  --alter='ADD COLUMN status VARCHAR(20) DEFAULT NULL, ADD INDEX idx_status (status)' \
 8  --allow-on-master=false \              # 不直接連 primary 讀 binlog
 9  --chunk-size=1000 \                    # 每批 copy 1000 row
10  --max-load='Threads_running=50' \      # primary load 限制
11  --critical-load='Threads_running=200' \ # 超過直接 abort
12  --max-lag-millis=1500 \                # replica lag 限制
13  --throttle-additional-flag-file=/tmp/throttle \  # touch 此檔 throttle
14  --postpone-cut-over-flag-file=/tmp/postpone \    # touch 此檔延後 cut-over
15  --execute                              # 真的執行（沒這個只 dry-run）

Interactive command（gh-ost 跑起來後）

1# 連 gh-ost socket（同 directory）
2echo "status" | nc -U /tmp/gh-ost.production.orders.sock
3# 動態調 chunk size
4echo "chunk-size=500" | nc -U /tmp/gh-ost.production.orders.sock
5# 立即觸發 cut-over（不再等）
6echo "unpostpone" | nc -U /tmp/gh-ost.production.orders.sock
7# Abort 並 drop ghost
8echo "panic" | nc -U /tmp/gh-ost.production.orders.sock

配置 step-by-step（pt-osc）

對比 gh-ost 的 binlog reader、pt-osc 命令更短但配置義務同樣多：

 1pt-online-schema-change \
 2  --host=primary.example.com \
 3  --user=ghost \
 4  --password=... \
 5  --alter='ADD COLUMN status VARCHAR(20) DEFAULT NULL, ADD INDEX idx_status (status)' \
 6  D=production,t=orders \
 7  --chunk-size=1000 \
 8  --max-load='Threads_running=50' \
 9  --critical-load='Threads_running=200' \
10  --max-lag=1.5 \
11  --check-replication-filters \           # 防 binlog filter 漏 trigger
12  --alter-foreign-keys-method=auto \      # auto / rebuild_constraints / drop_swap / none
13  --execute

--alter-foreign-keys-method 是 pt-osc 對 FK 處理的策略選項、四種選擇對 production 影響非常不同（rebuild 重建 FK / drop_swap 用更快但少了 atomic、none 是不處理）。

5 個 Production 踩雷

1. pt-osc trigger overhead 不可預期

--max-load='Threads_running=50' 看起來保護了 server、但 trigger 在 transaction 內、production 的 每個寫入 都加 trigger 開銷。Threads_running 是 當下 數字、看不到 trigger 累積 latency。常見場景：高峰時段下 pt-osc、預期 30% overhead、實際 60%、p99 飆 5x。

修法：

• 高峰時段不跑 pt-osc、排 off-peak window
• 用 staging environment 跑 production-like load 預估 trigger overhead
• 對寫吞吐 > 50% capacity 的 server 改用 gh-ost

2. gh-ost binlog lag 跟 primary 寫入率追不上

gh-ost 從 replica 讀 binlog、binlog event 進來速度有上限。如果 primary 寫入率超過 gh-ost binlog consume 速度（每秒幾千 transaction 對某些 server 已是 ceiling）、gh-ost 永遠追不上、cut-over 會長時間卡住。

修法：

• gh-ost 預設用 replica binlog、改用 --allow-on-master 直接從 primary 讀（如果 primary 容量夠）
• 提高 --chunk-size 加快 copy（同時用 --max-load 防過載）
• 真的追不上、考慮 暫停部分寫入流量（throttle traffic，而非 throttle tool）

3. Foreign key constraint — 兩工具都尷尬

原表有 FK 指向（其他 table FK references 這張表）、ghost table 切換時 新 ghost 沒有那些 FK 指向。Cut-over 一瞬間、FK 從指向「原表」變成指向「archive 表」、外部 constraint 失效。

修法（pt-osc）：

• 用 --alter-foreign-keys-method=rebuild_constraints：先 ALTER 外部 table FK 指向 ghost、再 cut-over
• 或 drop_swap：cut-over 前 drop FK、cut-over 後 recreate（更快但 cut-over 期間 FK 失效）

修法（gh-ost）：

• gh-ost 不支援 — 手動 drop FK / 重 setup FK
• 或維護 schema 改 FK 結構（FK 改在 application 層 enforce）

4. pt-osc trigger 跟 application 既有 trigger 衝突

原表上已經有 application 自建 trigger、pt-osc 在原表 再加 3 個 trigger、新舊 trigger 執行順序 MySQL 不保證（多 trigger 同事件按 未定義順序）。Application 行為可能 subtly broken。

修法：

• 跑 pt-osc 前 audit 原表 trigger（SHOW TRIGGERS FROM production LIKE 'orders'）
• 如果有 application trigger、考慮 暫時 disable 再 ALTER 或改 gh-ost
• gh-ost 不在原表加 trigger、不會碰到這個問題

5. Cut-over 瞬間 deadlock — 兩工具都有但表現不同

Cut-over 用 RENAME TABLE original TO archive, ghost TO original（atomic operation）。但 cut-over 瞬間需要 metadata lock、跟 進行中的 long-running transaction 衝突會 wait。Long-running transaction 持續、cut-over 永遠 wait、最後 timeout 失敗。

修法（gh-ost）：

• --cut-over-lock-timeout-seconds=3、超時 abort、稍後 retry
• --postpone-cut-over-flag-file：先把 copy 跑完、等流量空檔再觸發 cut-over

修法（pt-osc）：

• --set-vars="lock_wait_timeout=60"、cut-over 等更久（風險：long transaction 撐住更久 server 更多 lock wait）
• 或排在 long transaction 已知不會跑的時段（nightly backup 後）

容量 / 時間估算

對 100 GB 表、ALTER 加 column + 加 index 為例：

兩工具總時間接近、影響 production 的差異大。

跟其他模組整合

跟 GTID / Replication topology

兩工具都 依賴 replication — pt-osc 透過 trigger 確保 replica 同步、gh-ost 直接從 replica 讀 binlog。Pre-requisite：

• Binlog ROW format（兩工具都要）
• GTID 啟用（gh-ost 更需要、binlog re-pointing 容易）
• 詳見 Replication Topology

跟 Vitess

Vitess 有自己的 VReplication-based online DDL、不用 gh-ost 或 pt-osc。Vitess online DDL 在 shard 內部用類似 gh-ost 的 binlog stream 機制、但有 Vitess-aware schema management。詳見 Vitess sharding 設計 篇（待寫）。

跟 Aurora MySQL

Aurora MySQL 仍支援 gh-ost / pt-osc、但 Aurora 自己的 fast DDL（部分 ALTER） 比 8.0 Instant DDL 更廣。先檢查 Aurora 文件、能用 native fast DDL 就不用 ghost table tool。詳見 Aurora vendor page。

跟 PlanetScale

PlanetScale（managed Vitess）走 branch-based schema migration — 建 schema branch、跑 schema change、deploy 時 atomic merge。schema change 由 PlanetScale 內建流程承擔。詳見 PlanetScale migration playbook。

Production case：gh-ost operation workflow

Online schema change 的 production 責任是把大表 DDL 拆成可暫停、可節流、可切換的資料搬移流程。gh-ost 作為 GitHub 開源工具，把 schema change 轉成 ghost table copy、binlog tailing 與 controlled cutover；這讓 operator 可以在 replica lag、application load 或部署窗口變化時調整速度。

這個案例要回收到三個操作判準。第一，throttle 指標要接 production SLO，例如 replica lag、thread running、application latency 或錯誤率，而非只看 copy rows/sec。第二，pause / resume 是變更治理能力，代表 schema change 可以配合 incident response、deploy freeze 與商業尖峰窗口。第三，cutover 要設 rollback window 與 owner，因為 rename table 的瞬間仍是高風險控制點。

gh-ost workflow 的 sibling 路由是 PostgreSQL Online Schema Change。PostgreSQL 常靠 fast ALTER、MVCC 與 extension 工具解決同類需求；MySQL 的 ghost table tool 更常成為標準路徑，主因是大表 DDL、metadata lock 與 replication event 的組合壓力不同。

何時用哪一個

相關連結

• MySQL vendor overview
• MySQL Replication Topology（binlog ROW format + GTID 是 pre-requisite）
• PostgreSQL Online Schema Change（PG sibling、為什麼 PG 比 MySQL 少用 ghost table — fast ALTER 覆蓋多數變更）
• Aurora vendor page（managed MySQL fast DDL）
• PlanetScale（branch-based 不用 ghost table）
• 1.6 Database Migration Playbook（schema migration 治理）
• Expand / Contract 卡片（schema migration 設計原則）
• 官方：gh-ost / pt-online-schema-change

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 ProxySQL 配置 — connection pool + query routing 的 4 段 lifecycle 跟 rule chain 設計。

ProxySQL Lifecycle：每個 query 走 4 段

從 application 連 ProxySQL 到拿到 response、每個 query 都走完整 4 段：

11. Connection 接入        →  application connect 到 ProxySQL（不是 MySQL）
22. Query parse + rule match  → ProxySQL 解析 query、match query rule chain
33. Backend route          →  決定走哪個 hostgroup（primary / replica）+ 哪個 server
44. Response 返回          →  將 result set 回 application、connection 可被 reuse

每段都有獨立配置 + failure mode + 觀測 metric。ProxySQL 不是 簡單的 connection pool、是 query-aware proxy — 看得到 SQL 內容才能做 read/write split、replica lag-aware routing、query mirroring。

跟 PostgreSQL pgBouncer 比、pgBouncer 是 transaction-level pool（只看連線、不看 SQL）、ProxySQL 是 query-level proxy（看 SQL、做 routing decision）。能力不同、target use case 不同。

Stage 1：Connection 接入 — Hostgroup / Server / User 三層 schema

ProxySQL 不直接 expose backend MySQL、用 hostgroup 作為 routing 抽象。Application 不知道有幾個 backend、只知道 ProxySQL。

核心 table（在 main database）：

典型部署：

 1-- 進 ProxySQL admin (6032 port)
 2mysql -uadmin -padmin -h127.0.0.1 -P6032
 3
 4-- 設 2 個 hostgroup：10=writer、20=reader
 5INSERT INTO mysql_servers(hostgroup_id, hostname, port, weight, max_connections)
 6VALUES
 7  (10, 'primary.example.com', 3306, 1000, 200),
 8  (20, 'replica1.example.com', 3306, 1000, 100),
 9  (20, 'replica2.example.com', 3306, 1000, 100);
10
11-- 自動偵測 primary（用 read_only flag）
12INSERT INTO mysql_replication_hostgroups(writer_hostgroup, reader_hostgroup, comment)
13VALUES (10, 20, 'production cluster');
14
15-- 設 application user、預設走 reader（保守）
16INSERT INTO mysql_users(username, password, default_hostgroup, max_connections)
17VALUES ('app', 'app_password', 20, 1000);
18
19-- 套用設定到 runtime
20LOAD MYSQL SERVERS TO RUNTIME;
21LOAD MYSQL USERS TO RUNTIME;
22
23-- 持久化到 disk（重啟保留）
24SAVE MYSQL SERVERS TO DISK;
25SAVE MYSQL USERS TO DISK;

注意 ProxySQL 的 三層 state：disk（持久化）→ memory（編輯區）→ runtime（實際運作）。每次改完要 LOAD ... TO RUNTIME 才生效、SAVE ... TO DISK 才能 reboot 保留。沒 SAVE 重啟後 config 消失是新手最常踩的雷。

Stage 2：Query Parse + Rule Match — query rule engine

ProxySQL 不只 forward connection、看 SQL 內容 決定怎麼 route。Query rule 是 ordered chain、match 第一個符合的 rule。

Query rule 核心欄位：

典型讀寫分離 rule：

 1-- Rule 100: SELECT ... FOR UPDATE 必須走 primary
 2INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply)
 3VALUES (100, 1, '^SELECT.*FOR UPDATE$', 10, 1);
 4
 5-- Rule 200: 一般 SELECT 走 replica（reader）
 6INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply)
 7VALUES (200, 1, '^SELECT', 20, 1);
 8
 9-- Rule 300: BEGIN / START TRANSACTION 走 primary
10INSERT INTO mysql_query_rules(rule_id, active, match_pattern, destination_hostgroup, apply)
11VALUES (300, 1, '^(BEGIN|START TRANSACTION)', 10, 1);
12
13-- 其他（INSERT / UPDATE / DELETE）預設走 default_hostgroup（user 設的）
14-- application user default 設 10 (writer)、所以寫入自動走 primary
15
16LOAD MYSQL QUERY RULES TO RUNTIME;
17SAVE MYSQL QUERY RULES TO DISK;

Rule 順序很重要：rule_id 100 先 match、200 再 match、依此類推。Rule 200 比 100 寬鬆（任何 SELECT）、所以 FOR UPDATE 必須先 match rule 100 才不會誤送 replica。

Stage 3：Backend Route — replica lag-aware + circuit breaker

Rule match 後 ProxySQL 從 hostgroup 內挑一個 server。Backend selection 不是 pure round-robin、考慮：

• Weight：每個 server weight 比例分配（典型用於 replica capacity 不同）
• Replica lag：若 hostgroup 設 max_replication_lag、lag 超過 threshold 的 replica 自動暫時退出
• Connection count：避免某個 server connection 滿
• Server status：mysql_servers.status (ONLINE / SHUNNED / OFFLINE_SOFT / OFFLINE_HARD) 決定是否可用

Replica lag-aware routing 配置：

1-- 給整個 reader hostgroup 設 lag threshold
2UPDATE mysql_servers
3SET max_replication_lag = 5  -- 秒
4WHERE hostgroup_id = 20;
5
6LOAD MYSQL SERVERS TO RUNTIME;

ProxySQL 內部用 monitor module 定期跑 SHOW SLAVE STATUS、lag 超過 5 秒 → 該 replica 暫時退出 reader hostgroup。讀 query 自動避開 lagging replica。

Circuit breaker（自動 shun）：server 連續失敗 → ProxySQL 自動 SHUNNED、避免持續打 broken server。但 application 層仍要處理 retry、ProxySQL 不保證 query 100% 成功。

Stage 4：Response 返回 — connection multiplexing

ProxySQL 對 application connection 跟 backend connection 是 N:M 多工：

• Application connection 跟 ProxySQL 1:1
• ProxySQL 跟 backend MySQL connection 共用 pool（multiplexing）

Multiplexing 條件：

• Transaction 內：connection 綁定特定 backend（保 transaction atomicity）
• 跨 transaction：connection 可以換 backend
• SET statement 改 session variable：connection 黏死 backend（防 session state leak）
• User variable（@var）：connection 黏死 backend

結果：application 看到的是「自己有 1000 個 connection」、ProxySQL 後端可能只有 100 connection 到 MySQL。對 connection-bound MySQL（max_connections 限制）是關鍵 cost saving。

5 個 Production 踩雷

1. Query rule 順序錯亂 — FOR UPDATE 被 SELECT route 到 replica

Rule 200（^SELECT）寫在 rule 100（^SELECT.*FOR UPDATE$）之前、ProxySQL match 第一個 rule（rule 200）就停、SELECT ... FOR UPDATE 被送 replica、replica 沒 lock、application 假設有 lock 跑 race condition。

修法：

• rule_id 排序：精確 rule（多條件 regex）放小、寬鬆 rule 放大
• 用 apply=1 強制停 chain、不要讓 query 繼續往下 match
• 跑 ProxySQL SHOW PROCESSLIST + audit log 確認 routing 正確

2. Connection 漂移 — Multiplexing 把 session variable 弄丟

Application 跑 SET sql_mode=...、ProxySQL 把這 connection 暫時黏死 backend 1。下個 query ProxySQL forget、把 connection unstick、實際 forward 到 backend 2（沒 SET sql_mode）、SQL 解析行為不同、application bug。

修法：

• 用 mysql-multiplexing=false 全 disable（最簡單但浪費 connection pool 效率）
• 或在 application init 連線後跑的 SET 全列在 mysql_users.connect_init（每個 connection ProxySQL 自動跑、不會漂移）
• 避免 application 中途改 session variable、改成全部走 ProxySQL connect_init

3. Write 不小心 route 到 replica — default_hostgroup 設錯

Application user default_hostgroup 設 20 (reader)、INSERT / UPDATE / DELETE 沒 match 到任何 rule（沒寫 catch-all write rule）、走 default → 送 replica → replica 是 read-only → error。或更糟：replica 不是 read-only mode、寫入 寫到 replica 上、replication 反向不同步、data corruption。

修法：

• Application user default_hostgroup 設 10 (writer) — 寫入預設走 primary
• Replica MySQL 一定要 read_only=1（防 stale write 寫到 replica）
• 監控 mysql_query_rules match 率、寫入 query 應該大部分透過 default_hostgroup 路由、不是個別 rule

4. Runtime / disk schema drift — 改了 runtime 沒 save、重啟 config 消失

LOAD ... TO RUNTIME 跟 SAVE ... TO DISK 是兩個獨立操作。On-call 在事故中改 ProxySQL 配置（add server、調 query rule）、LOAD 套到 runtime 但忘記 SAVE、隔天 ProxySQL 重啟（OS update / crash）、config 回到 disk 版本、半夜 alert。

修法：

• 每次 LOAD ... TO RUNTIME 後立刻 SAVE ... TO DISK（變成 habit）
• 用 IaC（Terraform / Ansible）管 ProxySQL config、不要手動改 admin
• 監控：對比 runtime_mysql_servers 跟 mysql_servers（disk）、有 diff 即告警

5. Mirror traffic 副作用 — INSERT 鏡像到 staging 寫了兩次

mirror_hostgroup 把 query 鏡像送到第二個 hostgroup（不等 response、用於 shadow test 新 schema）。但 鏡像是真實執行、不是 dry-run。鏡像 INSERT 到 staging hostgroup → staging 真的多了 row。如果 staging hostgroup 接到 production 表（誤接）、production 寫入 doubled。

修法：

• Mirror 只用於 獨立 staging cluster、不混用 production schema
• Mirror 設定要 review（規則 match_pattern 跟 mirror_hostgroup 配對）
• 開 mirror 前在 staging 跑 dry-run、確認 schema 跟 production isolated

容量規劃要點

對 100 application instance × 50 connection / instance = 5000 application connection 場景：

ProxySQL 本身需要 HA：放兩個 instance 後面接 VIP（keepalived）或 HAProxy。Application 連 VIP / HAProxy、不直接連 ProxySQL hostname（單點失效）。

跟其他模組整合

跟 Replication topology

ProxySQL 透過 monitor module 自動偵測 primary（檢查 read_only flag）+ replica lag（檢查 Seconds_Behind_Master）。這個 monitor 依賴 MySQL replication 已配好（GTID + binlog ROW format）。詳見 Replication Topology。

跟 Orchestrator HA

Orchestrator 自動 failover 後新 primary 的 read_only flag 變 0、舊 primary 變 1。ProxySQL monitor 偵測到、自動把 hostgroup 10（writer）的 server 切換、application 不必改 connection string。

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

跟 OSC tool（gh-ost / pt-osc）

ProxySQL 可以 暫時 throttle application 對某張表的寫入（query rule delay 欄位）、配合 OSC tool cut-over 時段降低 metadata lock 衝突。

詳見 Online Schema Change Tools。

跟 Aurora MySQL / RDS Proxy

Aurora MySQL 推 RDS Proxy（AWS managed proxy）取代 ProxySQL — 跟 IAM 整合、failover < 30 秒。但 RDS Proxy 沒有 query routing rule engine（只做 connection pool）、不能讀寫分離。Aurora user 仍可能用 ProxySQL 在前面、再用 RDS Proxy 作 backend connection pool。

詳見 Aurora vendor page。

跟 PostgreSQL pgBouncer 對比

ProxySQL 是 query 層中介、pgBouncer 是 connection 層中介。詳見 pgBouncer 配置。

相關連結

• MySQL vendor overview
• MySQL Replication Topology（read replica routing 前提）
• MySQL Online Schema Change Tools（OSC + ProxySQL throttle 整合）
• PostgreSQL pgBouncer（PG sibling、不同抽象層）
• Aurora vendor page（RDS Proxy + ProxySQL 取捨）
• Connection Pool 卡片
• 官方：ProxySQL Documentation

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 Orchestrator failover — 自動 HA 的工具雙層架構跟 5 段 decision tree。

用詞註：Orchestrator 工具命名與 MySQL 5.7- SQL 命令（SHOW SLAVE STATUS / CHANGE MASTER TO / STOP SLAVE 等）沿用 master / slave。MySQL 8.0+ 改採 primary / replica、但 SQL syntax 仍保留別名。本文出現 master / slave 處對應 8.0 primary / replica 概念。

讀者第一個會問的問題：「Orchestrator 自己會壞嗎？壞了誰 failover Orchestrator？」這個 paradox 是 任何 HA 工具 的核心議題、PostgreSQL 的 Patroni 用 DCS（etcd / Consul）解決、MySQL 的 Orchestrator 用 內建 raft cluster 解決：

1被管的 (Layer 1):       primary MySQL → replica MySQL → replica MySQL → ...
2管理者 (Layer 2):       orchestrator instance × 3 (or 5) — 用 raft 自己選 leader
3管理者狀態存放 (Layer 3): 每個 orchestrator instance 自己有 MySQL backend (state)

Orchestrator 3 個 instance 構成 raft cluster、自己選 leader。Leader 才有 寫入 state + 發起 failover 權限、其他 instance follower 同步 state。Leader 失聯 → raft 重新選 leader（< 10 秒）、新 leader 繼續 manage MySQL topology。

跟 PostgreSQL Patroni 不同：Patroni 需要 外部 DCS（etcd / Consul）作為 source of truth、Patroni 本身 stateless；Orchestrator 內建 raft、不需要外部 DCS、但每個 orchestrator instance 需要 自己的 MySQL backend 存 state。

Orchestrator 雙層架構：管 MySQL 的 Layer 2

Layer 1 是 被管的 MySQL cluster — primary + replica 群。Layer 2 是 管理者 — orchestrator instance 群。Layer 2 監視 Layer 1、Layer 2 自己用 raft 自管。

Layer 1 對 Orchestrator 的需求：

• 所有 MySQL server 啟用 binlog + log_slave_updates（讓 Orchestrator 看得到 binlog event）
• 啟用 GTID（Orchestrator failover decision 依賴 GTID 比較進度、不用算 binlog position）
• 每個 server 有 orchestrator user（GRANT SUPER, REPLICATION CLIENT, REPLICATION SLAVE, PROCESS ON *.* TO 'orchestrator'@'%'）

Layer 2 配置：

 1# /etc/orchestrator.conf.json (簡化)
 2{
 3  "MySQLOrchestratorHost": "orchestrator-backend.example.com",
 4  "MySQLOrchestratorPort": 3306,
 5  "MySQLOrchestratorDatabase": "orchestrator",
 6
 7  # 用 backend MySQL（每個 orchestrator instance 自己一個）+ raft 同步
 8  "RaftEnabled": true,
 9  "RaftDataDir": "/var/lib/orchestrator",
10  "RaftBind": "10.0.1.10:10008",
11  "RaftNodes": [
12    "orchestrator1.example.com:10008",
13    "orchestrator2.example.com:10008",
14    "orchestrator3.example.com:10008"
15  ],
16
17  # Topology discovery
18  "DiscoverByShowSlaveHosts": true,
19  "InstancePollSeconds": 5,
20
21  # Failover detection
22  "FailureDetectionPeriodBlockMinutes": 60,
23  "RecoveryPeriodBlockSeconds": 3600,
24
25  # Failover automation
26  "RecoverMasterClusterFilters": ["*"],
27  "RecoverIntermediateMasterClusterFilters": ["*"],
28  "PreFailoverProcesses": ["/usr/local/bin/orchestrator-fence-master.sh"],
29  "PostFailoverProcesses": ["/usr/local/bin/orchestrator-notify-proxysql.sh"]
30}

Stage 1：Topology Discovery — 自動發現 + manual seed

Orchestrator 啟動後 seed 一個或多個 MySQL server、自動發現整個 topology：

• 連 seed server → SHOW SLAVE HOSTS → 發現所有 replica
• 對每個 replica 跑 SHOW MASTER STATUS + SHOW SLAVE STATUS → 建立 父子關係 graph
• 持續 poll（InstancePollSeconds=5）每 5 秒更新 topology state

Topology graph 的 node：

• Master：no slave status、被多個 replica 指
• Intermediate master：有 slave status 也有下游 replica（chained replication）
• Co-master：互相 replicate（罕見、active-passive failover 場景）
• Replica：有 slave status、無下游

Topology 可視化：Orchestrator UI（web）顯示 cluster 樹狀圖、操作員可手動 drag-and-drop replica 重新 attach。

Stage 2：Failure Detection — 區分真壞跟假壞

Orchestrator 不是 單一 ping 失敗就 failover、有 holistic detection：

Detection rule：Master 自己連不上 + 至少一個 replica 也看 master IO error → 判定 DeadMaster。單一 orchestrator 連不上 master 不觸發 — 防 orchestrator network 隔離造成的 false positive failover。

Stage 3：Failover Decision Tree — 選哪個 replica promote

判定 DeadMaster 後不是 選最近的 replica、用 decision tree：

1. GTID 最新的 replica：跟舊 master 同步最完整（用 Executed_Gtid_Set 對比）
2. 同 DC / AZ 的 replica（如果有 multi-DC 配置）
3. 手動指定的 promotion candidate（promote_rule=must 或 prefer）
4. Semi-sync ack 的 replica（如果 semi-sync 啟用）

GTID 最新是基本要求。其他規則是 tie-breaker。

Errant transaction 處理：選出的 candidate replica 如果有 errant GTID（master 沒有但 replica 有的 transaction）、Orchestrator 不會 promote 這個 replica（怕 errant transaction 變成 new master state）。改選次優 candidate。

Stage 4：Promote Action — 5 步 atomic（理想情況）

選好 candidate 後執行：

1. Fence 舊 master（pre-failover hook）：把舊 master 對外停掉、防 split-brain
2. STOP SLAVE on candidate：candidate 不再從舊 master pull binlog
3. RESET SLAVE ALL on candidate：candidate 清掉 slave 配置、變成獨立 master
4. Re-attach 其他 replica：用 CHANGE MASTER TO MASTER_HOST=<candidate>, MASTER_AUTO_POSITION=1（GTID auto-position）
5. Post-failover hook：通知 ProxySQL / HAProxy / DNS 切流量

每步任一失敗、Orchestrator 可能停在中間狀態、需要 人工介入。

Stage 5：Recovery — Old master 怎麼處理

Failover 完、舊 master 可能：

• 真的死了：物理 server 故障 / region outage → 不必處理、未來修好作為新 replica re-attach
• Network blip 後復活：舊 master 自己 仍認為自己是 master、再次接受寫入會造成 split-brain

修法：

• Fencing（必須）：pre-failover hook 把舊 master 對外 firewall 掉、或 force read_only=1、防舊 master 復活後接受寫入
• Manual reset：舊 master 復活後人工 confirm 是否變成新 master 的 replica（不要自動、自動容易誤判）

Orchestrator UI 在偵測到 errant master 時會標 warning、不會自動處理。

5 個 Production 踩雷

1. Split-brain — pre-failover hook 沒 fence 舊 master

舊 master network blip 後復活、orchestrator 已 promote 新 master、application 部分 instance 連舊 master、部分連新 master、雙寫造成 data divergence。

修法：

• Pre-failover hook 必須 fence（不是可選）：
  • 物理 fencing：透過 IPMI 重啟 / 關 server
  • Network fencing：透過 firewall rule 切斷 server 對外連線
  • MySQL fencing：SET GLOBAL read_only=1 + KILL 所有 active connection
• 用 VIP / DNS 配合：fence 完才切 VIP / DNS 到新 master、避免 application 連舊 IP
• 不依賴 application 連線 string 動態變更（DNS TTL 期間仍可能連舊 IP）

2. Pre-failover hook 失敗 — Orchestrator 該停還是該繼續

Pre-failover hook 跑失敗（fence script 因為 SSH 不通、IPMI 沒回應）。Orchestrator 有兩種策略：

• PostponeReplicaRecoveryOnLagMinutes：等 hook 成功才繼續、可能永遠 stuck
• FailMasterPromotionOnLagMinutes：放棄 promotion、留 cluster degraded（無 master）

兩者都不理想。多數 production 選 PostponeReplicaRecoveryOnLagMinutes=10：等 10 分鐘 hook 成功、超時則 alert 人工介入、不繼續 auto-promote（人工 review 才是正確選擇）。

3. Anti-flapping 窗口太短 — Master 抖動 vs 真死

FailureDetectionPeriodBlockMinutes=60：偵測一次 failure 後 60 分鐘內不再 trigger failover（即使再偵測到 failure）。預設 60 分鐘對 第一次 failover 後 master 仍不穩 的場景太長 — 60 分鐘內 master 真的死了第二次、orchestrator 不 failover。預設 60 分鐘對 網路抖動 的場景太短 — 60 分鐘內可能 multiple failover、cluster 一直在 promote。

修法：

• 評估自己 cluster 的 typical recovery time：1-2 小時、設 FailureDetectionPeriodBlockMinutes=120
• 監控 failover 頻率、單週 > 2 次表示底層問題（網路 / hardware）、不是調 anti-flapping window 解決

4. GTID errant transaction — Orchestrator 拒絕 promote 但沒講原因

Candidate replica 有 errant GTID（從別處 inject 的 transaction）、Orchestrator 拒絕 promote、log 訊息 errant GTID detected、但 沒寫實際是哪個 GTID。On-call 在事故中沒辦法 debug。

修法：

• 平時 監控 errant GTID：定期跑 pt-show-grants + GTID 比對、不要等 failover 才發現
• Orchestrator 的 OrchestratorIssuesAGtidPurge 設 true：preview mode 看 errant GTID 的位置
• Errant GTID 來源通常是 人為 inject（DBA 直接寫 replica 然後 binlog 出現）、教育 DBA 不要直接連 replica 寫

5. VIP / ProxySQL 整合斷層 — 切流量延遲

Post-failover hook 跑完 script 上報「我切完了」、但實際 VIP / DNS / ProxySQL 還沒看到變化。Application 連 stale endpoint 30 秒、寫入失敗。

修法：

• Post-failover hook 不只 trigger 切換、要 wait 切換完成：
  • VIP：等 arping 確認新 IP 已 propagate
  • ProxySQL：等 mysql_servers runtime table 更新 + 確認 monitor module 看到新 primary
  • DNS：先把 TTL 降到極短（5 秒）、再切 DNS、等 TTL 過
• Orchestrator PostFailoverProcessesFailOnError=true：hook 失敗整個 failover 標記失敗、人工檢查
• ProxySQL 用 mysql_replication_hostgroups 自動偵測 read_only flag、可不依賴 hook（推薦）

容量規劃要點

3 instance raft cluster 容忍 1 instance 故障。5 instance 容忍 2 instance 故障但 quorum cost 高、99% 場景 3 個夠用。

跟其他模組整合

跟 Replication topology

Orchestrator 100% 依賴 GTID + binlog ROW format（Replication Topology）。沒 GTID 用 binlog position、failover 時 re-pointing 容易出錯、Orchestrator 強烈建議 GTID。

跟 ProxySQL

ProxySQL 用 mysql_replication_hostgroups 自動偵測 read_only flag — orchestrator 切完新 master 後、ProxySQL monitor module 自動看到新 master 的 read_only=0、自動更新 routing、application 不用改 connection string。

這個 無需 post-failover hook 通知 ProxySQL 的整合是 ProxySQL + Orchestrator 組合的最大優勢、比手動 hook 通知 VIP / DNS 可靠。

跟 Patroni（PostgreSQL 對應）

兩者角色相同、設計取捨不同。Patroni 對 DCS 高依賴、Orchestrator 對自己 backend MySQL 高依賴。

跟 RDS / Aurora MySQL

AWS RDS / Aurora 內建 multi-AZ failover、不用 Orchestrator。Aurora failover < 30 秒、RDS failover ~60-120 秒。Aurora 把 replication / failover 整套封進 storage layer、application 看到的是 reader endpoint + writer endpoint。

詳見 Aurora vendor page。

跟 Vitess

Vitess shard 內部用 VTOrc（Vitess fork of Orchestrator）— 概念跟 Orchestrator 一致、針對 Vitess topology metadata 適配。

詳見 Vitess sharding 設計 篇（待寫）。

相關連結

• MySQL vendor overview
• MySQL Replication Topology（GTID 是 Orchestrator pre-requisite）
• MySQL ProxySQL 配置（Orchestrator + ProxySQL 自動失效切換組合）
• PostgreSQL Patroni HA（PG sibling、不同 HA 機制）
• Aurora vendor page（managed MySQL、Orchestrator 不需要）
• quorum 卡片 / failover 卡片
• 官方：orchestrator GitHub / orchestrator docs

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 InnoDB engine tuning — 4 個影響最大的 knob 跟對應 production 行為。

開場：常見痛點

一個 100 GB MySQL DB、64 GB RAM 的 server、p99 query latency 從 5ms 飆到 50ms。第一直覺是 server overload — 但 CPU < 30%、disk IO 50 IOPS。為什麼慢？

打開 SHOW VARIABLES LIKE 'innodb_buffer_pool_size'：134217728（128 MB）。對 64 GB RAM server、buffer pool 只用了 128 MB、剩 99.9% 的 working set 每次 query 都要從 disk 讀。CPU 閒、disk 沒滿、是因為 MySQL 自己不用 RAM — 用 InnoDB 預設值跑 100 GB DB 等於 disk-only 模式。

這個案例展示 InnoDB tuning 的核心：MySQL 預設值是 為 16 GB RAM 設計、production server RAM 越大、預設值離 optimal 越遠。

4 個 critical knob

對 90% production case、調這 4 個就解決大部分 InnoDB 性能問題：

其他 knob（innodb_thread_concurrency / innodb_buffer_pool_instances / innodb_read_io_threads 等）也有影響、但對多數 case 先把這 4 個調對 比微調其他 20 個重要。

Knob 1：Buffer pool — 把 working set 拉進 RAM

InnoDB buffer pool 是 page cache — 從 disk 讀過的 16 KB page 快取在 RAM、下次 query 直接 RAM 讀。Buffer pool 越大、cache hit ratio 越高、disk IO 越少。

Sizing：

• Dedicated MySQL server：RAM 70-80%（剩 20-30% 給 OS / MySQL 其他結構 / connection buffer）
• Shared server：RAM 30-50%（看其他 process 需求）
• Container / Kubernetes：對 container memory limit 70%（不是 host RAM）

1# 64 GB RAM dedicated server
2innodb_buffer_pool_size = 48G
3innodb_buffer_pool_instances = 8  # 分 8 個 instance 降 mutex contention（每 instance 6 GB）

Buffer pool warm-up：MySQL 重啟後 buffer pool 是空的、要慢慢從 disk 把熱資料拉回 RAM。預設 5.7+ MySQL 啟動時 dump buffer pool LRU list 到 disk、重啟時 自動 restore：

1innodb_buffer_pool_dump_at_shutdown = 1
2innodb_buffer_pool_load_at_startup = 1
3innodb_buffer_pool_dump_pct = 75  # 只 dump 最 hot 的 75% page list

沒這個 warm-up、重啟後第 1 個小時 query latency 都偏高、application 看到 p99 spike。

Knob 2：Redo log — flush 頻率跟寫吞吐

InnoDB 寫入 先寫 redo log（順序寫）、再非同步寫到 data file（隨機寫）。Redo log 滿了強迫 flush data file、flush 期間寫吞吐降。

innodb_log_file_size 控制每個 log file 大小（預設 2 個 file）：

• 5.7：預設 48 MB × 2 = 96 MB total
• 8.0：預設仍是 48 MB × 2、8.0.30+ 改用動態 innodb_redo_log_capacity（default 100 MB total）

對 5K WPS server、預設容量可能 每分鐘 flush 一次、寫吞吐持續 stall。提高到 1-4 GB total、flush 改成每 30 分鐘一次、寫吞吐穩定。

1innodb_log_file_size = 2G       # 大寫吞吐 server 設 1-4 GB
2innodb_log_files_in_group = 2   # 預設 2 個就夠
3innodb_log_buffer_size = 64M    # log 寫 disk 前的 RAM buffer

Trade-off：log file 越大、recovery 時間越長（crash 後 InnoDB 要 replay 全部 log）。1 GB log 通常 < 1 分鐘 recovery、4 GB 可能 5 分鐘以上。SSD / NVMe 這個 trade-off 不嚴重、HDD 要注意。

MySQL 8.0+ 改進：log file 可動態調整（不用重啟）、且 automatic redo log writer threads 降低 mutex contention。

Knob 3：Flush method — ACID vs 吞吐

innodb_flush_log_at_trx_commit 控制 每個 transaction commit 時要不要 flush log 到 disk：

• 1（預設）：每次 commit fsync log file → zero data loss on crash
• 2：每次 commit 寫 log file（但 OS-level cache、不 fsync）→ server crash 不丟、OS crash 丟 1 秒
• 0：每秒 fsync 一次 → 任何 crash 丟 1 秒

sync_binlog 對應 binlog（不是 InnoDB log）：

• 1（建議）：每次 commit fsync binlog
• 0：依賴 OS sync、容易丟 binlog → replication / CDC 風險

Production 組合：

多數 production 用 1 + 1、雖然慢但 簡單可預測。改成 2 + 1 之前要明確 能容忍 1 秒 data loss、且通常 review 過 Disaster Recovery Plan。

Knob 4：IO capacity — 適配儲存

InnoDB 後台 flush 速度受 innodb_io_capacity 限制：

• innodb_io_capacity（一般）：後台 flush 目標 IOPS
• innodb_io_capacity_max（突發）：emergency flush 上限

對應儲存類型：

預設 200 / 2000 是 為 HDD 設計、SSD / NVMe server 用預設值 = InnoDB 自我限速、flush 慢、寫入瓶頸。

1# NVMe SSD server
2innodb_io_capacity = 10000
3innodb_io_capacity_max = 40000
4innodb_flush_neighbors = 0  # NVMe 不需要 group flush 相鄰 page

5 個 Production 踩雷

1. Buffer pool 沒 warm-up — 重啟後 1 小時 p99 飆

MySQL 重啟（OS upgrade / config change / failover）後、buffer pool 是空的、所有 query 第一次都 disk 讀、p99 latency 飆 5-10x、application 看到 timeout。

修法：

• 啟用 innodb_buffer_pool_dump_at_shutdown=1 + innodb_buffer_pool_load_at_startup=1
• 對 沒 graceful shutdown 的 crash（OOM / kernel panic）、buffer pool 沒 dump、warm-up 後第一個小時仍辛苦
• 重要 server 重啟前手動 dump：SET GLOBAL innodb_buffer_pool_dump_now=ON
• 對於不能容忍 cold cache 的場景、failover 前 先 pre-warm new primary（用 query replay 把 hot data 拉到 buffer pool）

2. Log file size 設太小 — checkpoint storm

innodb_log_file_size=48M 預設、高寫吞吐 server log 每分鐘 flush 一次、flush 期間 checkpoint storm — 寫吞吐降 50%、p99 暴增。錯誤訊號是 innodb_log_waits 持續 > 0。

修法：

• 監控 SHOW STATUS LIKE 'Innodb_log_waits' — 應該長期接近 0
• 提高 innodb_log_file_size 到 1-4 GB（依寫吞吐）
• 8.0+ 可動態調整、5.7 需要 正常 shutdown 後改、開啟前先 dump buffer pool（避免 cold cache）

3. sync_binlog=0 換速度 — replication 永久 broken 風險

開發 / staging 改 sync_binlog=0（加快寫入）、後來複製到 production 配置、production 同樣 sync_binlog=0。OS crash 後 binlog 缺最後幾秒 transaction、replica 跟 primary GTID set diverge、replication broken、要 重建 replica from base backup（小時級 recovery）。

修法：

• Production 永遠用 sync_binlog=1、不要為了寫吞吐犧牲 binlog durability
• 開發 / staging 配置跟 production 隔離、不要直接 copy config
• Replica 失聯後 用 GTID 自動 re-attach（不是 binlog position）— 仍然需要 binlog 完整、sync_binlog=0 仍是風險

4. IO scheduler — 不是 InnoDB tuning 但影響大

Linux noop / deadline / cfq IO scheduler 對 SSD / NVMe 影響大：

• cfq（traditional spinning disk default）：對 SSD 嚴重 bottleneck
• deadline：對 SSD 較好、但有 latency cap
• noop / none：對 NVMe 最好（讓 device 自己處理 queue）

Production check：

1cat /sys/block/sda/queue/scheduler
2# 應該顯示： [none] mq-deadline (NVMe)
3# 或：         noop deadline [cfq] (cfq 是錯的)

不是 InnoDB knob、但影響 InnoDB IO behavior > 30%。InnoDB tuning 前先確認 OS-level IO scheduler 對。

5. Undo log 膨脹 — purge 跟不上

Undo log 紀錄 未來可能 rollback 需要的舊版本 row。長 transaction（hours-level）讓 undo log 持續累積、不能 purge、最後 InnoDB tablespace 膨脹幾 GB、disk 滿。

訊號：

• SHOW ENGINE INNODB STATUS 看 History list length 持續成長（正常 < 1000、異常 millions）
• information_schema.innodb_metrics 的 trx_rseg_history_len

修法：

• 找 long-running transaction：SELECT * FROM information_schema.innodb_trx WHERE trx_started < NOW() - INTERVAL 1 HOUR
• KILL 該 transaction（謹慎、可能 application bug）
• 8.0+ 用 separate undo tablespace（innodb_undo_tablespaces）、不污染 main tablespace、且可以 truncate

容量規劃要點

對 64 GB RAM、NVMe SSD、5K WPS、100 GB DB 的 server：

 1# my.cnf production-ready baseline
 2[mysqld]
 3# Buffer pool (75% RAM)
 4innodb_buffer_pool_size = 48G
 5innodb_buffer_pool_instances = 8
 6innodb_buffer_pool_dump_at_shutdown = 1
 7innodb_buffer_pool_load_at_startup = 1
 8
 9# Redo log
10innodb_log_file_size = 2G
11innodb_log_files_in_group = 2
12innodb_log_buffer_size = 64M
13
14# Flush behavior
15innodb_flush_log_at_trx_commit = 1
16sync_binlog = 1
17innodb_flush_method = O_DIRECT  # 跳過 OS page cache 避免 double cache
18
19# IO capacity (NVMe)
20innodb_io_capacity = 10000
21innodb_io_capacity_max = 40000
22innodb_flush_neighbors = 0
23innodb_lru_scan_depth = 1024
24
25# Concurrency
26innodb_thread_concurrency = 0  # 0 = no limit (8.0+ 推薦)
27innodb_read_io_threads = 8
28innodb_write_io_threads = 8
29
30# 額外
31innodb_file_per_table = 1
32innodb_strict_mode = 1

跨不同 server spec、buffer_pool_size / io_capacity 隨硬體調整、其他 knob 變動小。

跟其他模組整合

跟 Replication topology

sync_binlog=1 + innodb_flush_log_at_trx_commit=1 是 durability baseline、影響 Replication Topology 的 primary durability。Semi-sync 加在這基礎上提供 跨 server durability。

跟 ProxySQL

ProxySQL connection pool 降低 MySQL connection 開銷、但 每個 connection 仍消耗 8-10 MB RAM（thread stack + session buffer）。Buffer pool 設 75% RAM 後、剩 25% 給 connection / temporary buffer / OS。Connection 太多會擠掉 buffer pool。

詳見 ProxySQL 配置。

跟 Aurora MySQL

Aurora 改寫 InnoDB storage layer、上方 knob 大多 Aurora 自動管理：

• Buffer pool size：Aurora compute instance 自動配
• Redo log：Aurora 自己的 distributed log、不用 innodb_log_file_size
• sync_binlog / innodb_flush_log_at_trx_commit：Aurora storage layer 保證 durability、應用層 knob 影響小

Aurora user 仍可 tune innodb_buffer_pool_size 等、但操作面從 InnoDB 內部議題變成 Aurora instance class 選擇。詳見 Aurora vendor page。

跟 OSC tool

InnoDB tuning 不直接影響 OSC 工具行為、但 log file size 太小 時 gh-ost / pt-osc 寫 ghost table 容易 trigger checkpoint storm、放慢整個 schema migration。詳見 Online Schema Change Tools。

觀測 metric

SHOW STATUS LIKE + Performance Schema 提供：

• Innodb_buffer_pool_read_requests / _reads → cache hit ratio = 1 - reads/read_requests、應該 > 99%
• Innodb_log_waits → checkpoint pressure、應該 = 0
• Innodb_log_write_requests / _writes → log buffer 效率
• Innodb_rows_inserted / _updated / _read → workload 形狀
• Innodb_row_lock_waits / _time → lock contention

把這些丟進 Datadog / Prometheus 透過 mysqld_exporter / Percona Monitoring 持續 trend。

相關連結

• MySQL vendor overview
• MySQL Replication Topology（sync_binlog 跟 replication 互動）
• MySQL ProxySQL 配置（connection 跟 buffer pool 爭 RAM）
• Aurora vendor page（managed MySQL、InnoDB tuning 部分轉手）
• PostgreSQL Autovacuum Tuning（PG sibling、不同 engine 內部 tuning）
• 官方：InnoDB Configuration / Percona Tuning Guide

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 CDC — Maxwell / Debezium 怎麼讀 binlog 產生 event stream。

MySQL CDC 的核心定位是 binlog consumer。

這個誤解來自跟 PostgreSQL CDC（Logical Replication + Debezium）混用名詞。PG 的 logical decoding 是 MySQL 沒有的能力 — PG 有 logical event（INSERT / UPDATE / DELETE 加上欄位 metadata）、輸出格式是 logical（人可讀、schema-aware）。MySQL 的 binlog 是 physical — 紀錄的是 row 的 binary image、不帶 schema 資訊。

Maxwell / Debezium 對 MySQL 是 binlog 第二消費者：

1Primary MySQL → binlog
2              ├→ Replica 1（讀 binlog 同步）
3              ├→ Replica 2
4              └→ Maxwell / Debezium（讀 binlog 解析、發 Kafka）

跟 replica 同一份 binlog stream，並非 separate logical decoding output。這個結構決定 CDC consumer 的設計：必須 自己處理 schema（從 information_schema 拉、跟 binlog event 對齊）、必須 自己 track position（binlog file + position 或 GTID）。

Binlog format：STATEMENT / ROW / MIXED

MySQL binlog 有 3 種 format、CDC 只能用 ROW：

ROW 是 CDC 唯一選擇、production 強制：

1binlog_format = ROW
2binlog_row_image = FULL  # FULL (all columns) / MINIMAL (only changed) / NOBLOB
3log_bin_use_v1_row_events = 0  # 用新版 event format

binlog_row_image 取捨：

• FULL：每個 row event 包含所有 column（before + after）、binlog 大、CDC 完整
• MINIMAL：只包含 changed column + primary key、binlog 省 30-50% 空間、CDC 看不到 未變 column
• NOBLOB：跟 FULL 一樣但 BLOB / TEXT column 只在 changed 時包含、平衡選擇

對 CDC 需要 full row payload（例如下游 search index 重建）必須 FULL。對 純 audit log 可以 MINIMAL。

ROW format 的 raw event 結構

Binlog ROW event 的資料形狀是 binary row image，而非 INSERT INTO orders VALUES (1, ‘foo’, 100)：

1TABLE_MAP_EVENT     - 對應 table schema metadata (table id + column type)
2                      ↓ 接續同一個 transaction 內所有 row event
3WRITE_ROWS_EVENT    - INSERT 的新 row image（column values）
4UPDATE_ROWS_EVENT   - UPDATE 的 before + after image
5DELETE_ROWS_EVENT   - DELETE 的 row image（被刪的 row）
6XID_EVENT           - transaction commit marker

CDC consumer（Maxwell / Debezium）必須：

1. 接收 binlog event stream
2. 看到 TABLE_MAP_EVENT 從中拿 table id → 對應 table name（cache 一份）
3. 看到 WRITE/UPDATE/DELETE_ROWS_EVENT 用 table id 反查 schema、把 binary 解析成 column value
4. 包成 JSON / Avro / Protobuf 推到 Kafka

關鍵：table schema 不在 binlog 內、CDC consumer 必須 獨立查 information_schema。如果 schema 變了（ALTER TABLE）、CDC 必須 invalidate cache、重新查、否則新 column 的 row event 解析錯亂。

Maxwell vs Debezium

兩個是 MySQL CDC 主流選擇、不同設計取捨：

選擇邏輯：

• 只用 MySQL + 想要 simple operations → Maxwell
• 已用 Kafka Connect、需要 schema registry、跨多種 DB → Debezium
• 需要 Avro / Protobuf schema 嚴格 governance → Debezium

配置 step-by-step（Debezium MySQL connector）

Debezium 是 Kafka Connect plugin、整套 stack：

 1# debezium-mysql.json - 部署到 Kafka Connect REST API
 2{
 3  "name": "orders-mysql-connector",
 4  "config": {
 5    "connector.class": "io.debezium.connector.mysql.MySqlConnector",
 6    "database.hostname": "primary.example.com",
 7    "database.port": "3306",
 8    "database.user": "debezium",
 9    "database.password": "...",
10    "database.server.id": "184054",          # 唯一 server ID (跟 MySQL replica 一樣)
11    "topic.prefix": "production",            # Debezium 2.x（舊 1.x 用 database.server.name）
12    "database.include.list": "orders_db",
13    "table.include.list": "orders_db.orders,orders_db.payments",
14
15    "database.history.kafka.bootstrap.servers": "kafka:9092",
16    "database.history.kafka.topic": "dbhistory.orders",
17    "include.schema.changes": "true",
18
19    "snapshot.mode": "initial",              # 或 schema_only / when_needed / never
20    "snapshot.locking.mode": "minimal",      # 避免 FLUSH TABLES WITH READ LOCK
21
22    "gtid.source.includes": "...",           # 可選 GTID filter
23    "tombstones.on.delete": "true",          # DELETE event 同 partition 跟一個 null tombstone
24    "decimal.handling.mode": "double"        # DECIMAL 處理: precise / string / double
25  }
26}

deploy：

1curl -X POST -H "Content-Type: application/json" \
2  --data @debezium-mysql.json \
3  http://kafka-connect:8083/connectors

Output topic：production.orders_db.orders / production.orders_db.payments 等 — 每張 table 一個 topic。

配置 step-by-step（Maxwell）

Maxwell 簡單很多：

 1maxwell \
 2  --host=primary.example.com \
 3  --user=maxwell \
 4  --password=... \
 5  --producer=kafka \
 6  --kafka.bootstrap.servers=kafka:9092 \
 7  --kafka_topic="maxwell.%{database}.%{table}" \
 8  --filter='exclude: *.*, include: orders_db.*' \
 9  --gtid_mode=true \
10  --output_ddl=true \
11  --output_xoffset=true

Maxwell event format：

 1{
 2  "database": "orders_db",
 3  "table": "orders",
 4  "type": "update",
 5  "ts": 1715000000,
 6  "xid": 12345,
 7  "commit": true,
 8  "data": { "id": 1, "status": "shipped", "amount": 100.50 },
 9  "old": { "status": "pending" }
10}

Debezium 對應的 event 格式更複雜（envelope + before + after + source + ts_ms 各 nested）、但跟 schema registry 整合好。

5 個 Production 踩雷

1. Binlog retention 太短 — CDC consumer 落後就 re-bootstrap

CDC consumer 失聯（Kafka Connect cluster down、network issue）超過 binlog retention（預設 binlog_expire_logs_seconds=2592000、30 天、但有些 production 縮短到 1 天）、需要的 binlog event 已被 purge、consumer error。

修法：

• Production binlog retention >= 7 天（避免為了 disk 過度縮短）
• 監控 Master_Log_File 是否還在（如果 retention 設 7 天、確認當前 file 仍存在）
• CDC consumer 失聯 alert 設 早於 retention 期（例如 6 天告警、給 24 小時修）
• 真的 missed binlog、必須 re-snapshot table（用 Debezium snapshot.new.tables）— 24 小時級工作

2. DDL event 處理 — schema change 跟 row event 對齊

ALTER TABLE orders ADD COLUMN status VARCHAR(20) 之後、UPDATE_ROWS_EVENT 多一個 column。CDC consumer 如果還用舊 schema cache、解析 row 時欄位數對不上、event 丟。

修法（Debezium）：

• include.schema.changes=true：DDL 進獨立 topic、consumer 監聽更新自己的 schema cache
• database.history.kafka.topic：Debezium 自己 track schema 歷史

修法（Maxwell）：

• --output_ddl=true：DDL 也進 stream、downstream 看到 DDL event 自己更新
• 沒有內建 schema history、要 application 層處理

修法（兩者通用）：

• 用 Online Schema Change Tools 取代直接 ALTER — 工具操作的 DDL 對 CDC consumer 更可預期
• Schema 改動 優先 add column 為 nullable、避免 backfill 期間 CDC consumer 看到 mid-state

3. binlog_row_image=MINIMAL 讓下游錯亂

MINIMAL 省 binlog 空間、但 row event 只含 changed column。下游 search index 重建 需要 full row payload 的場景下、MINIMAL 看不到未變的 column、index 缺欄位。

修法：

• CDC 需要 full payload 的場景 必須 FULL、這項成本要納入容量規劃
• 如果空間真緊、考慮 NOBLOB（BLOB / TEXT 只在 changed 時包含、其他 column 仍 FULL）
• 統一設定：production 全部 server 同一 binlog_row_image 設定

4. Kafka producer 跟 binlog reader 速度差 — lag 累積

Binlog reader 從 MySQL 讀 1000 event/sec、Kafka producer 寫得只有 800 event/sec、CDC consumer 自身 lag 累積、最終 disk 滿（producer 內部 buffer）。

修法：

• 監控 CDC consumer lag：對 Debezium 看 Kafka Connect 的 source-record-poll-rate vs source-record-write-rate
• Kafka producer tuning：batch.size / linger.ms / compression.type=snappy
• Kafka broker capacity：partition 數量 ≥ Debezium task 數量、避免 partition 瓶頸
• 避免把 過多 table 給單一 Debezium connector — 用 table grouping（按 traffic 拆 connector）

5. Schema change 跟 downstream consumer 不同步

CDC producer（Debezium）正確處理了 schema change、但 downstream Kafka consumer 用舊 schema deserialize、新 column 看不到 / type 解析錯。

修法：

• 用 Schema Registry（Confluent / Apicurio）+ Avro：consumer 訂閱 schema、自動 evolve
• 不用 schema registry 時、CDC payload 設計 backward-compatible（新 column 為 optional）
• Application 層 schema change protocol：Expand / Contract — 先加 column、deploy consumer 認 column、再 backfill、最後 application 寫新 column
• 大型 schema change 跨多服務、建議 先 freeze CDC stream、做 schema migration、resume stream（極端但確定）

容量規劃要點

對 100K WPS server、CDC pipeline cost 大致是 MySQL infra 的 5-10%。

跟其他模組整合

跟 Replication topology

CDC 是 binlog 第二消費者、需要 GTID + binlog ROW format（Replication Topology）。Debezium / Maxwell 都偏好從 replica 讀 binlog（不增加 primary 負擔）、但要小心 replica lag 加在 CDC lag 上。

跟 OSC tool

gh-ost / pt-osc 跑 schema change 時、會在 binlog 留下大量 row event（copy 既有 row 到 ghost）。CDC consumer 看到這些 event 是 normal-looking INSERT、可能誤觸發 downstream side effect。

修法：

• CDC consumer 過濾 ghost table prefix（_orders_new / _orders_gho）— 不發 downstream
• 或暫停 CDC 期間跑 OSC（用 Debezium pause API）

跟 PostgreSQL Logical Replication + Debezium

詳見 PostgreSQL Logical Replication + Debezium — 這是 sibling 對照，用來區分不同 abstraction。

跟 Aurora MySQL

Aurora MySQL 5.7 / 8.0 都支援 binlog + GTID、CDC 可用。但 Aurora 推薦走 Aurora-native database activity streams（不同 abstraction）— 跟 Debezium 共存但有 overlapping。生產上 Debezium 仍是 cross-cloud 跟 vendor-neutral 選項、優先用 Debezium。

詳見 Aurora vendor page。

Production case：Shopify sharded MySQL CDC

Sharded MySQL CDC 的核心責任是把多個 shard 的 binlog 轉成可消費、可回放、可觀測的事件流。Shopify Debezium CDC over sharded MySQL 提供的工程訊號是 100+ shard、約 150 個 Debezium connector、BFCM 期間 100K records/sec，以及 snapshot lock 與 oversized payload 對 CDC pipeline 的壓力。

這個案例要回收到三個操作判準。第一，connector 數量應跟 shard 拓撲一起設計，避免單一 connector 變成跨 shard bottleneck。第二，snapshot window 要排進 schema migration 與 event consumer 的變更計畫，避免 initial snapshot 把 production read path 壓滿。第三，oversized payload 要在 schema / outbox / topic 分流階段處理，避免 Kafka partition 與 downstream consumer 同時承受大訊息。

Shopify 案例的下一步路由是把本篇和 Database Sharding 一起讀。若讀者關心 broker 層的 partition、consumer lag 與 replay 策略，接到 Kafka vendor；若關心資料庫端壓力，回到 Replication Topology 與 Online Schema Change Tools。

相關連結

• MySQL vendor overview
• MySQL Replication Topology（binlog ROW + GTID 是 CDC pre-requisite）
• MySQL Online Schema Change Tools（OSC + CDC 整合）
• PostgreSQL Logical Replication + Debezium（PG sibling、不同 abstraction）
• Outbox pattern 卡片（CDC 跟 outbox 在 application-level event publishing 的關係）
• Expand / Contract 卡片（schema migration 跟 CDC consumer）
• 官方：Debezium MySQL Connector / Maxwell

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 Vitess sharding — 4 個 component 協作的完整 sharding 系統。

問題情境：MySQL 寫吞吐撞上 single primary 上限

MySQL primary 單機極限大致 50K-100K WPS（依 schema / hardware）。超過這個級別、選項三條：

1. Application 層 sharding：每張 table 自己決定怎麼分片、application 寫 routing logic、跨 shard query / migration 都要自己處理
2. Vitess：proxy layer 自動 routing、cross-shard query 可選自動 split、resharding 自動化
3. Distributed SQL（CockroachDB / Spanner / Aurora DSQL）：跟 MySQL 不同 engine、application 改 driver

選 Vitess 的核心 driver：保留 MySQL wire protocol + 應用層幾乎不必改 + 透明分片。代價是 4 個 component 的 operational complexity — Vitess 的責任範圍是完整分散式系統，而非單純 proxy。

閱讀本文前可先對齊 Database Sharding 的 shard key、routing、resharding 與 cross-shard query 語意；容量失衡時再接 Hot Partition。

Vitess 四件套：每個 component 的責任

 1                        ┌─────────────────┐
 2   Application ────→    │     VTGate      │  ← 對外 MySQL wire protocol
 3                        │  (proxy + parse + route + aggregate)  │
 4                        └────┬─────┬──────┘
 5                             │     │
 6                ┌────────────┘     └──────────────┐
 7                ▼                                 ▼
 8        ┌──────────────┐                  ┌──────────────┐
 9        │   VTTablet   │                  │   VTTablet   │
10        │ (per-MySQL   │                  │ (per-MySQL   │
11        │  sidecar)    │                  │  sidecar)    │
12        └─────┬────────┘                  └─────┬────────┘
13              │                                 │
14              ▼                                 ▼
15        ┌──────────────┐                  ┌──────────────┐
16        │    MySQL     │                  │    MySQL     │
17        │  (Shard -80) │                  │  (Shard 80-) │
18        └──────────────┘                  └──────────────┘
19
20   Topology Service (etcd / Consul / ZooKeeper)
21   ↑↓ 所有 component 共享 metadata
22   VSchema：keyspace 結構、shard 範圍、Vindex 定義

VTGate — query routing layer

對 application 看起來像 MySQL（同樣 port、同樣 wire protocol、同樣 query 語法）、實際是 stateless proxy。每個 query VTGate：

1. Parse SQL → 找出 routing key（從 WHERE column 拿）
2. 查 VSchema → 計算 routing key 對應的 shard
3. 把 query 送該 shard 的 VTTablet
4. 等 response、aggregate（如果是 cross-shard query）、回 application

Stateless 設計 → VTGate 可以隨意 scale、放 N 個前面接 LB。多數 production 部署 3-10 個 VTGate per region。

VTTablet — per-MySQL agent

每個 MySQL instance 旁邊都跑一個 VTTablet。VTTablet 責任：

• 把 MySQL primary 標記、上報給 topology
• 接 VTGate 的 query、轉發給 local MySQL
• 跑 connection pool（VTGate 跟 VTTablet 之間少量連線、VTTablet 跟 local MySQL 共享 connection）
• 跑 query plan cache / transactional consistency check
• 處理 online schema change（Vitess 內建 OSC）
• 跟 VTOrc（fork of Orchestrator）配合做 failover

VTTablet 是 Vitess 跟 MySQL 唯一連接點 — 沒 VTTablet 直接連 MySQL 不在 Vitess 管理下。

VReplication — 跨 shard 資料移動

VReplication 是 Vitess 跨 shard / 跨 keyspace / 跨 cluster 資料移動引擎、底層用 MySQL binlog。用途：

• Resharding：把 shard -80 拆成 -40 + 40-80、VReplication 自動拆 binlog event 對應 shard
• Materialized view：cross-shard aggregation 預計算
• MoveTables：跨 keyspace 移 table（schema-level migration）
• VStream：CDC、binlog event 對外輸出（可接 Kafka / Debezium）

VReplication 的主要使用者是 Vitess operator，它和 application 行為直接相關（resharding 期間有 write split 行為）。

VSchema — sharding metadata

VSchema 是 keyspace 內 哪張 table 怎麼 shard 的定義、JSON 格式存 topology service。例子：

 1{
 2  "sharded": true,
 3  "vindexes": {
 4    "hash": {
 5      "type": "hash"
 6    }
 7  },
 8  "tables": {
 9    "orders": {
10      "column_vindexes": [
11        {
12          "column": "user_id",
13          "name": "hash"
14        }
15      ]
16    },
17    "users": {
18      "column_vindexes": [
19        {
20          "column": "user_id",
21          "name": "hash"
22        }
23      ]
24    }
25  }
26}

orders.user_id 跟 users.user_id 用同一個 Vindex（hash）+ 同一個 column → 同 user_id 的 orders + users 落在同 shard、可以 JOIN 不跨 shard。

Vindex：Vitess 的 sharding function

Vindex 是 Vitess 的 shard key 計算函數。內建多種：

最常用：hash（primary key）+ lookup_hash（secondary access pattern）。

Keyspace / Shard / Tablet 階層

 1Keyspace (邏輯 database)
 2   └── Shards
 3        ├── -80 (shard range 0-128)
 4        │     ├── Primary tablet (1 MySQL primary)
 5        │     ├── Replica tablet × 2
 6        │     └── RDOnly tablet × 1 (analytics)
 7        └── 80- (shard range 128-256)
 8              ├── Primary tablet
 9              ├── Replica tablet × 2
10              └── RDOnly tablet × 1

Shard range 用 binary hex prefix（-80 表示 0 到 0x80、80- 表示 0x80 到 max）— 給 resharding 留 split 餘地（-80 可切成 -40 + 40-80）。

Tablet type：

• Primary：寫入入口
• Replica：read traffic（Vitess query rules 控制）
• RDOnly：純 analytics / backup / VReplication source、低 SLA、不上 production read traffic

配置 step-by-step（local cluster）

Production 通常用 Kubernetes operator（vitess-operator）部署、但理解概念用 local cluster 最快：

 1# 用 vtctldclient 操作（替代舊的 vtctlclient）
 2
 3# 1. 建 unsharded keyspace
 4vtctldclient CreateKeyspace --durability-policy=semi_sync commerce
 5
 6# 2. 從一個 MySQL primary 開始（unsharded）
 7vtctldclient ApplySchema --sql="CREATE TABLE orders (id INT PRIMARY KEY, user_id INT)" commerce
 8
 9# 3. 把 keyspace 改成 sharded、定義 VSchema
10vtctldclient ApplyVSchema --vschema='{
11  "sharded": true,
12  "vindexes": {"hash": {"type": "hash"}},
13  "tables": {
14    "orders": {
15      "column_vindexes": [{"column": "user_id", "name": "hash"}]
16    }
17  }
18}' commerce
19
20# 4. 觸發 resharding：unsharded → 2 shards (-80, 80-)
21vtctldclient Reshard --workflow=initial-shard create \
22  --source-shards="commerce/0" \
23  --target-shards="commerce/-80,commerce/80-"
24
25# 5. 等資料 copy 完（VReplication 跑）
26vtctldclient Workflow --keyspace=commerce show initial-shard
27
28# 6. SwitchTraffic：先切 RDOnly → 再切 Replica → 最後切 Primary
29vtctldclient Reshard --workflow=initial-shard switchtraffic \
30  --tablet-types="rdonly,replica"
31vtctldclient Reshard --workflow=initial-shard switchtraffic \
32  --tablet-types="primary"
33
34# 7. 完成、cleanup old shard
35vtctldclient Reshard --workflow=initial-shard complete

實際 production 走 Vitess Kubernetes operator、用 VitessCluster CRD 宣告 desired state、operator 自動操作上面這些 step。

5 個 Production 踩雷

1. Cross-shard transaction — Vitess 不支援 atomic（預設）

兩個 user 的 order 在不同 shard、BEGIN; UPDATE orders WHERE user_id=1; UPDATE orders WHERE user_id=2; COMMIT; 跨兩個 shard。Vitess 預設 不保證 atomic — 兩個 shard 各自 commit、可能一個成功一個失敗、application 看到 partial state。

修法：

• 避免 cross-shard transaction：schema design 讓 transaction boundary 落在單一 shard 內
• 啟用 atomic 2-phase commit（Vitess transaction_mode=TWOPC、實驗性、performance penalty 大）
• 大規模需要 atomic 的場景應該換 distributed SQL（CockroachDB / Spanner），讓資料庫層承擔跨節點一致性

2. VStream lag — Resharding 期間 CDC 落後

Resharding 過程 VReplication 大量寫 binlog event、application 本來在用 的 VStream（接 Kafka 等）共享同 binlog stream、可能 lag。Downstream consumer 看到 stale data 1-2 小時。

修法：

• Resharding 期間 暫停非關鍵 VStream（analytics ETL 可暫停、real-time recommendation 需要保留）
• 確認 binlog disk capacity > resharding 期間預估 binlog 量 × 2（buffer）
• Resharding 完成後 手動驗證 VStream offset 已 catch up，把驗證結果留成 cutover evidence

3. Vindex 不均勻 — Hot shard

Vindex 預設 hash 對 primary key 均勻分布、但對 natural key（country / region / company_id 等）可能不均勻。10 個 country、其中 1 個 country 佔 80% traffic、單一 shard 永遠 hot。

修法：

• Composite Vindex：combine country + user_id 兩 column 作為 shard key、user-level 仍均勻
• Synthetic shard key：application 層加 sharding_key=hash(actual_key) % N、控制分布
• 監控 per-shard QPS：vtctldclient ShowVDiff + Prometheus exporter
• Hot shard 出現後 Vitess 可以 resharding 解（split hot shard 為 2 個小 shard）、但工作量大

4. Resharding 切流量瞬間 deadlock

Resharding 最後的 SwitchTraffic 切 primary 階段、舊 shard 仍接 write、Vitess 切 routing、Application 一瞬間連兩個 shard、相同 user_id 寫入可能跑兩邊、deadlock 或 lost update。

修法：

• SwitchTraffic 用 ReverseTraffic 預備：先 switch、確認問題後可 reverse 回去
• 切流量 只在 known quiet period（夜間 / 週末早上）
• VTGate --retry-count=2 + --track-vtgate-deadlock-events：deadlock 自動 retry、不暴露給 application
• 真的失敗用 Reshard cancel 回 old state，讓 workflow 回到可驗證狀態

5. VReplication workflow 卡住 — cancel 前需要保護狀態

VReplication workflow 跑到 50% 但 某個 row 解析錯誤（schema mismatch / blob 大小超過 limit）、workflow stuck、進度條卡住、無 timeout。整個 resharding flow halt。

修法：

• 平時跑 staging 資料 dry-run、發現 schema 跟 blob 邊界問題
• Workflow 卡住時 vtctldclient Workflow show 看 last_message / row_state
• 手動修問題 row（直接 MySQL 改）後 resume workflow
• 大 cluster 建議 VReplication 跑前先 SchemaApply audit、確認 source / target schema 兼容

Vitess 跟自管 sharding 對照

Vitess 的 operational complexity 是它的代價。10-20 人 SRE 團隊撐得住、5 人團隊用 managed Vitess（PlanetScale） 更實際。

跟其他模組整合

跟 Replication topology

Vitess shard 內部仍用 MySQL replication（Replication Topology）— 每個 shard 有 primary + replica + rdonly。Vitess durability-policy 控制 primary 寫入是否等 replica ack（semi-sync）。

跟 OSC tool

Vitess 不用 gh-ost / pt-osc、用 VReplication-based online DDL。Vitess online DDL：

1vtctldclient ApplySchema --strategy=vitess \
2  --sql="ALTER TABLE orders ADD COLUMN status VARCHAR(20)" commerce

詳見 Online Schema Change Tools。

跟 ProxySQL

Vitess 取代 ProxySQL。VTGate 本身做 connection pool + query routing、不再需要 ProxySQL。混用會造成 routing 衝突（VTGate 期待自己決定 shard、ProxySQL 跟 VTGate 競爭）。詳見 ProxySQL 配置。

跟 Orchestrator

Vitess 用 VTOrc（fork of Orchestrator）作 failover、跟 Vitess topology metadata 整合。不用獨立 Orchestrator。詳見 Orchestrator failover 設計。

跟 PlanetScale（managed Vitess）

PlanetScale 是 Vitess managed service、隱藏 4 component operational complexity、加 branch-based schema workflow。詳見 PlanetScale migration playbook。

跟 Aurora MySQL

Aurora 跟 Vitess 是 不同 scale 路徑：

• Aurora：single-region scaling（storage / compute 分離、最高 ~128 TB）
• Vitess：horizontal sharding（無上限、靠加 shard scaling）

兩者承擔的容量與操作責任不同。超過 Aurora single-region 上限的場景才考慮 Vitess。詳見 Aurora vendor page。

Production case：YouTube / Vitess

Vitess 的 production 責任是把 MySQL shard 拓撲變成應用可查詢、可遷移、可操作的資料庫層。YouTube / Vitess 的公開歷史提供的工程訊號是 VTGate、VTTablet、VReplication 與 VSchema 這組元件分工：application query 進 VTGate、tablet 層包住 MySQL、VSchema 描述 routing / sharding 規則、VReplication 支援 resharding 與資料搬移。

這個案例要回收到三個操作判準。第一，Vitess 是一套 database control plane，而非單一 proxy；導入時要把 topology service、tablet lifecycle、backup、failover 與 schema workflow 一起納入 ownership。第二，VSchema 是 application contract，shard key、lookup vindex 與 cross-shard query 都會影響產品功能設計。第三，VReplication 讓 resharding 可操作，但它仍需要 capacity window、backfill 監控與 cutover plan。

Vitess 的 sibling 路由是 PostgreSQL Citus Distributed 與 1.11 全球分散式 OLTP。Citus 保留 PostgreSQL 生態並用 coordinator / worker 拆分資料；CockroachDB / Spanner 則用 distributed SQL 重新定義交易與一致性邊界。選型時要先判斷自己是在延伸 MySQL 投資，還是在重新選 global OLTP model。

何時用 Vitess

相關連結

• MySQL vendor overview
• MySQL Replication Topology（Vitess shard 內部）
• MySQL Online Schema Change Tools（Vitess 不用 gh-ost / pt-osc）
• MySQL ProxySQL 配置（Vitess 取代 ProxySQL）
• MySQL Orchestrator failover（VTOrc fork）
• PostgreSQL Citus Distributed（PG sibling、coordinator + worker 模型 vs Vitess VTGate + tablet）
• 1.11 全球分散式 OLTP（Vitess vs CockroachDB vs Spanner）
• Database Sharding（shard key、routing、resharding 與 cross-shard query）
• 官方：Vitess Documentation / Vitess Operator

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 8.0 modern SQL 特性 — 5 個關鍵能力 + 跟 PostgreSQL 對應特性的對比。

「MySQL 是 SQL 簡單版」是個過時觀念。

這個觀念的來源很合理：MySQL 5.x 時代沒 CTE、window function 要嗑 hack、recursive query 寫不出來、JSON 處理是字串 substring 拼接、複雜分析 query 只能丟去 PostgreSQL 或 Snowflake。整整 10 年 SQL 進階特性 MySQL 全缺、PostgreSQL 全有。

MySQL 8.0（2018 推出）改變這件事。CTE / window function / lateral derived table / JSON_TABLE / hash join / atomic DDL / role-based authentication / common table expression 全部進來。這不是「終於跟上 PG」、是 MySQL 第一次有資格進入 SQL 工程深度討論。但有 caveats：每個特性的 行為實現 跟 PostgreSQL 對應特性都有 微妙差異、不能假設 PG 經驗直接套用。

對從 PostgreSQL 過來評估 MySQL 的讀者：本文是 特性對等驗證 — 哪些 8.0 特性真的可以 production 用、哪些是 marketing 但實作有 gap。對既有 MySQL 5.7 user：本文是 upgrade 5.7 → 8.0 的具體 ROI — 從 SQL feature 角度看升級值不值得。

5 個關鍵特性 + PG 對比

特性 1：CTE（Common Table Expression）

MySQL 8.0 / PG 8.4+ 都支援。

 1-- MySQL 8.0 + PG 都 OK
 2WITH order_summary AS (
 3    SELECT user_id, SUM(amount) AS total
 4    FROM orders
 5    WHERE created_at > '2026-01-01'
 6    GROUP BY user_id
 7)
 8SELECT u.name, os.total
 9FROM users u JOIN order_summary os ON u.id = os.user_id
10WHERE os.total > 1000;

行為差異：

• MySQL 8.0：CTE 不 materialize 為預設、optimizer 把 CTE 視為 inlined subquery、CTE 引用兩次以上會 重複計算
• PostgreSQL（< 12）：CTE fence by default（materialize barrier）、optimizer 不 push predicate 進 CTE
• PostgreSQL（12+）：CTE 行為跟 MySQL 接近、有 MATERIALIZED / NOT MATERIALIZED keyword 明示

對 PG 12+ user：可以套 MySQL 經驗。對 PG 11 以下 user：CTE 行為跟 MySQL 不一樣、要重看 query plan。

Recursive CTE：

1WITH RECURSIVE org_chart AS (
2    SELECT id, name, manager_id, 0 AS depth
3    FROM employees WHERE manager_id IS NULL
4    UNION ALL
5    SELECT e.id, e.name, e.manager_id, oc.depth + 1
6    FROM employees e JOIN org_chart oc ON e.manager_id = oc.id
7)
8SELECT * FROM org_chart WHERE depth <= 10;

兩家都支援、但 MySQL 8.0 有 深度上限（cte_max_recursion_depth=1000、預設 1000、PG 預設 unlimited）。複雜 hierarchical query（深度 > 1000）MySQL 需要顯式提高 limit。

特性 2：Window Function

MySQL 8.0 / PG 8.4+ 都支援、語法同 SQL standard。

1SELECT
2    order_id,
3    user_id,
4    amount,
5    SUM(amount) OVER (PARTITION BY user_id ORDER BY created_at) AS running_total,
6    RANK() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rank_in_user
7FROM orders;

行為差異：

• 執行 plan：MySQL 8.0 用 window iterator、單 partition 內 sort、外加 in-memory window buffer。PostgreSQL 有更成熟的 WindowAgg node、複雜 frame spec 處理更好
• Frame spec 支援度：兩家都支援 ROWS / RANGE / GROUPS、但 GROUPS frame MySQL 是 8.0.16+ 才補進、PG 11+ 才補
• 大資料量 spill behavior：MySQL window function 超過 sort_buffer_size（預設 256K）會 spill 到 disk、Performance 雪崩。PG 用 work_mem（預設 4MB）、寬裕些但也會 spill

對長期用 PG window function 寫複雜 reporting query 的 user：MySQL 8.0 可以做、但 效能 tune 工作量大、不是 drop-in。

特性 3：JSON_TABLE（PG 主要賣點對比）

這是 user 點到的對比重點。

MySQL 8.0 的 JSON_TABLE：

 1SELECT t.id, j.name, j.price
 2FROM products t,
 3     JSON_TABLE(
 4         t.metadata,
 5         '$.variants[*]' COLUMNS (
 6             name VARCHAR(50) PATH '$.name',
 7             price DECIMAL(10,2) PATH '$.price'
 8         )
 9     ) AS j
10WHERE t.category = 'shoes';

JSON_TABLE 把 JSON document 內的 array element 展開成 relational rows、然後可以 JOIN / WHERE / GROUP BY。SQL:2016 standard 規範。

PostgreSQL 對應：

PG 17+ 有 JSON_TABLE（SQL:2016 standard、跟 MySQL 同語法）、但歷史上 PG user 用兩條不同路線：

1. JSONB operator（PG 9.4+）：

   1SELECT id, metadata->'variants' AS variants
   2FROM products
   3WHERE metadata @> '{"category": "shoes"}';

2. jsonb_path_query（PG 12+）：

   1SELECT t.id, v.name, v.price
   2FROM products t,
   3     jsonb_path_query(t.metadata, '$.variants[*]') AS v;

核心差異：

選型結論：

• MySQL 是 JSON-storage 角色（document 順手存進關聯 DB）：JSON_TABLE 夠用、配 generated column + index、production-ready
• MySQL 是 document-heavy workload（大量 JSON-driven query / 複雜 path / 高 selectivity）：PG JSONB GIN index 仍是 clearly winner、或直接用 MongoDB
• MySQL 8.0 JSON 不是 PG JSONB 替代：JSON_TABLE 是 SQL standard 對齊、好 portable、但 index 跟 storage 仍弱

對「JSON 是 PG 主要賣點」的判斷：JSONB binary storage + GIN index 是 PG 在 JSON workload 的 結構性優勢、MySQL 8.0 補了 SQL_TABLE 但 index 那層沒補。8.0 後 JSON 議題 不是 deal-breaker for MySQL（不像 5.7 時代直接 disqualify）、但仍不是 MySQL 主場。

特性 4：Lateral Derived Table

MySQL 8.0.14+ / PG 9.3+ 都支援。

1-- 對每個 user、找他最近 5 個 order
2SELECT u.id, recent.*
3FROM users u
4LEFT JOIN LATERAL (
5    SELECT order_id, amount
6    FROM orders o
7    WHERE o.user_id = u.id
8    ORDER BY created_at DESC LIMIT 5
9) recent ON true;

Lateral 讓 subquery 可以 引用外部 reference column（u.id）、不可能用 plain subquery 寫出來。

行為差異：

• MySQL 8.0：lateral 後加、optimizer plan 仍在演進、複雜 lateral query 可能 plan 次優
• PostgreSQL：lateral 早就成熟、plan 跟 join 直接 fuse、效率高

對 PG-experienced 使用 lateral 寫 reporting query 的 user：MySQL 8.0 可以、但有時候要 hint optimizer 達到最佳 plan。

特性 5：Hash Join

MySQL 8.0.18+ / PG 早已有。

MySQL 8.0 之前：只有 nested loop join、大表 JOIN 完全失控（n × m row scan）。8.0.18 加 hash join、optimizer 在預估 row count 大時自動切。

注意：MySQL 8.0 hash join 預設 不對所有 join 開、只在 optimizer_switch='hash_join=on' 且 join condition 是 equality on indexed column 時觸發。常見錯估：複雜 join 條件不觸發 hash join、optimizer fallback nested loop、query 永遠跑不完。

PG 對應：PG 一直有 hash join、optimizer 預設 cover 廣、且有 parallel hash join（PG 11+）大表 JOIN 並行加速。

MySQL hash join 是 補洞、不是 並肩特性。複雜 OLAP query MySQL 仍弱於 PG。

其他 8.0 特性（一句話帶過）

• Atomic DDL：CREATE TABLE / DROP / ALTER 變 transactional、crash recovery 不會留 orphan table（PG 早就 atomic）
• Role-based authentication：role 取代 group-level grant、user 可繼承 role（PG 早就 role 系統）
• CHECK constraint enforcement：5.7 可寫但不執行、8.0 真的 enforce（PG 一直執行）
• invisible index：建 index 但 optimizer 暫不用、適合 staging query plan 測試（PG 沒原生對應）
• Resource Group：query 跑時可分配 CPU thread 給特定 user group（PG 沒原生對應）
• Generated column：MySQL 5.7 已有、8.0 強化、可作為 JSON path 加速的 workaround

配置 step-by-step（從 5.7 → 8.0 SQL feature 升級）

如果已經是 8.0、所有特性都可以用、不必額外配置。如果是 5.7 → 8.0、需要：

1. character_set_server=utf8mb4：8.0 預設 utf8mb4（5.7 預設 latin1）、character set 不一致導致 query 行為微差
2. default_authentication_plugin=mysql_native_password：8.0 預設 caching_sha2_password、舊 client 連不上、cluster upgrade 期間用 native_password 保兼容
3. optimizer_switch='hash_join=on'：確認 hash join 啟用、預設應該已 ON
4. cte_max_recursion_depth=10000：複雜 recursive CTE 需要時提高
5. 重新 review 所有 ORM-generated SQL：8.0 keywords 變多（WINDOW、RANK、LATERAL 等變成 reserved word）、5.7 識別碼可能變 syntax error

5 個 Production 踩雷

1. CTE 引用兩次 = 跑兩次

1WITH expensive AS (SELECT ... heavy aggregation ...)
2SELECT * FROM expensive WHERE ...
3UNION ALL
4SELECT * FROM expensive WHERE other_condition;

預期 CTE 跑一次、實際 MySQL 跑兩次。Query 時間 doubled。

修法：

• 把 CTE 結果先 INSERT 進 temporary table、SELECT 兩次走 temp table（手動 materialize）
• 或 PG 用 MATERIALIZED keyword（MySQL 沒對應 hint、要手動 temp table）

2. Window function 大 partition spill 到 disk

1SELECT order_id,
2       SUM(amount) OVER (PARTITION BY user_id ORDER BY created_at)
3FROM orders;  -- 1 億 row

sort_buffer_size=256K 預設、單 partition > 256K row 開始 spill disk、執行從秒級變分鐘級。

修法：

• 提高 sort_buffer_size（per-connection、不要設太大、connection × buffer 會吃 RAM）
• 加 INDEX 包含 user_id, created_at、optimizer 可直接用 sorted index、不必額外 sort

3. JSON_TABLE 跟 generated column 取捨錯誤

直接 JSON_TABLE on every query：

1SELECT * FROM products,
2JSON_TABLE(metadata, '$.variants[*]' COLUMNS (...));

每次 query 跑 JSON parse、無 index 加速、大表 query 慢。

修法：

• 對 常 query 的 JSON path 建 generated column：

  1ALTER TABLE products
  2ADD COLUMN category VARCHAR(50)
  3GENERATED ALWAYS AS (JSON_UNQUOTE(metadata->'$.category')) STORED,
  4ADD INDEX idx_category (category);

• JSON_TABLE 用於 ad-hoc query、不要當熱 path

• 跟 PG JSONB GIN 對比：PG 不必預先建 generated column、GIN index 直接 over JSONB

4. Hash join 沒觸發 — Optimizer 預估錯 row count

JOIN 大表預期 hash join、實際 MySQL 跑 nested loop、query 跑不完。常見原因：

• Table statistics 過時（沒跑 ANALYZE TABLE）
• Join condition 不是 pure equality（a.id = b.id + 1 等）
• 一邊有 LIMIT、optimizer 估 small set、選 nested loop

修法：

• 跑 ANALYZE TABLE 更新 statistics
• 用 EXPLAIN ANALYZE 看實際 row count vs 估計
• 用 optimizer_hint（如 /*+ HASH_JOIN(t1 t2) */）強制

5. Recursive CTE 深度上限 — Production query 突然 fail

cte_max_recursion_depth=1000 預設、organization hierarchy / tree query 超過 1000 層直接 fail（ER_CTE_MAX_RECURSION_DEPTH_EXCEEDED）。

修法：

• 評估真實 hierarchy 深度、設 cte_max_recursion_depth=10000 或更高
• 或 query 加 WHERE depth < N 提前停（不依賴 implicit limit）
• 對極大 hierarchy（社群 follow graph 等）改用 graph DB（Neo4j）— MySQL recursive CTE 不是 graph workload 主場

MySQL 8.0 vs PG SQL 特性 cross-reference

8.0 補了 語法層 大部分缺漏、storage / index / extensibility 層 仍是 PG 結構優勢。對「先選 SQL 工程深度」的 org、PG 仍領先；對「先選 ecosystem / replication / sharding」的 org、MySQL 已不是 disqualifier。

跟其他模組整合

跟 InnoDB Tuning

JSON column 在 InnoDB 是 LONGTEXT 包裝、大 JSON 進 off-page storage（innodb_default_row_format=DYNAMIC 才行、Antelope format 不支援）。Buffer pool 對 LONGTEXT 較不友善、大 JSON workload 可能要更大 buffer pool。詳見 InnoDB Tuning。

跟 Query Optimization

8.0 新 hash join + lateral derived 讓 EXPLAIN ANALYZE 結果更複雜。優化複雜 query 需要熟 新 plan node 類型。詳見 Query Optimization deep dive 篇（待寫）。

跟 Online Schema Change

JSON column 跟 generated column 的 schema change 走 gh-ost / pt-osc 沒問題、但 JSON 大表 ALTER 速度比一般 column 慢（每 row 重 serialize）。詳見 Online Schema Change Tools。

跟 Replication

Window function / CTE / JSON_TABLE 的 query 結果 replicate（row-level binlog 紀錄結果）、不 replicate query 本身。所以 replica apply 不會重新跑 window function、效率 OK。詳見 Replication Topology。

何時 SQL 特性是 MySQL 選型 driver

• 想要 SQL standard 對齊跨 vendor portable：MySQL 8.0 JSON_TABLE / window 都對齊 standard、PG 部分能力（JSONB operator）是 PG-only、portability MySQL 略好
• JSON workload < 20% query：MySQL 8.0 + generated column 夠用、不必為 JSON 換 PG
• JSON workload > 50% query + 複雜 path / aggregation：PG JSONB GIN 仍 winner、考慮 PG 或 MongoDB
• 需要 materialized view / FDW / partial index：PG 仍領先、不要因為 SQL feature parity 假設 MySQL 全 cover
• 既有 MySQL 投資 + SQL 工程深度上升：升 8.0 + 訓練團隊用新特性、不是換 vendor

相關連結

• MySQL vendor overview
• InnoDB Tuning（JSON column 對 buffer pool 影響）
• Online Schema Change Tools（JSON column 大表 ALTER）
• Replication Topology（ROW-format binlog 對 window function）
• PostgreSQL SQL Features Baseline（PG 反向視角、哪些特性 PG 早 5-15 年、MySQL 8.0 補齊後 PG 仍領先）
• PostgreSQL JSONB Deep Dive（PG sibling、binary storage + GIN index 跟 MySQL JSON_TABLE 對比）
• PostgreSQL vendor page（JSON / SQL feature 對比 source）
• MongoDB vendor page（document-heavy workload 替代）
• 官方：MySQL 8.0 What’s New

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 Group Replication + InnoDB Cluster — synchronous multi-primary 的 transaction model + 部署模型。

把「Group Replication multi-primary mode」當成「multi-primary 直接線性 scale write」是常見誤解。

Single-primary 跟 multi-primary 共用同一套 GR 機制（GCE atomic broadcast + certification + applier）— 切換 mode 是 配置變更。但 性能效果 經常跟讀者預期不同：在 single-primary cluster 上加開 group_replication_single_primary_mode=OFF、預期 3 個 instance 都可以接受 write 帶來吞吐倍增、實際上每個寫入仍要全 cluster GCE broadcast + certification、寫吞吐沒爆增 / latency 飆高 / certification 衝突回退增加。

這篇 deep article 把 GR 的 certification 流程 講清楚 — 為什麼「multi-primary」聽起來像「線性 scale」、實際是「保 strong consistency 的 multi-entry」。然後展開 InnoDB Cluster（GR + MySQL Shell + MySQL Router）作為 production deployment 工具。

Group Replication 的 transaction model

GR 用 Group Communication Engine (GCE)（Paxos 變種）達成 atomic broadcast — 任何 write transaction 必須先 broadcast 到所有 member、所有 member 確認 certification pass 才 commit。

每個 transaction 的 GR lifecycle：

11. Client → Member A: BEGIN; UPDATE ...; COMMIT;
22. Member A: 先 local execute、收集 write_set（被改的 row + PK + transaction GTID）
33. Member A: write_set + binlog event → GCE broadcast to all members
44. GCE: Paxos consensus、所有 member 收到 broadcast、按 *相同順序*
55. Each Member: certification phase — 看 write_set 跟 *尚未 apply 的 incoming transactions* 是否有 PK 衝突
66. 若無衝突 → apply 該 transaction（local + remote member 都 apply）、回 client COMMIT OK
77. 若衝突 → certification fail、Member A 對 client 回 ERR_LOCK_DEADLOCK / GR_CONFLICT、application 必須 retry

核心結論：

• Single-primary mode：只有指定 member 接受 write、其他 member 純 apply、certification 仍跑（但衝突極少、因只有一個寫入源）
• Multi-primary mode：所有 member 都接受 write、certification 衝突常見、application 必須處理 conflict retry

「multi-primary 不會線性 scale write」的原因：

• 每個 write 仍要全 cluster GCE broadcast + certification
• 寫吞吐 ceiling 受 最慢 member + 網路延遲 限制（不是「N members × M throughput」）
• 多寫入源增加 certification 衝突機率、衝突 retry 反而拖 throughput

「multi-primary 真實價值」：

• 跨 region multi-active deploy（每個 region local member 接受 local write、無 cross-region write latency）— 但需求極少、多數場景 single-primary + Aurora DSQL / Spanner 更實際
• 零停機 maintenance（任一 member 下線、其他繼續接 write、不必 failover）— 但 single-primary mode 也提供同等 HA

對 99% production case：single-primary mode 才是正確選擇。Multi-primary 是 特殊 use case 工具、不是 預設 mode。

Group Communication Engine（GCE）

GR 內建 GCE、基於 XCom protocol（Paxos 變種）。GCE 責任：

• Atomic broadcast：保證 message 到所有 member、按相同順序
• Group membership：偵測 member join / leave / fail、reconfigure consensus
• Network partition handling：minority partition 自動 fence（read-only）、majority 繼續服務

GCE 跟 Raft 對比：

GR 的設計取捨：緊耦合 MySQL（不必外部 DCS）、Paxos-like consensus（不像 Raft 那麼簡單但效率更高）。trade-off 是 對 ops 的 transparency 較低 — XCom 內部行為對 DBA 是 black box。

InnoDB Cluster：GR + MySQL Shell + MySQL Router

純 GR 是 底層 replication mechanism、要組成 production deployment 需要：

• MySQL Shell (mysqlsh)：CLI 工具、提供 dba.createCluster() / cluster.addInstance() 等 cluster 管理 API
• MySQL Router：connection routing layer、自動發現 cluster topology、寫入 routing 給 primary、讀取 routing replica
• MySQL Group Replication plugin：在每個 MySQL instance 啟用

InnoDB Cluster = GR + Shell + Router、是 Oracle 推薦的 production GR deployment 方式。

起始部署（3 member single-primary cluster）

 1# Step 1: 在每個 instance 啟 GR plugin + 配 my.cnf
 2[mysqld]
 3server_id = 1                          # 各 instance 不同
 4gtid_mode = ON
 5enforce_gtid_consistency = ON
 6log_bin = mysql-bin
 7binlog_format = ROW
 8master_info_repository = TABLE
 9relay_log_info_repository = TABLE
10transaction_write_set_extraction = XXHASH64
11plugin_load_add = 'group_replication.so'
12
13group_replication_group_name = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
14group_replication_start_on_boot = OFF
15group_replication_local_address = "node1.example.com:33061"
16group_replication_group_seeds = "node1:33061,node2:33061,node3:33061"
17group_replication_bootstrap_group = OFF
18group_replication_single_primary_mode = ON       # 99% 場景用 ON
19group_replication_enforce_update_everywhere_checks = OFF
20
21# Step 2: 用 MySQL Shell 從第一個 member bootstrap cluster
22mysqlsh --user=root --host=node1.example.com
23> dba.configureInstance('root@node1:3306')
24> var cluster = dba.createCluster('prodCluster')
25> cluster.addInstance('root@node2:3306')
26> cluster.addInstance('root@node3:3306')
27> cluster.status()  # 應該顯示 3 member、1 PRIMARY + 2 SECONDARY
28
29# Step 3: 部署 MySQL Router
30mysqlrouter --bootstrap root@node1:3306 --directory /etc/mysql-router --user=mysqlrouter
31systemctl start mysql-router
32
33# 完成 — application 連 mysql-router:6446 (R/W) 或 :6447 (R/O)

Application 連 Router、Router 自動發現 cluster topology + 自動 failover routing。Application 不必知道哪個 instance 是 primary。

5 個 Production 踩雷

1. Certification lag — Multi-primary 模式 retry storm

Multi-primary mode 下、3 個 instance 同時收到 相同 row 的 conflicting write、certification 階段必有 N-1 個 transaction 被退回。Application 看到 ER_GR_CONFLICT_TRANSACTION_ABORTED、retry、若不智能 retry（exponential backoff）會 retry storm、整個 cluster 寫吞吐暴降。

修法：

• 99% 場景用 single-primary mode、避開 conflict
• 真的需要 multi-primary：application 必須 sharding-aware（不同 entry 寫不同 row range）、本質上跟 Vitess sharding 同概念但用 GR 機制
• Application retry 用 jitter exponential backoff、不直接 retry

2. Certification queue 爆炸 — Single-primary mode 仍受 cert backlog 影響

Single-primary mode 下 primary 接受 write、broadcast 到 secondary。Secondary 跟 primary network latency / 處理速度差時、cert queue 累積。Cert queue 滿 → primary write 也被卡（GR 設計：所有 member 同步前不接受新 write、保 consistency）。

修法：

• 監控 group_replication_member_stats view：COUNT_TRANSACTIONS_IN_QUEUE 持續 > 0 是警訊
• 提高 group_replication_message_cache_size（預設 1 GB）給 large transaction 緩衝
• 確認 所有 member 同 instance class、不要混 spec
• 跨 region GR：完全不推薦（network latency 殺 cert throughput）

3. Large transaction — 全 cluster 卡住

GR 必須把整個 transaction（含所有 write_set）一次 broadcast。10 GB transaction（大批量 UPDATE）必須一次塞滿 GCE buffer、cluster 內所有 member 都暫停接受新 transaction 直到 broadcast / apply 完成。常見場景：批次 archive / 大 backfill / INSERT ... SELECT 1 億 row。

修法：

• group_replication_transaction_size_limit（預設 150 MB）超過直接 reject、不要設 unlimited
• 大批量寫入拆 chunk（每 chunk < 100 MB）、用 application 層 loop
• 對 archive / backfill 用 INSERT INTO archive SELECT ... LIMIT 10000 chunked、不是一個 transaction

4. Network partition — Minority partition 自動 read-only

3 member cluster、network partition 把 1 個 member 隔離。被隔離 member 是 minority、自動進入 read-only mode（不接受 write）、防 split-brain。Application 連到 minority member 寫入會失敗。

修法：

• MySQL Router 自動發現 cluster topology、自動 route write 到 majority partition primary
• Application 必須處理 connection error + retry（甚至 connection string 改成 Router endpoint 而非個別 instance）
• 監控 group_replication_primary_member UDF、確認哪個是真 primary

5. Member 加入 catch-up — 大量 binlog 阻擋 cluster service

新 member 加入 cluster（new instance / 復原 failed member）必須 catch-up — apply 從 GR cluster start 到當前所有 binlog 才能 join consensus。如果 cluster 已運作 1 個月、binlog 累積 100 GB、catch-up 可能 6-12 小時、catch-up 期間 該 member 不投票、其他 member 仍 service、但 majority 安全邊界縮小（3 → 2 member working）。

修法：

• 用 MySQL Shell clone plugin 直接 physical-snapshot 一個 existing member、跳過 binlog replay：

  1> cluster.addInstance('root@node4:3306', {recoveryMethod: 'clone'})

• Clone 期間原 member 暫不接 write traffic（用 Router temporarily 排除）

• 規劃 maintenance window 加 member、不要在 peak load 期間

何時用 GR / InnoDB Cluster

跟其他模組整合

跟 Replication topology

GR 取代傳統 async / semi-sync replication、不是 加在上面。啟用 GR 後不要再配 master-slave style replication。詳見 Replication Topology。

跟 Orchestrator

Orchestrator 跟 InnoDB Cluster 不該 同時用 — 兩者都會 trigger failover、會打架。GR / InnoDB Cluster 內建 failover、不需要 Orchestrator。詳見 Orchestrator Failover。

跟 ProxySQL / MySQL Router

ProxySQL 可以連 GR cluster（自動偵測 read_only flag）、但 MySQL Router 是 GR 原生的 routing layer、跟 InnoDB Cluster 緊耦合（透過 MySQL Shell metadata）。

選擇邏輯：

• 純 MySQL stack, 想 Oracle-supported 整套 → MySQL Router
• 已用 ProxySQL（包含其他非 GR cluster）+ 統一 routing → 仍用 ProxySQL

詳見 ProxySQL 配置。

跟 InnoDB Tuning

GR 對 innodb_flush_log_at_trx_commit / sync_binlog 行為更敏感 — GR 要求 binlog 必須 fsync to disk（sync_binlog=1）保 zero-loss、不能用 sync_binlog=0 換速度。詳見 InnoDB Tuning。

跟 PostgreSQL Patroni 對比

兩者角色相同、設計取捨不同。詳見 PostgreSQL Patroni HA。

容量規劃要點

Member 跨 region：不推薦。GR 對 latency 敏感、跨 region 50-200ms RTT 嚴重影響 cert throughput。multi-region 需求用 Aurora Global Database / Spanner 等專為跨 region 設計的方案。

相關連結

• MySQL vendor overview
• MySQL Replication Topology（GR 取代傳統 replication）
• MySQL Orchestrator Failover（GR / InnoDB Cluster 不必 Orchestrator）
• MySQL ProxySQL 配置（routing layer 對比）
• MySQL InnoDB Tuning（GR durability 需求）
• PostgreSQL BDR / Multi-Master（PG sibling、active-active 寫入 3 種路徑跟 conflict 治理）
• PostgreSQL Patroni HA（PG sibling、不同 consensus）
• quorum 卡片 / Paxos / Raft 對比
• 官方：MySQL Group Replication / InnoDB Cluster

本文是 MySQL overview 的 implementation-layer deep article。Overview 已說明 MySQL 在 OLTP 譜系的定位、本文聚焦 query optimization — EXPLAIN / optimizer trace / hint 三層工具跟 5 個實際 case。

5 個常見 production case

production 上 query 慢、root cause 幾乎都是 optimizer 選錯 plan。從以下 5 個 case 進入 query optimization：

Case 1：5 秒 → 50ms — JOIN 順序選錯

1-- 慢 (5 秒)：optimizer 選 customers 為 outer table、scan 全 1M row
2SELECT o.id, o.amount, c.name
3FROM orders o JOIN customers c ON o.customer_id = c.id
4WHERE o.created_at > '2026-05-01' AND c.region = 'TW';

EXPLAIN 顯示：

1+----+-------------+-------+------+---------------+--------+
2| id | select_type | table | type | possible_keys | rows   |
3+----+-------------+-------+------+---------------+--------+
4|  1 | SIMPLE      | c     | ALL  | NULL          | 1000000|
5|  1 | SIMPLE      | o     | ref  | idx_cust_id   | 100    |
6+----+-------------+-------+------+---------------+--------+

c table type=ALL（full scan）、rows=1M。問題：customers 沒在 region 上的 index、optimizer 預估「region=TW filter 沒效率、就 full scan」、但 region=TW 只佔 10% row（100K row）。

修法：

1ALTER TABLE customers ADD INDEX idx_region (region);
2ANALYZE TABLE customers;  -- 更新 statistics

加 index 後 optimizer 切 plan：先 scan customers 用 idx_region 篩 100K row、再 join orders。從 5 秒降到 50ms。

Case 2：30 秒 → 200ms — Range scan 退化 ALL

1SELECT * FROM events
2WHERE created_at BETWEEN '2026-05-01' AND '2026-05-02'
3AND user_id = 12345;

events 有 idx_user_id 跟 idx_created_at 兩個 index、optimizer 應該選一個 + 二級 filter、但實際 type=ALL（full scan）。

EXPLAIN ANALYZE 顯示：

1-> Filter: ((events.user_id = 12345) and (events.created_at between ...))  (cost=2M rows=100)
2    -> Table scan on events  (cost=2M rows=10000000)  (actual time=0.1..30s ...)

問題：optimizer estimated rows=100、實際 cardinality estimation 失準（distribution skew）、選了 ALL。

修法：

1-- 用 composite index 直接 cover 兩個條件
2ALTER TABLE events ADD INDEX idx_user_created (user_id, created_at);

Composite index 讓 optimizer 看到 單一 index 直接 satisfy 兩個 predicate、走 range scan + index condition pushdown。30 秒降到 200ms。

Case 3：8 秒 → 30ms — Subquery 沒 unnest

1SELECT * FROM orders
2WHERE customer_id IN (
3    SELECT id FROM customers WHERE region = 'TW' AND vip_level >= 3
4);

5.6 之前 MySQL 把 IN (subquery) 寫成 correlated subquery、外表每 row 都 re-run subquery、極慢。5.6+ 加 subquery unnesting、轉換成 JOIN，但某些情況 unnest 失敗。

EXPLAIN 顯示：

1+----+--------------------+-----------+-------+
2| id | select_type        | table     | type  |
3+----+--------------------+-----------+-------+
4|  1 | PRIMARY            | orders    | ALL   |
5|  2 | DEPENDENT SUBQUERY | customers | unique_subquery |
6+----+--------------------+-----------+-------+

DEPENDENT SUBQUERY 是危險訊號。修法：

1-- 手動改寫成 JOIN
2SELECT o.* FROM orders o
3JOIN customers c ON o.customer_id = c.id
4WHERE c.region = 'TW' AND c.vip_level >= 3;

或用 EXISTS（部分 case 比 IN plan 好）：

1SELECT * FROM orders o
2WHERE EXISTS (
3    SELECT 1 FROM customers c
4    WHERE c.id = o.customer_id AND c.region = 'TW' AND c.vip_level >= 3
5);

不同寫法 plan 差異需用 EXPLAIN 驗證、不能假設「JOIN 一定比 IN 快」。

Case 4：2 秒 → 100ms — Derived table 沒 materialize

1SELECT * FROM orders o
2JOIN (
3    SELECT customer_id, COUNT(*) AS order_count
4    FROM orders
5    GROUP BY customer_id
6) AS counts ON o.customer_id = counts.customer_id
7WHERE counts.order_count > 10;