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.

*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.)

For a server where GTIDs are in use (gtid_mode is ON), issuing RESET
SLAVE has no effect on the GTID execution history. The statement does
not change the values of gtid_executed or gtid_purged, or the
mysql.gtid_executed table. If you need to reset the GTID execution
history, use RESET MASTER, even if the GTID-enabled server is a
replication slave where binary logging is disabled.

RESET SLAVE requires the RELOAD privilege.

To use RESET SLAVE, the slave replication threads must be stopped, so
on a running slave use STOP SLAVE before issuing RESET SLAVE. To use
RESET SLAVE on a Group Replication group member, the member status must
be OFFLINE, meaning that the plugin is loaded but the member does not
currently belong to any group. A group member can be taken offline by
using a STOP GROUP REPLICATION statement.

The optional FOR CHANNEL channel clause enables you to name which
replication channel the statement applies to. 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. If no channel is named and no
extra channels exist, the statement applies to the default 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
https://dev.mysql.com/doc/refman/8.0/en/replication-channels.html for
more information.

RESET SLAVE does not change any replication connection parameters such
as the master host, master port, master user, or master password. RESET
SLAVE also does not affect the PRIVILEGE_CHECKS_USER account. If you
want to reset the connection parameters intentionally, you need to use
RESET SLAVE ALL, which clears the connection parameters, including the
MASTER_USER and PRIVILEGE_CHECKS_USER accounts. RESET SLAVE ALL also
clears the IGNORE_SERVER_IDS list set by CHANGE MASTER TO. When you
have used RESET SLAVE ALL, you must issue a CHANGE MASTER TO statement
after the server start to specify new connection parameters.

In the event of a server crash or deliberate restart after issuing
RESET SLAVE but before issuing START SLAVE, retention of the
replication connection parameters depends on the repository used for
the master info log:

o From MySQL 8.0.13, when master_info_repository=TABLE is set on the
  server (which is the default from MySQL 8.0), replication connection
  parameters are preserved in the crash-safe InnoDB table
  mysql.slave_master_info as part of the RESET SLAVE operation. They
  are also retained in memory. In the event of a server crash or
  deliberate restart after issuing RESET SLAVE but before issuing START
  SLAVE, the replication connection parameters are retrieved from the
  table and reused for the new connection.

o When master_info_repository=FILE is set on the server, replication
  connection parameters are only retained in memory. If the slave
  mysqld is restarted immediately after issuing RESET SLAVE due to a
  server crash or deliberate restart, the connection parameters are
  lost. In that case, you must issue a CHANGE MASTER TO statement after
  the server start to respecify the connection parameters before
  issuing START SLAVE.

RESET SLAVE does not change any replication filter settings (such as
--replicate-ignore-table) for channels affected by the statement.
However, RESET SLAVE ALL removes the replication filters that were set
on the channels deleted by the statement. When the deleted channel or
channels are recreated, any global replication filters specified for
the slave are copied to them, and no channel specific replication
filters are applied. For more information see
https://dev.mysql.com/doc/refman/8.0/en/replication-rules-channel-based
-filters.html.

RESET SLAVE causes an implicit commit of an ongoing transaction. See
https://dev.mysql.com/doc/refman/8.0/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.

RESET SLAVE does not reset the heartbeat period
(Slave_heartbeat_period) or SSL_VERIFY_SERVER_CERT.

*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: https://dev.mysql.com/doc/refman/8.0/en/reset-slave.html

