A slave replication server creates two small status files. By
default, these files are named
relay-log.info and created in the data
directory. Their names and locations can be changed by using the
See Section 14.8, “Replication and Binary Logging Options and Variables”.
The two status files contain information like that shown in the
output of the
SHOW SLAVE STATUS
statement, which is discussed in
Section 12.5.2, “SQL Statements for Controlling Slave Servers”. Because the status
files are stored on disk, they survive a slave server's
shutdown. The next time the slave starts up, it reads the two
files to determine how far it has proceeded in reading binary
logs from the master and in processing its own relay logs.
master.info file should be protected
because it contains the password for connecting to the master.
See Section 188.8.131.52, “Administrator Guidelines for Password Security”.
The slave I/O thread updates the
master.info file. As of MySQL 4.1, the file
includes a line count and information about SSL options. The
following table shows the correspondence between the lines in
the file and the columns displayed by
|1||Number of lines in the file|
|6||Password (not shown by |
Before MySQL 4.1, the file does not include a line count or information about SSL options.
|5||Password (not shown by |
The slave SQL thread updates the
relay-log.info file. The following table
shows the correspondence between the lines in the file and the
columns displayed by
The contents of the
relay-log.info file and
the states shown by the
STATUS statement might not match if the
relay-log.info file has not been flushed to
disk. Ideally, you should only view
relay-log.info on a slave that is offline
mysqld is not running). For a
SHOW SLAVE STATUS
should be used.
When you back up the slave's data, you should back up these two
status files as well, along with the relay log files. They are
needed to resume replication after you restore the slave's data.
If you lose the relay logs but still have the
relay-log.info file, you can check it to
determine how far the SQL thread has executed in the master
binary logs. Then you can use
TO with the
MASTER_LOG_POS options to tell the slave to
re-read the binary logs from that point. This requires that the
binary logs still exist on the master server.