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
RESET SLAVE does
not change the values of
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
STOP SLAVE statement
or if the slave is highly loaded.)
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
GROUP REPLICATION statement.
clause enables you
to name which replication channel the statement applies to.
clause applies the
RESET SLAVE statement to a specific
replication channel. Combining a
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
ALL statement without a
multiple replication channels exist deletes
all replication channels and recreates only
the default channel. See Section 17.2.3, “Replication Channels”
for more information.
RESET SLAVE does not change any
replication connection parameters such as master host, master
port, master user, or master password.
From MySQL 8.0.13, when
master_info_repository=TABLEis set on the server (which is the default from MySQL 8.0), replication connection parameters are preserved in the crash-safe
mysql.slave_master_infoas part of the
RESET SLAVEoperation. They are also retained in memory. In the event of a server crash or deliberate restart after issuing
RESET SLAVEbut before issuing
START SLAVE, the replication connection parameters are retrieved from the table and reused for the new connection.
master_info_repository=FILEis set on the server, replication connection parameters are only retained in memory. If the slave mysqld is restarted immediately after issuing
RESET SLAVEdue to a server crash or deliberate restart, the connection parameters are lost. In that case, you must issue a
CHANGE MASTER TOstatement after the server start to respecify the connection parameters before issuing
If you want to reset the connection parameters intentionally,
you need to use
ALL, which clears the connection parameters. In that
case, you must issue a
TO statement after the server start to specify the new
RESET SLAVE ALL clears the
IGNORE_SERVER_IDS list set by
CHANGE MASTER TO.
RESET SLAVE does not change any
replication filter settings (such as
channels affected by the statement. However,
SLAVE ALLremoves 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
Section 18.104.22.168, “Replication Channel Based Filters”.
RESET SLAVE causes an implicit commit of an
ongoing transaction. See Section 13.3.3, “Statements That Cause an Implicit Commit”.
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
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.