RESET MASTER
删除所有 index file 中记录的所有 binlog 文件,将日志索引文件清空,创建一个新的日志文件,这个命令通常仅仅用于第一次用于搭建主从关系的时的主库。
注意,reset master 不同于 purge binary log 的两处地方。
- reset master 将删除日志索引文件中记录的所有 binlog 文件,创建一个新的日志文件起始值从 000001 开始,然而 purge binary log 命令并不会修改记录 binlog 的顺序的数值。
- 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 文件并重新启用一个新的 relay log 文件。
使用 reset slave 之前必须使用 stop slave 命令将复制进程停止。
注:所有的 relay log 将被删除,不管他们是否被 SQL thread 进程完全应用(这种情况发生于备库延迟以及在备库执行了 stop slave 命令),存储复制链接信息的 master.info 文件将被立即清除,如果 SQL thread 正在复制临时表的过程中,执行了 stop slave ,并且执行了 reset slave,这些被复制的临时表将被删除。
RESET SLAVE ALL
在 MySQL 5.6 版本中 reset slave 并不会清理存储于内存中的复制信息,比如 master host,master port,master user,or master password,也就是说如果没有使用 change master 命令做重新定向,执行 start slave 还是会指向旧的 master 上面。
当从库执行 reset slave 之后,将 mysqld shutdown 复制参数将被重置。
在 MySQL 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”.