Syntax:
RESET SLAVE [ALL] [channel_option]

channel_option:
    FOR CHANNEL channel

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. RESET SLAVE does not change the values of
gtid_executed or gtid_purged. To use RESET SLAVE, the slave replication
threads must be stopped, so on a running slave use STOP SLAVE before
issuing RESET SLAVE.

*Note*:

All relay log files are deleted, even if they have not been completely
executed by the slave SQL thread. (This is a condition likely to exist
on a replication slave if you have issued a STOP SLAVE statement or if
the slave is highly loaded.)

The optional FOR CHANNEL channel clause added in MySQL 5.7.6 enables
you to choose which replication channel the statement applies to. If no
clause is set and no extra channels exist, the statement applies to the
default channel and behaves the same as versions of MySQL prior to
5.7.6. Providing a FOR CHANNEL channel clause applies the RESET SLAVE
statement to a specific replication channel. Combining a FOR CHANNEL
channel clause with the ALL option deletes the specified channel.
Issuing a RESET SLAVE ALL statement without a FOR CHANNEL channel
clause when multiple replication channels exist deletes all replication
channels and recreates only the default channel. See
http://dev.mysql.com/doc/refman/5.7/en/replication-channels.html for
more information.

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.

Connection parameters are reset by RESET SLAVE ALL. (RESET SLAVE
followed by a restart of the slave mysqld also does this.)

In MySQL 5.7 RESET SLAVE causes an implicit commit of an ongoing
transaction. See
http://dev.mysql.com/doc/refman/5.7/en/implicit-commit.html.

If the slave SQL thread was in the middle of replicating temporary
tables when it was stopped, and RESET SLAVE is issued, these replicated
temporary tables are deleted on the slave.

Prior to MySQL 5.7.5, RESET SLAVE also had the effect of resetting both
the heartbeat period (Slave_heartbeat_period) and
SSL_VERIFY_SERVER_CERT. This issue is fixed in MySQL 5.7.5 and later.
(Bug #18777899, Bug #18778485)

Prior to MySQL 5.7.5, RESET SLAVE ALL did not clear the
IGNORE_SERVER_IDS list set by CHANGE MASTER TO. In MySQL 5.7.5 and
later, the statement clears the list. (Bug #18816897)

*Note*:

When used on an NDB Cluster replication slave SQL node, RESET SLAVE
clears the mysql.ndb_apply_status table. You should keep in mind when
using this statement that ndb_apply_status uses the NDB storage engine
and so is shared by all SQL nodes attached to the slave cluster.

You can override this behavior by issuing SET GLOBAL
@@ndb_clear_apply_status=OFF prior to executing RESET SLAVE, which
keeps the slave from purging the ndb_apply_status table in such cases.

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

