MySQL 5.6 Reference Manual Including MySQL NDB Cluster 7.3-7.4 Reference Guide
RESET SLAVE [ALL]
RESET SLAVE
makes the replica
forget its replication position in the source's binary log. This
statement is meant to be used for a clean start: It clears the
replication metadata 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 replication
threads must be stopped, so on a running replica use
STOP SLAVE
before issuing
RESET SLAVE
.
All relay log files are deleted, even if they have not been
completely executed by the replication SQL thread. (This is a
condition likely to exist on a replica if you have issued a
STOP SLAVE
statement or if the
replica is highly loaded.)
In MySQL 5.6 (unlike the case in MySQL 5.1 and
earlier), RESET SLAVE
does not
change any replication connection parameters such as the
source's host name and port or the replication user account name
and 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 if the replica
mysqld is shut down following RESET
SLAVE
. In MySQL 5.6.3 and later, you can instead use
RESET SLAVE ALL
to reset these connection
parameters (Bug #11809016).
RESET SLAVE ALL
does not clear the
IGNORE_SERVER_IDS
list set by
CHANGE MASTER TO
. This issue is
fixed in MySQL 5.7. (Bug #18816897)
In MySQL 5.6.7 and later, RESET SLAVE
causes
an implicit commit of an ongoing transaction. See
Section 13.3.3, “Statements That Cause an Implicit Commit”.
If the replication 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 replica.
When used on an NDB Cluster replica 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 replica cluster.
Beginning with MySQL NDB Cluster 7.4.9, you can override this
behavior by issuing
SET
GLOBAL
@@
ndb_clear_apply_status=OFF
prior to executing RESET SLAVE
, which keeps
the replica from purging the
ndb_apply_status
table in such cases.