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 命令不被支持，reset master 將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 mysql5.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”.
參考
http://dev.mysql.com/doc/refman/5.6/en/reset-master.html
http://dev.mysql.com/doc/refman/5.6/en/reset-slave.html
http://blog.csdn.net/zyz511919766/article/details/49336289