The difference between reset slave and reset master in MySQL

The syntax for RESET slave is as follows:


RESET SLAVE [ALL] [channel_option]

channel_option: 
    FOR CHANNEL channel


Among them, Channel_option is mainly for the 5.7.6 introduction of multi-source replication.


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. To use RESET SLAVE, the slave replication threads must be stopped (use STOP SLAVE if necessary).

In fact, it is to delete the Master.info and Relay-log.info files directly, and delete all the relay log, and then regenerate a new relay log, even if the relay log in SQL is not completed by the SQL thread.

But

RESET slave has a problem, although it deleted the above file, but the change master information in memory is not deleted, at this time, can directly execute the start slave, But because Master.info and relay-log.info are removed, it will accept the master's Binlog from the beginning and apply.

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

Relative to RESET Slave,reset SLAVE all also deletes the in-memory connection information, at which point the execution of the start SLAVE will error.
As shown below:

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


Note: Starting with MySQL 5.6.7, reset SLAVE and reset SLAVE all will implicitly commit the current transaction.
RESET MASTER


inch file file file.

Delete all binary logs and recreate a new binary log

In the Gtid environment,


RESET Master clears the values of the system variables gtid_purged and gtid_executed.

Starting with MySQL 5.7.5, the statement also empties the contents of the mysql.gtid_executed, which holds gtid information so that Binlog is not enabled in slave.


The difference between RESET master and purge BINARY logs


1. RESET master Deletes all binary logs, while purge binary logs is a point-in-time deletion


The PURGE BINARY logs syntax is as follows:
PURGE { BINARY | MASTER } LOGS
    { TO ‘log_name‘ | BEFORE datetime_expr }

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


2. In a normal master-slave replication environment, if you perform reset master on master, the result is unpredictable. However, using the Purge BINARY logs statement to delete the Binlog does not have much effect (provided that the events in the deleted Binlog have been transferred to the slave)

Reference
1. http://dev.mysql.com/doc/refman/5.7/en/reset-slave.html

2. http://dev.mysql.com/doc/refman/5.7/en/reset-master.html

3. http://dev.mysql.com/doc/refman/5.7/en/purge-binary-logs.html

The difference between reset slave and reset master in MySQL