"Mysql" 2026-06-26
資料庫大版本升級
MySQL 5.7→8.0、PostgreSQL 13→16 等大版本升級的相容性評估、備份保險、平行驗證、切換策略與升級後監控 2026-06-26
無 SSH 環境的資料庫備份與變更管理
在只有 phpMyAdmin 或有限遠端連線的無 SSH 環境裡,怎麼建立可靠的資料庫備份策略、schema 變更紀律與還原演練流程 2026-05-19
MySQL → PostgreSQL:從 SQL dialect diff 跑出來的 Type A 6-phase migration
MySQL → PostgreSQL 是 Type A 高 schema 差 migration 的標準形態 — SQL dialect / collation / case sensitivity / replication 模型差異主導;用 pgloader / AWS DMS / 自管 dual-write 三條 path、5 個 production 踩雷(auto_increment vs SERIAL / charset 跟 collation / case sensitivity / index syntax / triggers) 2026-05-19
MySQL Replication Topology:async / semi-sync / GTID 不是三選一、是三個 trade-off 軸的疊加
MySQL replication 不是「選 async 還是 semi-sync」、是 *durability / latency / consistency* 三個 trade-off 軸的疊加;GTID 是跨 mode 的 infrastructure layer、不是第三種 mode。本文走 3 軸取捨模型 → async / semi-sync 行為對比 → GTID 替代 binlog-position 的好處 → 配置 step-by-step → 5 production 踩雷(lag 暴衝 / semi-sync 退回 async / GTID gap / Loss-Less semi-sync 真的 loss-less / chained replication 雪崩)→ 跟 Aurora MySQL / Vitess / ProxySQL / Orchestrator 整合 2026-05-19
MySQL Online Schema Change:gh-ost 跟 pt-online-schema-change 兩條完全不同的 ghost table 路徑
MySQL ALTER TABLE 可能鎖整張表,production 需要 online schema change 流程。gh-ost(GitHub)跟 pt-online-schema-change(Percona)都用 ghost table 解決、但底層機制完全不同:pt-osc 用 trigger 同步、gh-ost 用 binlog stream 同步。本文走兩工具機制對照表 → trigger vs binlog 各自取捨 → 配置 step-by-step → 5 production 踩雷(trigger overhead / binlog 延遲 / FK constraint / hot trigger lock / 切換瞬間 deadlock)→ 何時用哪一個 2026-05-19
MySQL ProxySQL 配置:connection / query / route / response 四段 lifecycle 跟 query rule 設計
ProxySQL 是 MySQL 生態的 connection pool + query routing 標準。本文走 connection → query parse → route → response 四段 lifecycle、query rule engine 的 rule chain 設計、Hostgroup / Server / User 三層 schema、配置 step-by-step(讀寫分離 + replica lag-aware routing)、5 production 踩雷(query rule 順序錯亂 / connection 漂移 / write 路由到 replica / runtime / disk schema drift / mirror traffic 副作用)、跟 Replication / Orchestrator / HAProxy 整合 2026-05-19
MySQL Orchestrator Failover:HA 工具自己怎麼 HA?raft cluster + GTID-based promotion 的兩段 paradox
Orchestrator 是 MySQL HA 自動 failover 的 de facto standard、但讀者第一個問題往往是「HA 工具自己會壞嗎」。本文走 Orchestrator 的雙層架構(管 MySQL 的 raft cluster + 被 raft 管的 orchestrator instance)→ topology discovery → failure detection → failover decision tree → promote action → 5 production 踩雷(split-brain 跟 fencing / pre-failover hook 失敗 / anti-flapping window / GTID errant transaction / VIP 跟 ProxySQL 整合斷層)→ 跟 ProxySQL / Patroni / RDS 對比 2026-05-19
MySQL InnoDB Tuning:為什麼一個 100 GB DB 在 64 GB RAM server 上 query 慢 5 倍
InnoDB 是 MySQL 預設 storage engine、預設值給 256 MB buffer pool(早期 default)。本文從一個常見痛點開場(DB > RAM 但 server 仍 swap)、走 4 個 critical knob(buffer pool / redo log / flush method / IO capacity)、各自如何影響讀寫吞吐、配置 step-by-step、5 production 踩雷(buffer pool warm-up / log file 大小 / 設 sync_binlog=0 換速度 / IO scheduler / undo log 膨脹)、跟 SSD / NVMe / EBS 的 IO 假設 2026-05-19
MySQL Binary Log + CDC:Maxwell / Debezium 是 binlog 第二消費者
MySQL CDC 跟 PostgreSQL logical decoding 是不同 abstraction — PG logical decoding 是 *logical event*(INSERT / UPDATE / DELETE)、MySQL CDC 是 *讀 binlog row-level event*。Maxwell / Debezium 是 binlog 第二消費者(跟 replica 共享 binlog stream),並非 PostgreSQL 式 logical replication 系統。本文走 binlog 三種 format(STATEMENT / ROW / MIXED)、ROW format 的 raw event 結構、Maxwell vs Debezium 對比、配置 step-by-step、5 production 踩雷(binlog retention / DDL event / row image / Kafka producer 跟 binlog reader 速度差 / schema change 跟 CDC consumer 同步) 2026-05-19
MySQL Vitess Sharding:VTGate / VTTablet / VReplication / VSchema 四件套協作
Vitess 不只是 MySQL sharding proxy、是 4 個 component 協作的完整 sharding 系統 — VTGate(query routing layer)、VTTablet(per-MySQL agent)、VReplication(跨 shard 資料移動)、VSchema(sharding metadata)。本文走 4 件套各自責任、keyspace / shard / tablet 架構、shard key 設計(Vindex)、配置 step-by-step、5 production 踩雷(cross-shard transaction / VStream lag / Vindex 不均勻 / resharding 切流 / VReplication 卡住)、跟自管 sharding 跟 PlanetScale 的對比 2026-05-19
MySQL 8.0 Modern SQL:CTE / window function / JSON_TABLE 不是「終於跟上 PG」、是進入 SQL 工程深度的入場券
MySQL 8.0 在 SQL 特性上 *終於補齊* CTE、window function、lateral derived table、JSON_TABLE、hash join 等現代 SQL 特性。本文走 5 個關鍵特性、各自實際 production 場景、跟 PostgreSQL 對應特性的行為差異(特別是 JSON_TABLE vs PG JSONB / jsonb_path_query)、配置 / migration 注意事項、5 production 踩雷(CTE 不 materialize / window function 大量 sort spill / JSON_TABLE 跟 generated column 取捨 / hash join 預設沒開 / recursive CTE 深度上限) 2026-05-19
MySQL Group Replication / InnoDB Cluster:single-primary vs multi-primary mode 對 transaction certification 的影響
MySQL Group Replication 提供 synchronous multi-primary replication、用 Paxos-like Group Communication Engine(GCE)達成 quorum-based commit。但「multi-primary」不是「single-primary 多開幾個 write 入口」、是 *transaction conflict detection + certification* 整個機制不同。本文走 GR 機制(GCE + certification + applier)、single-primary vs multi-primary mode、InnoDB Cluster 跟 MySQL Shell / Router 整合、5 production 踩雷(cert lag / write conflict / large transaction / network partition / member 加入 catch-up)、何時用 GR 何時用傳統 replication 2026-05-19
MySQL Query Optimization:從 EXPLAIN 看到實際執行、5 條 query 從 5 秒變 50ms 的 anatomy
MySQL query 慢的根因不在「SQL 寫法」、在「optimizer 選錯 plan」。本文從 5 個常見 production case 開場(5 秒 → 50ms / 30 秒 → 200ms / 8 秒 → 30ms 等)、走 EXPLAIN / EXPLAIN ANALYZE / optimizer trace 三層分析工具、index hint vs optimizer hint 取捨、cardinality estimation 失效時的修法、5 production 踩雷(statistics 過時 / forced index 用錯 / hash join 沒觸發 / range scan 退化 ALL / derived table materialization) 2026-05-19
MySQL Partitioning:partition lifecycle 五段、跟 Vitess sharding 不同的「同 instance 內水平切割」
MySQL native partitioning 是 *同一個 MySQL instance 內的水平切割*、不是 Vitess sharding(跨 instance)。本文走 partition lifecycle 五段(design → create → query → maintenance → drop)、4 種 partition type(RANGE / LIST / HASH / KEY + COLUMNS / sub-partitioning)的 trade-off、partition pruning 怎麼運作、5 production 踩雷(PK 必須含 partition key / global index 沒原生 / partition exchange 細節 / orphan partition / cross-partition query 慢)、跟 PG declarative-partitioning 對比 2026-05-19
MySQL PITR + Backup Strategy:備份不是「拷貝資料」、是 N 點任意 restore 的能力
MySQL backup 不只是 mysqldump、是 *full backup + binlog 連續流* 組合才能達成 PITR(point-in-time recovery)。本文走「PITR 是能力、不是動作」、3 種 backup tool 對比(mysqldump / Percona XtraBackup / MyDumper)、binlog-based recovery 流程、配置 step-by-step、5 production 踩雷(GTID 處理不一致 / binlog gap / backup 沒 verify / RPO 不到 1 分鐘的代價 / encryption key 沒備份)、跟 PG pitr-wal-archiving sibling 對比 2026-05-19
MySQL Lock Contention:在 staging 重現的 deadlock、production 跑 6 個月才出現
MySQL InnoDB 的 lock 是 row-level、但 *為什麼某些 row 莫名其妙也被 lock* 是 gap lock / next-key lock 設計造成的隱性行為。本文從一個 production case 開場(staging 重現 deadlock / production 6 個月後突然爆)、走 5 種 InnoDB lock 類型(record / gap / next-key / insert intention / auto-inc)、isolation level 對 lock 行為的決定性影響、deadlock detection / SHOW ENGINE INNODB STATUS 解讀、5 production 踩雷(gap lock 阻塞 INSERT / auto-inc lock contention / FK lock cascading / large transaction lock holding / READ COMMITTED 跟 binlog ROW 互動) 2026-05-19
MySQL 5.7 → 8.0 Major Version Upgrade:character set / authentication / atomic DDL 三條 paradigm 同時換軌
MySQL 5.7 → 8.0 三條 default 同時改:charset utf8 → utf8mb4、auth plugin native_password → caching_sha2_password、DDL non-atomic → atomic。本文走 Type E paradigm shift 結構、6 維 audit、4-phase upgrade、5 production 踩雷、何時不要升級。 2026-05-19
MySQL → Aurora MySQL:storage layer 轉手到 AWS、replication / HA / backup 全部 outsource
自管 MySQL → Aurora MySQL 是 Type C operational hybrid migration — wire protocol 一致、ops 責任轉到 AWS。本文走 6 維 audit(Operational High)、Aurora storage architecture 衝擊、4-phase migration、5 production 踩雷、何時維持原路線。 2026-05-19
MySQL → PlanetScale:managed Vitess + branch-based schema workflow 的 hybrid shift
自管 MySQL → PlanetScale 加上 Vitess sharding 跟 branch-based schema workflow。本文走 6 維 audit(Paradigm + Operational + Schema 多軸)、4-phase migration、5 production 踩雷、何時不要遷。 2026-05-19
自管 Vitess → PlanetScale:Vitess component ops outsource、加 schema workflow shift
自管 Vitess → PlanetScale 是 Type C operational hybrid — Vitess component(VTGate / VTTablet / VReplication / VSchema)ops outsource + branch workflow。本文走 6 維 audit、4-phase migration、5 production 踩雷、何時不要遷。 2026-06-26
mysqldump
MySQL / MariaDB 的 CLI 備份工具,把資料庫匯出成 SQL 語句的純文字檔 2026-05-27
從自管 PostgreSQL / MySQL 遷到 Aurora:operational redesign migration playbook
PostgreSQL / MySQL → Aurora 的 Type C operational redesign hybrid playbook、6 規格面(Driver / Diff audit / Phase plan / Evidence / Cutover / Cleanup)、Standard Chartered 合規 lead time 模型、Netflix 非 all-purpose store 邊界 2026-05-22
MySQL Audit Log + SIEM
MySQL audit log、general log、slow log、privilege event、SIEM pipeline、retention 與 alert route 2026-05-22
MySQL Backup Restore Drill
MySQL logical dump、physical backup frame、binlog position、restore validation 與 RPO / RTO evidence 2026-05-22
MySQL Cross-buffer Memory Contention
MySQL InnoDB buffer pool、sort / join buffer、tmp table、thread memory、OS page cache 與 memory pressure 判讀 2026-05-22
MySQL Document Store / X Protocol
MySQL Document Store、X Protocol、JSON collection、SQL interoperability、MongoDB-like API 與使用邊界 2026-05-22
MySQL Encryption / TLS / Key Management
MySQL at-rest encryption、TLS、keyring、certificate rotation、backup encryption 與 credential governance 2026-05-22
MySQL HeatWave OLAP Add-on
MySQL HeatWave、OLTP + OLAP hybrid、query offload、cost model、data freshness 與 warehouse 邊界 2026-05-22
MySQL Local Lab Quickstart
MySQL local lab 的 Docker Compose、schema seed、sample workload、basic metric 與 teardown 2026-05-22
MySQL Metadata Lock Deep Dive
MySQL metadata lock、DDL blocking、long transaction、online schema change、MDL observability 與 incident runbook 2026-05-22
MySQL Multi-source Replication
MySQL multi-source replication、channel、consolidation、conflict boundary、lag monitoring 與 migration route 2026-05-22
MySQL Online Schema Change Lab
MySQL ALTER TABLE、metadata lock、gh-ost / pt-osc frame、cutover evidence 與 rollback note 2026-05-22
MySQL ProxySQL Routing Lab
MySQL ProxySQL hostgroup、read/write split、query rule、backend health 與 routing evidence 2026-05-22
MySQL Replication Failover Lab
MySQL source / replica、replication lag、promotion、client route、Orchestrator frame 與 validation evidence 2026-05-22
MySQL Vitess Sandbox Route
Vitess sandbox、keyspace、shard、VSchema、query routing、resharding preview 與 MySQL migration evidence Tarragon (CC BY 4.0) | 使用 hugo 製作