What is the difference between reset slave and reset master in MySQL? mysqlslave

What is the difference between reset slave and reset master in MySQL? mysqlslave

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. 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 TO

 

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 '2008-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)

 

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