前言

在 MySQL 主從複制運維中，RESET SLAVE 與 RESET MASTER 是兩個極易混淆但用途截然不同的指令。錯誤使用可能導致複制中斷、資料不一致甚至主庫 Binlog 遺失。本文詳細對比兩者差異、參數細節、GTID 環境行為與操作禁忌。

核心差異速查表

指令	作用對象	核心動作	典型場景
RESET SLAVE	從庫	清除複制位點、刪除 Relay Log、重置複制狀態	從庫重新同步、拓撲變更、測試環境重置
RESET MASTER	主庫	刪除所有 Binlog、重置 Binlog 索引、生成新 Binlog	主庫初始化搭建、測試環境清理、Binlog 損壞重建

RESET SLAVE 詳細解析

語法

RESET SLAVE [ALL] [FOR CHANNEL channel]  -- 5.7.6+ 多源複制支援 channel_option

RESET SLAVE (基礎版)

• 刪除 master.info、relay-log.info 檔案
• 刪除所有 Relay Log 檔案
• 建立新的空 Relay Log 檔案
• 將 MASTER_DELAY 重置為 0
• 不變更：記憶體中的連線參數 (master host/port/user/password)

效果：執行後可直接 START SLAVE，從庫將從主庫 Binlog 開頭重新複制 (即使 Relay Log 尚有未應用事件)。

STOP SLAVE;
RESET SLAVE;
START SLAVE;  -- 直接生效，無需 CHANGE MASTER TO

RESET SLAVE ALL (5.6.3+)

• 包含基礎版所有動作
• 額外清除記憶體中的複制連線參數 (master host/port/user/password)

STOP SLAVE;
RESET SLAVE ALL;
START SLAVE;  -- ERROR 1200: The server is not configured as slave; fix with CHANGE MASTER TO

需重新執行 CHANGE MASTER TO 才能啟動複制。

版本演進與隱式提交

• 5.6.7+：RESET SLAVE / RESET SLAVE ALL 引發隱式提交 (進行中事務自動提交)
• 5.7+：修復 RESET SLAVE ALL 不清除 IGNORE_SERVER_IDS 列表的 Bug (Bug #18816897)

RESET MASTER 詳細解析

核心動作

• 刪除 Binlog 索引檔案中列出的所有 Binlog 檔案
• 清空 Binlog 索引檔案
• 建立新的 Binlog 檔案 (編號歸零：mysql-bin.000001)

GTID 環境額外行為

• 清除系統變數 gtid_purged、gtid_executed (全域值，Session 值保留)
• 5.7.5+：清空 mysql.gtid_executed 表內容 (從庫可不開啟 Binlog 仍能追蹤 GTID)

RESET MASTER vs PURGE BINARY LOGS

差異點	RESET MASTER	PURGE BINARY LOGS
刪除範圍	所有 Binlog	指定時間點/檔案前
Binlog 編號	重置為 000001	保持原有編號序列
主從環境安全性	極度危險：從庫會找不到舊 Binlog 報錯	相對安全：前提是被刪 Binlog 已同步至從庫

-- PURGE 範例
PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2024-01-01 00:00:00';

操作禁忌與最佳實踐

總結

RESET SLAVE 是從庫複制狀態的「軟重置」，保留連線參數便於快速重啟；RESET SLAVE ALL 是「硬重置」，需重新配置連線。RESET MASTER 是主庫 Binlog 的「核彈級重置」，嚴禁在有從庫運行時使用。生產環境清理 Binlog 必須使用 PURGE BINARY LOGS 並驗證從庫同步進度。GTID 環境下兩指令均會同步重置 GTID 狀態，簡化了拓撲重構流程。