MySQL 5.7 Reference Manual Including MySQL NDB Cluster 7.5 and NDB Cluster 7.6
RESET MASTER
Use this statement with caution to ensure you do not lose any wanted binary log file data and GTID execution history.
RESET MASTER
requires the
RELOAD
privilege.
For a server where binary logging is enabled
(log_bin
is
ON
), RESET MASTER
deletes
all existing binary log files and resets the binary log index
file, resetting the server to its state before binary logging
was started. A new empty binary log file is created so that
binary logging can be restarted.
For a server where GTIDs are in use
(gtid_mode
is
ON
), issuing RESET MASTER
resets the GTID execution history. The value of the
gtid_purged
system variable is
set to an empty string (''
), the global value
(but not the session value) of the
gtid_executed
system variable
is set to an empty string, and the
mysql.gtid_executed
table is cleared (see
mysql.gtid_executed Table). If the
GTID-enabled server has binary logging enabled,
RESET MASTER
also resets the
binary log as described above. Note that
RESET MASTER
is the method to
reset the GTID execution history even if the GTID-enabled server
is a replica where binary logging is disabled;
RESET SLAVE
has no effect on the
GTID execution history. For more information on resetting the
GTID execution history, see
Resetting the GTID Execution History.
The effects of RESET MASTER
differ from those of PURGE BINARY
LOGS
in 2 key ways:
RESET MASTER
removes
all binary log files that are listed
in the index file, leaving only a single, empty binary log
file with a numeric suffix of .000001
,
whereas the numbering is not reset by
PURGE BINARY LOGS
.
RESET MASTER
is
not intended to be used while any
replicas are running. The behavior of
RESET MASTER
when used
while replicas are running is undefined (and thus
unsupported), whereas PURGE BINARY
LOGS
may be safely used while replicas are
running.
RESET MASTER
can prove useful
when you first set up the source and the replica, so that you
can verify the setup as follows:
Start the source and replica, and start replication (see Section 16.1.2, “Setting Up Binary Log File Position Based Replication”).
Execute a few test queries on the source.
Check that the queries were replicated to the replica.
When replication is running correctly, issue
STOP SLAVE
followed by
RESET SLAVE
on the replica,
then verify that any unwanted data no longer exists on the
replica.
Issue RESET MASTER
on the
source to clean up the test queries.
After verifying the setup, resetting the source and replica and ensuring that no unwanted data or binary log files generated by testing remain on source or replica, you can start the replica and begin replicating.