MySQL主從複製詳解

基本概念與作用

MySQL主從複製是一種數據同步機制，允許將一個MySQL服務器（主服務器）的數據變更實時複製到一個或多個MySQL服務器（從服務器）。主從複製主要有以下作用：

• 數據備份：從服務器可作為主服務器的實時備份
• 負載均衡：讀操作分發到從服務器，減輕主服務器壓力
• 高可用架構：主服務器故障時可快速切換到從服務器
• 數據分發：將數據複製到地理分佈式服務器
• 版本升級測試：在從服務器上測試升級而不影響生產環境

複製原理（三線程模型）

MySQL主從複製基於二進制日誌（binary log），採用三個線程協同工作：

1. 主服務器上的Binlog Dump線程：當從服務器連接時創建，讀取主服務器二進制日誌併發送給從服務器
2. 從服務器上的I/O線程：連接主服務器，接收二進制日誌事件並寫入從服務器的中繼日誌（relay log）
3. 從服務器上的SQL線程：讀取中繼日誌中的事件，並在從服務器上執行這些事件，實現數據同步

複製類型

根據複製內容和方式，MySQL主從複製主要分為以下類型：

1. 基於語句的複製（SBR - Statement-Based Replication）

• 記錄SQL語句而非數據變更
• 優點：二進制日誌較小，節省存儲空間
• 缺點：某些非確定性函數（如NOW()、RAND()）可能導致數據不一致

2. 基於行的複製（RBR - Row-Based Replication）

• 記錄實際數據行的變更
• 優點：複製更精確，適用於所有場景
• 缺點：二進制日誌較大，可能增加網絡傳輸量

3. 混合複製模式（Mixed Replication）

• 默認使用語句複製，必要時自動切換到行復制
• 結合了兩種模式的優點

4. GTID複製（Global Transaction ID）

• 基於全局事務ID進行復制，而非基於日誌文件位置
• 簡化了複製配置和故障轉移
• 支持並行複製，提高性能

配置步驟

1. 主服務器配置

# my.cnf配置
server-id = 1               # 唯一ID，不能和從服務器重複
binlog_format = ROW         # 推薦使用ROW格式
log_bin = mysql-bin         # 啓用二進制日誌
binlog_row_image = FULL     # 記錄完整行數據
max_binlog_size = 1G        # 二進制日誌文件大小
# 可選：只記錄特定數據庫變更
binlog_do_db = test_db

重啓MySQL後，創建複製用户：

CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

獲取主服務器狀態：

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

2. 從服務器配置

# my.cnf配置
server-id = 2               # 唯一ID，不能和主服務器重複
relay_log = relay-log       # 啓用中繼日誌
read_only = ON              # 設置為只讀模式

重啓MySQL後，配置主從複製：

CHANGE MASTER TO
  MASTER_HOST = 'master_host_ip',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'password',
  MASTER_LOG_FILE = 'mysql-bin.000001',  # 從SHOW MASTER STATUS獲取
  MASTER_LOG_POS = 154;                  # 從SHOW MASTER STATUS獲取

START SLAVE;

檢查複製狀態：

SHOW SLAVE STATUS\G

常見問題與解決方案

1. 複製延遲

• 原因：從服務器I/O或SQL線程處理慢、網絡延遲、主服務器寫入量過大

• 解決：

  • 升級從服務器硬件
  • 使用並行複製（slave_parallel_workers > 1）
  • 優化主服務器寫入操作
  • 考慮使用多線程複製插件

2. 複製中斷

• 原因：主從數據不一致、從服務器上的臨時表問題、權限問題

• 解決：

  • 使用STOP SLAVE和START SLAVE重啓複製
  • 使用SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1跳過有問題的事件
  • 重新搭建複製（作為最後的選擇）

3. 數據不一致

• 原因：使用了非確定性函數、網絡問題、複製中斷

• 解決：

  • 使用pt-table-checksum和pt-table-sync工具檢測和修復
  • 採用基於行的複製
  • 定期驗證主從數據一致性

4. 主從切換

• 手動切換：

  1. 停止主服務器寫入
  2. 等待從服務器完全同步
  3. 配置從服務器為新主服務器
  4. 更新應用連接配置
• 半同步複製：確保事務至少已複製到一個從服務器
• MHA：使用Master High Availability工具實現自動故障轉移

複製優化

1. 性能優化

• 使用半同步複製（semi-synchronous replication）提高數據安全性
• 配置並行複製提高從服務器處理能力
• 使用GTID複製簡化管理和故障轉移
• 適當增加innodb_flush_log_at_trx_commit值提升性能（但會降低可靠性）

2. 可靠性優化

• 啓用sync_binlog = 1確保二進制日誌及時刷盤
• 配置半同步複製防止數據丟失
• 使用監控工具（如PMM、Zabbix）實時監控複製狀態
• 定期執行數據一致性檢查

高級複製架構

1. 級聯複製

主→從→從的多級複製架構，適用於大規模部署場景

2. 雙主複製（互為主從）

• 配置兩個服務器互為主從，實現雙向複製
• 需要注意設置auto_increment_increment和auto_increment_offset避免主鍵衝突

3. 多源複製

一個從服務器可同時從多個主服務器複製數據，適用於數據整合場景

監控與維護

• 定期檢查複製狀態（SHOW SLAVE STATUS）
• 監控複製延遲（Seconds_Behind_Master）
• 定期備份二進制日誌和中繼日誌
• 注意二進制日誌文件管理，防止磁盤空間耗盡

最佳實踐建議

1. 生產環境推薦使用基於行的複製（RBR）和GTID
2. 配置適當的服務器ID，確保唯一性
3. 為複製賬户設置嚴格的權限控制
4. 實施定期備份策略，不僅依賴複製作為備份
5. 監控複製延遲，設置告警閾值
6. 升級時先升級從服務器，驗證無誤後再升級主服務器