A slave replication server creates two small status files. By
default, these files are named master.info
and relay-log.info
and created in the data
directory. Their names and locations can be changed by using the
--master-info-file
and
--relay-log-info-file
options.
See Section 17.1.3, “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.
The master.info
file should be protected
because it contains the password for connecting to the master.
See Section 5.3.2.1, “Administrator Guidelines for Password Security”.
The slave I/O thread updates the
master.info
file. The following table shows
the correspondence between the lines in the file and the columns
displayed by SHOW SLAVE STATUS
.
Line | Status Column | Description |
---|---|---|
1 | Number of lines in the file | |
2 | Master_Log_File | The name of the master binary log currently being read from the master |
3 | Read_Master_Log_Pos | The current position within the master binary log that have been read from the master |
4 | Master_Host | The host name of the master |
5 | Master_User | The user name used to connect to the master |
6 | Password (not shown by SHOW SLAVE STATUS ) | The password used to connect to the master |
7 | Master_Port | The network port used to connect to the master |
8 | Connect_Retry | The period (in seconds) that the slave will wait before trying to reconnect to the master |
9 | Master_SSL_Allowed | Indicates whether the server supports SSL connections |
10 | Master_SSL_CA_File | The file used for the Certificate Authority (CA) certificate |
11 | Master_SSL_CA_Path | The path to the Certificate Authority (CA) certificates |
12 | Master_SSL_Cert | The name of the SSL certificate file |
13 | Master_SSL_Cipher | The name of the cipher in use for the SSL connection |
14 | Master_SSL_Key | The name of the SSL key file |
15 | Master_SSL_Verify_Server_Cert | Whether to verify the server certificate |
17 | Replicate_Ignore_Server_Ids | The number of server IDs to be ignored, followed by the actual server IDs |
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 SHOW SLAVE
STATUS
.
Line | Status Column | Description |
---|---|---|
1 | Relay_Log_File | The name of the current relay log file |
2 | Relay_Log_Pos | The current position within the relay log file; events up to this position have been executed on the slave database |
3 | Relay_Master_Log_File | The name of the master binary log file from which the events in the relay log file were read |
4 | Exec_Master_Log_Pos | The equivalent position within the master's binary log file of events that have already been executed |
The contents of the relay-log.info
file and
the states shown by the SHOW SLAVE
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
(that is, mysqld
is not running). For a
running system, 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 CHANGE MASTER
TO
with the MASTER_LOG_FILE
and
MASTER_LOG_POS
options to tell the slave to
re-read the binary logs from that point. Of course, this
requires that the binary logs still exist on the master server.