MySQL主从配置中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”.