content_image/827682.jpg
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 | +-------------------+-----------+-----------+ 

<img src='content_image/827682.jpg'>

## 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 REPLICA | SLAVE  followed by RESET REPLICA | 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. 

## 13.4.1.3 SET sql_log_bin Statement 

