Detailed description of the differences between reset slave and reset master in MySQL MASTER-SLAVE configuration

Difference between reset slave and RESET MASTER

The reset slave syntax is as follows:

Reset slave [ALL] [channel_option]

Channel_option:
For channel channel
Among them, channel_option is mainly for multi-source replication introduced in 5.7.6.

RESET SLAVE

The official explanation is as follows:

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 use reset slave, the slave replication threads must be stopped (use stop slave if necessary ).
In fact, it is to directly delete the master.info and relay-log.info files, and delete all the relay logs, and then re-generate a new relay log, even if the relay log contains SQL not completed by the SQL thread apply.

However

Reset slave has a problem, although it deleted the above files, but the change master information in the memory is not deleted, at this time, you can directly execute start slave, but because the master.info and relay-log.info are deleted, it receives and applies the primary binlog from the beginning.

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

Compared with reset slave, reset slave all also deletes connection information in the memory. If you run start slave, an error is returned.

As follows:

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
Note: From MySQL 5.6.7, reset slave and reset slave all implicitly commit the current transaction.

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.
Delete all binary logs and create a new binary log.

In the GTID environment,

The reset master will clear the values of the system variables gtid_purged and gtid_executed.

Starting from MySQL 5.7.5, this statement also clears the content of mysql. gtid_executed. The table stores GTID information, so that binlog can be disabled in slave.

Difference between reset master and PURGE BINARY LOGS

1. reset master will delete all binary logs, while purge binary logs is a time point-based deletion method.

The purge binary logs syntax is as follows:

PURGE {BINARY | MASTER} LOGS
{TO 'log _ name' | BEFORE datetime_expr}
For example:

Purge binary logs to 'MySQL-bin.010 ';
Purge binary logs before '2017-04-02 22:46:26 ';

2. In a normal master-slave replication environment, if you execute reset master on the master, the result is unpredictable. However, using the purge binary logs statement to delete a binlog does not have much impact (the premise is that the events in the deleted binlog have been transmitted to the slave)

Precautions for using the reset master and reset slave commands

RESET MASTER
Delete all binlog files recorded in all index files, clear the log index files, and create a new log file. This command is usually used only for the first time when the master-slave relationship is set up,
Note:
The reset master is different from the purge binary log.
1 reset master will delete all binlog files recorded in the log index file and create a new log file starting from 000001, however, the purge binary log command does not modify the values that record the binlog sequence.
2 reset master cannot be used for the master database with any active/standby relationship of slave. Because the reset master Command is not supported at the slave runtime, the resetmaster records the binlog of the master from 000001, and the master log recorded by the slave is the latest binlog of the master database when the reset master, the slave database reports an error for the specified binlog file that cannot be found.

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 will make slave forget the location information of the master-slave replication relationship. This statement will be used for a clean start, which deletes the master.info file and the relay-log.info file as well as all the relay log files and re-enables a new relaylog file.
Before using reset slave, you must use the stop slave command to stop the replication process.

Note that all relay logs will be deleted whether or not they are fully applied by the SQL thread process (this happens when the standby database delays and the stop slave command is executed in the standby database ), the master.info file that stores the copied link information will be cleared immediately. If the SQL thread is copying a temporary table, the stop slave command is executed and the reset slave command is executed, these temporary tables will be deleted.

RESET SLAVE ALL
In version 5.6, reset slave does not clean up the replication information stored in the memory, such as the master host, master port, master user, or master password. That is to say, if the change master Command is not used for redirection, executing start slave still points to the old master.
After the slave database executes reset slave, the mysqld shutdown replication parameter is reset.
Use reset slave all in versions 5.6.3 and later to completely clean up the replication connection parameter information. (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 ".