The two status logs contain information like that shown in the
output of the SHOW SLAVE STATUS
statement, which is discussed in
Section 13.4.2, “SQL Statements for Controlling Slave Servers”. Because the status logs
are stored on disk, they survive a slave server's shutdown.
The next time the slave starts up, it reads the two logs to
determine how far it has proceeded in reading binary logs from
the master and in processing its own relay logs.

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 list of possible ciphers used in the handshake for the SSL
connection

14

Master_SSL_Key

The name of the SSL key file

The slave SQL thread updates the relay log info log. The
following table shows the correspondence between the lines in
the relay-log.info file and the columns
displayed by SHOW SLAVE STATUS.

Line in relay-log.info

SHOW SLAVE 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 logs, along with the relay log files. The status logs
are needed to resume replication after you restore the data from
the slave. If you lose the relay logs but still have the relay
log info log, 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.