您现在的位置：程式碼之家 >> 數據庫知識 > >> MySQL 資料庫 >> MySQL 資料庫相關知識

MySQL 主從復制部署全流程與常見錯誤排查：GTID、Binlog、故障切換實戰指南

編輯：MySQL 資料庫相關知識

MySQL 主從復制是讀寫分離、災備、零停機遷移的基石。本文記錄基於 Binlog 位點與 GTID 兩種模式的部署步驟、關鍵參數、驗證方法，並深度剖析 Slave_IO_Running: No、1236 錯誤、主從延遲、數據不一致等高頻故障的根因與修復方案。

一、架構優勢與適用場景

優勢	說明
讀寫分離	主庫寫、從庫讀，降低主庫壓力 60%+
備份無影響	從庫執行 `mysqldump`/`xtrabackup`，主庫零干擾
故障切換	主庫故障秒級提升從庫為主（配合 MHA/Orchestrator）
異構環境	跨版本、跨存儲引擎、跨雲廠商同步

風險提示：主庫誤操作（DROP/TRUNCATE/錯誤 UPDATE）會同步到從庫，**主從 ≠ 備份**，必須配合延遲從庫或定期全量備份

二、環境準備

角色	IP	Server ID	MySQL 版本
Master	10.1.1.45	45	5.7+ (支援 GTID)
Slave	10.1.1.43	43	5.7+

三、Master 配置 `/etc/my.cnf`

[mysqld]
server-id=45
log-bin=/opt/log.bin/45
binlog-format=ROW
gtid-mode=ON
enforce-gtid-consistency=ON
log-slave-updates=1
sync_binlog=1
innodb_flush_log_at_trx_commit=1
expire_logs_days=7
max_binlog_size=1G

四、建立復制賬號

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.1.1.43' IDENTIFIED BY 'StrongReplPass';
FLUSH PRIVILEGES;

五、基線數據同步（熱備份法）

# Master 導出（單事務、刷新日誌、記錄位點）
mysqldump -uroot -p --single-transaction --flush-logs --master-data=2 --all-databases > all.sql

# 檢查位點信息
head -40 all.sql | grep "CHANGE MASTER TO"
# 輸出: CHANGE MASTER TO MASTER_LOG_FILE='45.000064', MASTER_LOG_POS=98;

六、Slave 配置與啟動

[mysqld]
server-id=43
relay-log=relay-bin
log-slave-updates=1
gtid-mode=ON
enforce-gtid-consistency=ON
skip-slave-start          # 防止啟動前誤啟動
read-only=1               # 防止誤寫入

# 導入基線數據
mysql -uroot -p < all.sql

# 配置復制 (GTID 模式無需指定文件/位點)
CHANGE MASTER TO 
    MASTER_HOST='10.1.1.45',
    MASTER_USER='repl',
    MASTER_PASSWORD='StrongReplPass',
    MASTER_AUTO_POSITION=1;

START SLAVE;

七、驗證復制狀態

SHOW SLAVE STATUS\G
# 關鍵指標
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
Retrieved_Gtid_Set: xxxx:1-100
Executed_Gtid_Set:  xxxx:1-100
Auto_Position: 1

八、常見故障深度排查

故障 1：Slave_IO_Running: No + Last_IO_Error: 1236

Error: Client requested master to start replication from impossible position

根因：sync_binlog=0 導致 Master 宕機時 Binlog Cache 未刷盤，Slave 記錄的位點大於實際文件大小

修復：跳過至下一個 Binlog 文件

STOP SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='45.000065', MASTER_LOG_POS=4, MASTER_AUTO_POSITION=0;
START SLAVE;

預防：Master 強制 sync_binlog=1、innodb_flush_log_at_trx_commit=1

故障 2：主從數據不一致

檢測工具：pt-table-checksum (Percona Toolkit)

pt-table-checksum --replicate=percona.checksums h=master,u=repl,p=pass --databases=db1

修復工具：pt-table-sync（謹慎使用，建議從庫重建）

故障 3：主從延遲 (Seconds_Behind_Master 高)

原因	解決
從庫硬件較弱	升級配置、啟用多線程復制 `slave_parallel_workers=4`
大事務阻塞	業務拆分小事務、避免長事務
慢查詢回放	優化從庫索引、`log_slow_slave_statements=1`
網絡延遲	專線/同可用區部署、壓縮協議 `slave_compressed_protocol=1`

故障 4：GTID 集合異常 (Executed_Gtid_Set 缺失)

原因：從庫誤執行寫入、手動注入 GTID、RESET MASTER

修復：重新搭建從庫，或使用 SET GTID_PURGED 修正（高風險）

九、多線程復制優化 (MySQL 5.7+)

slave_parallel_workers=4
slave_parallel_type=LOGICAL_CLOCK
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON

十、監控與告警體系

核心指標：Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master、Relay_Log_Space
告警閾值：延遲 > 30s 告警、> 300s 嚴重、IO/SQL 線程 Stop 立即告警
巡檢腳本：每分鐘 SHOW SLAVE STATUS 解析入 Prometheus
延遲從庫：部署 1 台 MASTER_DELAY=3600 從庫，防誤操作回滾