您现在的位置：程式碼之家 >> 數據庫知識 > >> MySQL 資料庫 >> MySQL 綜合教學

MySQL Replication 主從復制架構設計與實戰部署指南

編輯：MySQL 綜合教學

MySQL Replication 主從復制架構設計與實戰部署指南

MySQL Replication 是 MySQL 最具特色的擴展性功能，通過異步二進制日志傳輸實現數據同步，廣泛應用於讀寫分離、災備、數據分析等場景。本文基於《MySQL性能調優與架構設計》第 13 章核心內容，系統闡述 Replication 原理、架構模式、搭建流程與運維最佳實踐。

Replication 核心價值

讀擴展：多 Slave 分擔 SELECT 壓力，Master 專注寫入
災備容灾：異地 Slave 實現數據熱備，故障快速切換
業務隔離：報表、分析、備份在 Slave 執行，不影響主業務
零停機維護：Slave 停機維護、升級，Master 無感
架構演進基石：MHA、Orchestrator、Group Replication、InnoDB Cluster 皆建立於此

復制原理深度解析

三線程協作模型

┌─────────────┐                    ┌─────────────┐
│   Master    │                    │    Slave    │
│             │                    │             │
│ ┌─────────┐ │   Binlog Dump      │ ┌─────────┐ │
│ │ IO Thread│◀───────────────────│ │ SQL Thread│ │
│ └─────────┘ │  (Master 端)       │ └────┬────┘ │
│      ▲      │                    │      │      │
│      │      │                    │ ┌────┴────┐ │
│ ┌────┴────┐ │                    │ │ IO Thread│ │
│ │Binlog   │ │                    │ └────┬────┘ │
│ │(mysql-  │ │                    │      │      │
│ │ bin.xxx)│ │                    │ ┌────┴────┐ │
│ └─────────┘ │                    │ │Relay Log│ │
└─────────────┘                    │ │(relay-  │ │
                                   │ │ bin.xxx)│ │
                                   │ └─────────┘ │
                                   └─────────────┘

流程：
1. Slave IO Thread 連接 Master，請求指定位置後的 Binlog
2. Master IO Thread 讀取 Binlog 發送給 Slave
3. Slave IO Thread 寫入 Relay Log，記錄 Master 位置到 master.info
4. Slave SQL Thread 解析 Relay Log，重放 SQL，更新數據

關鍵文件與位置點

文件/位置	作用	管理命令
Master: mysql-bin.xxxxxx	二進制日志，記錄所有 DDL/DML	SHOW MASTER STATUS; PURGE BINARY LOGS;
Slave: relay-bin.xxxxxx	中繼日志，存儲從 Master 拉取的事件	SHOW SLAVE STATUS\G (Relay_Log_File)
Slave: master.info	記錄 Master 連接信息、當前讀取位置	CHANGE MASTER TO 更新
Slave: relay-log.info	記錄 Relay Log 執行位置、SQL 線程進度	自動維護

復制實現級別：Statement vs Row vs Mixed

級別	Binlog 內容	優勢	劣勢	適用場景
Statement (SBR)	SQL 語句文本 + 上下文	Binlog 小、IO 少、易閱讀	非確定性函數( UUID(), NOW() )、存儲過程/觸發器可能不一致	簡單 DML、兼容老版本
Row (RBR)	每行數據變更前後圖像	完全確定性、無函數/觸發器問題、支持並行復制	Binlog 大 (尤其 ALTER TABLE)、IO 開銷大	數據一致性要求高、混合負載
Mixed (MBR)	自動選擇 SBR/RBR	平衡體積與正確性	判斷邏輯複雜、仍有邊界案例	MySQL 5.1.8+ 默認推薦

生產環境推薦配置

# my.cnf
binlog_format = ROW                    # 強一致性、支持並行復制
binlog_row_image = FULL                # 完整行圖像 (可選 MINIMAL/NOBLOB 減小體積)
transaction_isolation = READ-COMMITTED # ROW 格式必須配合 RC 隔離級別
log_slave_updates = ON                 # 鏈式復制/級聯必備
gtid_mode = ON                         # MySQL 5.6+ GTID 模式 (強烈建議)
enforce_gtid_consistency = ON

經典架構模式

1. 標準主從 (One Master - Multiple Slaves)

        ┌─────────┐
        │ Master  │◀── 寫入流量
        └────┬────┘
             │ Binlog
     ┌───────┼───────┐
     ▼       ▼       ▼
  ┌─────┐ ┌─────┐ ┌─────┐
  │Slave│ │Slave│ │Slave│  讀流量分發、備份、分析
  └─────┘ └─────┘ └─────┘

特點：90%+ 生產場景，搭建簡單、延遲極低、Slave 可水平擴展

2. 雙主互備 (Dual Master / Master-Master)

Master → Slave L1 (3-5 台) → Slave L2 (N 台) → Slave L3 ...

解決：Master 連接數過多導致 IO 線程壓力大、Binlog 發送瓶頸
代價：延遲疊加 (每級增加 1-10ms)、L1 故障影響全鏈路
優化：L1 不對外提供讀、專職轉發、監控延遲告警

4. 雙主級聯混合 (高可用 + 讀擴展)

# 1. 啟用 Binlog
log-bin=mysql-bin
server-id=1

# 2. 創建復制用戶
CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'ReplPass123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%';
FLUSH PRIVILEGES;

# 3. 獲取一致性備份 + Binlog 位置
# 方案 A: 熱備份 (推薦 Percona XtraBackup)
innobackupex --user=root --password=xxx /backup/full/

# 方案 B: mysqldump (小數據量)
mysqldump --single-transaction --master-data=2 --all-databases > full.sql
# 輸出文件含: CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;

Step 2: Slave 恢復備份

CHANGE MASTER TO
    MASTER_HOST='192.168.1.10',
    MASTER_USER='repl',
    MASTER_PASSWORD='ReplPass123!',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=154;

# GTID 模式 (5.6+ 推薦)
CHANGE MASTER TO
    MASTER_HOST='192.168.1.10',
    MASTER_USER='repl',
    MASTER_PASSWORD='ReplPass123!',
    MASTER_AUTO_POSITION=1;  # 自動基於 GTID 定位

Step 4: 啟動並驗證

# 核心指標 (Prometheus + mysqld_exporter)
mysql_slave_status_slave_io_running
mysql_slave_status_slave_sql_running
mysql_slave_status_seconds_behind_master
mysql_slave_status_last_io_error_timestamp
mysql_slave_status_last_sql_error_timestamp

# 告警規則:
- Seconds_Behind_Master > 300 (5 分鐘) → 警告
- Slave_IO_Running != Yes OR Slave_SQL_Running != Yes → 致命
- Last_IO_Error / Last_SQL_Error 非空 → 致命

常見故障處理

故障類型	典型錯誤	處理步驟
IO 線程故障	Connection timeout / Access denied	檢查網絡/防火牆 → 驗證用戶權限 → 確認 Master Binlog 存在
SQL 線程故障	Duplicate entry / Foreign key fails / Deadlock	1. SHOW SLAVE STATUS 記錄錯誤位置 2. 分析衝突數據 3. 跳過/修正/重搭
數據不一致	校驗和不匹配 / 業務發現異常	pt-table-checksum 檢測 → pt-table-sync 修復 → 或重搭 Slave
Relay Log 損壞	Relay log read failure	STOP SLAVE → RESET SLAVE → 重新 CHANGE MASTER → START SLAVE

延遲優化策略

並行復制：slave_parallel_workers=4 (5.6+ 基於庫)、slave_parallel_type=LOGICAL_CLOCK (5.7+ 基於組提交)
硬件優化：Slave 使用 SSD、獨立網卡、關閉 swap
參數調優：relay_log_purge=1, sync_relay_log=1000, slave_net_timeout=60
業務分離：大事務拆分、避免長事務阻塞 SQL 線程