RESET MASTER 和RESET SLAVE區別

RESET MASTER
刪除所有index file 中記錄的所有binlog 檔案，將日誌索引檔案清空，建立一個新的記錄檔，這個命令通常僅僅用於第一次用於搭建主從關係的時的主庫，
注意
  reset master 不同於purge binary log的兩處地方
1 reset master 將刪除日誌索引檔案中記錄的所有binlog檔案，建立一個新的記錄檔 起始值從000001 開始，然而purge binary log 命令並不會修改記錄binlog的順序的數值
2 reset master 不能用於有任何slave 正在啟動並執行主從關係的主庫。因為在slave 運行時刻 reset master 命令不被支援，resetmaster 將master 的binlog從000001 開始記錄,slave 記錄的master log 則是reset master 時主庫的最新的binlog,從庫會報錯無法找的指定的binlog檔案。

In MySQL 5.6.5 and later, RESET MASTER also clears the values of the gtid_purged system variable (known as gtid_lost in MySQL 5.6.8 and earlier) as well as the global value of the gtid_executed (gtid_done, prior to MySQL 5.6.9) system variable (but not its session value); that is, executing this statement sets each of these values to an empty string ('')


RESET SLAVE
reset slave 將使slave 忘記主從複製關係的位置資訊。該語句將被用於乾淨的啟動, 它刪除master.info檔案和relay-log.info 檔案以及所有的relay log 檔案並重新啟用一個新的relaylog檔案。
使用reset slave之前必須使用stop slave 命令將複製進程停止。

注 所有的relay log將被刪除不管他們是否被SQL thread進程完全應用(這種情況發生於備庫延遲以及在備庫執行了stop slave 命令),儲存複製連結資訊的master.info檔案將被立即清除,如果SQL thread 正在複製暫存資料表的過程中，執行了stop slave ，並且執行了reset slave，這些被複製的暫存資料表將被刪除。


RESET SLAVE ALL
在 5.6 版本中 reset slave 並不會清理儲存於記憶體中的複製資訊比如 master host, master port, master user, or master password,也就是說如果沒有使用change master 命令做重新定向，執行start slave 還是會指向舊的master 上面。
當從庫執行reset slave之後,將mysqld shutdown 複製參數將被重設。
在5.6.3 版本以及以後 使用使用 RESET SLAVE ALL 來完全的清理複製串連參數資訊。(Bug #11809016)
RESET SLAVE ALL does not clear the IGNORE_SERVER_IDS list set by CHANGE MASTER TO. This issue is fixed in MySQL 5.7. (Bug #18816897)
In MySQL 5.6.7 and later, RESET SLAVE causes an implicit commit of an ongoing transaction. See Section 13.3.3, “Statements That Cause an Implicit Commit”.