複制架構圖
核心流程：三線程協作
- Master Binlog Dump Thread：Master 將 Binlog 事件發送給 Slave I/O Thread。
- Slave I/O Thread：連接 Master，請求 Binlog，順序寫入本地 Relay Log（中繼日誌）。
- Slave SQL Thread：讀取 Relay Log，解析事件，在 Slave 重放執行，保持數據一致。
關鍵文件角色
| 文件 | 位置 | 作用 |
|---|
| Binlog | Master | 記錄所有 DDL/DML 變更，複制源頭，亦用於時間點恢復 (PITR) |
| Relay Log | Slave | I/O Thread 寫入，SQL Thread 讀取，緩衝網絡抖動、解耦讀寫 |
| master.info | Slave | 記錄 Master 連接信息、Binlog 文件/位置 |
| relay-log.info | Slave | 記錄 SQL Thread 執行到的 Relay Log 位置 |
複制解決的四大核心問題
- 備份容災：Slave 為 Master 熱備份，故障時可提升為新 Master（RPO≈0，RTO 分鐘級）。
- 讀寫分離：Master 負責寫，Slave 群負責讀，線性擴展讀吞吐。
- 讀負載均衡：多 Slave 組成讀池，中間件（ProxySQL/HAProxy）分發 SELECT。
- 高可用基石：MHA、Orchestrator、InnoDB Cluster、GTID 自動故障轉移的前提。
複制模式演進
| 模式 | 定位方式 | 優點 | 缺點 |
|---|
| 基於位置 | Binlog 文件名 + Offset | 簡單兼容 | 主從切換需手動對齊位置，多級複制易錯 |
| GTID (Global Transaction ID) | 全局事務 ID (source_id:transaction_id) | 自動定位、多級複制安全、故障轉移簡單 | 5.6+ 支援，嚴格要求 GTID 模式一致 |
生產強制 GTID：gtid_mode=ON + enforce_gtid_consistency=ON。
常見延遲原因與優化
| 原因 | 優化方向 |
|---|
| Slave 機能弱（CPU/IO/內存） | 規格對齊 Master，或啟用並行複製 |
| 大事務（長 SQL、批量更新） | 業務拆分小事務，binlog_row_image=MINIMAL |
| 鎖爭用（長鎖表、死鎖） | 優化索引、縮短事務、避免全表掃描 |
| 單線程 SQL Thread 瓶頸 | 啟用 slave_parallel_workers>0 (5.6+) / slave_parallel_type=LOGICAL_CLOCK (5.7+) |
監控關鍵指標
SHOW SLAVE STATUS\G
-- 核心
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
-- 進階
Relay_Log_Space: 458 -- Relay Log 總大小
Exec_Master_Log_Pos: 120 -- SQL Thread 已執行位置
Retrieved_Gtid_Set: ... -- 已接收 GTID 集合
Executed_Gtid_Set: ... -- 已執行 GTID 集合
