MySQL主從配置中RESET SLAVE和RESET MASTER的區別詳解

在mysql主從配置中我們會用到RESET SLAVE和RESET MASTER了，那麼RESET SLAVE和RESET MASTER的區別是什麼它們在使用時需要注意什麼呢，今天我們一起來看看吧。

RESET SLAVE和RESET MASTER的區別

RESET SLAVE的語法如下：

RESET SLAVE [ALL] [channel_option]

channel_option:
    FOR CHANNEL channel
其中，channel_option主要是針對5.7.6引入的多源復制。

RESET SLAVE

官方的解釋如下

RESET SLAVE makes the slave forget its replication position in the master's binary log. This statement is meant to be used for a clean start: It clears the master info and relay log info repositories, deletes all the relay log files, and starts a new relay log file. It also resets to 0 the replication delay specified with the MASTER_DELAY option to CHANGE MASTER TO. To use RESET SLAVE, the slave replication threads must be stopped (use STOP SLAVE if necessary).
其實，它是直接刪除master.info和relay-log.info文件，並刪除所有的relay log，然後重新生成一個新的relay log，即使relay log中還有SQL沒有被SQL線程apply完。

但是

RESET SLAVE有個問題，它雖然刪除了上述文件，但內存中的change master信息並沒有刪除，此時，可直接執行start slave，但因為刪除了master.info和relay-log.info，它會從頭開始接受主的binlog並應用。

RESET SLAVE does not change any replication connection parameters such as master host, master port, master user, or master password, which are retained in memory. This means that START SLAVE can be issued without requiring a CHANGE MASTER TO statement following RESET SLAVE.
RESET SLAVE ALL

相對於RESET SLAVE，RESET SLAVE ALL還會刪除內存中的連接信息，這個時候，執行start slave會報錯。

如下所示：

mysql> stop slave;
Query OK, 0 rows affected (0.00 sec)

mysql> reset slave all;
Query OK, 0 rows affected (0.01 sec)

mysql> start slave;
ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO
注意：從MySQL 5.6.7開始，RESET SLAVE和RESET SLAVE ALL會對當前事務進行隱式提交。

RESET MASTER

Deletes all binary log files listed in the index file, resets the binary log index file to be empty, and creates a new binary log file.
刪除所有的二進制日志，並重新創建一個新的二進制日志

在GTID環境中，

RESET MASTER會清除掉系統變量gtid_purged和gtid_executed的值。

從MySQL 5.7.5開始，該語句同樣會清空mysql.gtid_executed的內容，該表保存著GTID的信息，這樣，在slave中可不用開啟binlog。

RESET MASTER和PURGE BINARY LOGS的區別

1. RESET MASTER會刪除所有的二進制日志，而PURGE BINARY LOGS是一種基於時間點的刪除

PURGE BINARY LOGS語法如下：

PURGE { BINARY | MASTER } LOGS
    { TO 'log_name' | BEFORE datetime_expr }
譬如：

PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2008-04-02 22:46:26';

2. 在正常的主從復制環境中，如果在master上執行RESET MASTER，結果是不可預測的。但使用PURGE BINARY LOGS語句刪除binlog沒多大影響（前提是，刪除的binlog中的events已經傳輸到slave上）

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”.