MySQL Binlog 與主從複制架構概覽

Binlog (二進制日誌) 核心角色

• 主從複制傳輸載體：主庫寫入 Binlog → 從庫 I/O 線程拉取 → 寫入 Relay Log → SQL 線程重放。
• 時間點恢復 (PITR)：全量備份 + Binlog 回放 = 任意秒級恢復。
• 審計/數據訂閱：解析 Binlog (Canal/Maxwell/Debezium) 實現異構同步、緩存失效、數據湖入湖。

三種 Binlog 格式

建議：binlog_format = ROW + binlog_row_image = FULL (或 MINIMAL 節省空間)。

主從複制工作流程 (三階段)

1. 主庫：事務提交前寫入 Binlog (Group Commit) → 通知存儲引擎提交。
2. 從庫 I/O 線程：連接主庫 → 請求 Binlog (GTID 或 File+Pos) → 寫入本地 Relay Log。
3. 從庫 SQL 線程：讀取 Relay Log → 重放事務 → 更新從庫數據。

關鍵限制：從庫重放是單線程串行 (5.6 及之前)；5.7+ slave_parallel_workers + slave_parallel_type=LOGICAL_CLOCK 可並行重放。

GTID (Global Transaction Identifier) 複制模式

• 核心：每個事務分配全局唯一 GTID (source_id:transaction_id)。
• 優勢：自動定位同步位置、故障切換簡單、多源複制支援、跳過錯誤事務方便。
• 啟用：gtid_mode=ON、enforce_gtid_consistency=ON、log_slave_updates=ON。

關鍵配置參數 (主/從)

搭建步驟速覽

1. 主庫：開啟 Binlog、設定 server_id、建立複制帳號 (GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY 'pass';)。
2. 從庫：設定 server_id、開啟 Relay Log、CHANGE MASTER TO ... (或 GTID 模式 MASTER_AUTO_POSITION=1)。
3. START SLAVE; → SHOW SLAVE STATUS\G 確認 Slave_IO_Running=Yes、Slave_SQL_Running=Yes、Seconds_Behind_Master=0。

常見故障與應對

• 從庫延遲：大事務、DDL、單線程瓶頸、I/O 慢 → 並行複制、優化主庫大事務、升級硬體。
• 主從不一致：STATEMENT 格式非確定函數、從庫誤寫入、Binlog 損壞 → 定期 pt-table-checksum 校驗、修復腳本。
• Binlog 丟失/損壞：sync_binlog=1、RAID/雲盤高可靠、定期備份 Binlog。

監控指標

SHOW SLAVE STATUS\G
-- Seconds_Behind_Master, Slave_IO_Running, Slave_SQL_Running, Last_IO_Error, Last_SQL_Error
-- Relay_Log_Space (積壓大小)

接入 Prometheus mysqld_exporter 告警：Seconds_Behind_Master > 30、Slave_*_Running != Yes。

總結

Binlog 是 MySQL 高可用、災備、數據集成的**核心樞紐**。選對格式 (ROW)、開啟 GTID、配置並行複制、做好監控校驗，構建穩健的主從架構。