Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
RESET MASTER
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.
In MySQL 5.6.5 and later, RESET MASTER also clears the values of the gtid_purged system
variable (known as gtid_lost in MySQL 5.6.8 and earlier) as well as the global value of the gtid_executed
(gtid_done, prior to
MySQL 5.6.9) system variable (but not its session value); that is, executing this statement sets each of these
values to an empty string ('').
This statement is intended to be used only when the master is started for the first time.
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
replication slaves are running. The behavior of RESET MASTER when used while slaves are running is undefined (and
thus unsupported), whereas PURGE
BINARY LOGS may be safely used while replication slaves are running.
RESET
MASTER can prove useful when you first set up the master and the slave, so that you can verify the
setup as follows:
Start the master and slave, and start replication (see Section 16.1.1, "How to Set Up Replication").
Execute a few test queries on the master.
Check that the queries were replicated to the slave.
When replication is running correctly, issue STOP SLAVE followed by RESET SLAVE on the slave, then verify that any unwanted data no longer
exists on the slave.
Issue RESET
MASTER on the master to clean up the test queries.
After verifying the setup and getting rid of any unwanted and log files generated by testing, you can start the slave and begin replicating.