Documentation Home
MySQL 8.0 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 48.3Mb
PDF (A4) - 48.3Mb
PDF (RPM) - 43.9Mb
HTML Download (TGZ) - 11.1Mb
HTML Download (Zip) - 11.1Mb
HTML Download (RPM) - 9.5Mb
Man Pages (TGZ) - 239.6Kb
Man Pages (Zip) - 343.4Kb
Info (Gzip) - 4.4Mb
Info (Zip) - 4.4Mb
Excerpts from this Manual

13.4.1.2 RESET MASTER Statement

RESET MASTER [TO binary_log_file_index_number]
Warning

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.

Issuing RESET MASTER without the optional TO clause deletes all binary log files listed in the index file, resets the binary log index file to be empty, and creates a new binary log file starting at 1. Use the optional TO clause to start the binary log file index from a number other than 1 after the reset.

Using RESET MASTER with the TO clause to specify a binary log file index number to start from simplifies failover by providing a single statement alternative to the FLUSH BINARY LOGS and PURGE BINARY LOGS TO statements. Check that you are using a reasonable value for the index number. If you enter an incorrect value, you can correct this by issuing another RESET MASTER statement with or without the TO clause. If you do not correct a value that is out of range, the server cannot be restarted.

The following example demonstrates TO clause usage:

RESET MASTER TO 1234;

SHOW BINARY LOGS;
+-------------------+-----------+-----------+
| Log_name          | File_size | Encrypted |
+-------------------+-----------+-----------+
| source-bin.001234 |       154 | No        |
+-------------------+-----------+-----------+
Important

The effects of RESET MASTER without the TO clause differ from those of PURGE BINARY LOGS in 2 key ways:

  1. 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.

  2. 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.

See also Section 13.4.1.1, “PURGE BINARY LOGS Statement”.

RESET MASTER without the TO clause can prove useful when you first set up a source and replica, so that you can verify the setup as follows:

  1. Start the source and replica, and start replication (see Section 17.1.2, “Setting Up Binary Log File Position Based Replication”).

  2. Execute a few test queries on the source.

  3. Check that the queries were replicated to the replica.

  4. When replication is running correctly, issue STOP SLAVE followed by RESET SLAVE on the replica, then verify that no unwanted data from the test queries exists on the replica.

  5. 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 the source or replica, you can start the replica and begin replicating.