MySQL 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 指令不被支援，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 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”.

      本文轉自crazy_charles 51CTO部落格，原文連結：http://blog.51cto.com/douya/1795359，如需轉載請自行聯系原作者