Documentation Home
MySQL 5.5 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 26.9Mb
PDF (A4) - 27.0Mb
PDF (RPM) - 25.4Mb
HTML Download (TGZ) - 6.3Mb
HTML Download (Zip) - 6.4Mb
HTML Download (RPM) - 5.4Mb
Man Pages (TGZ) - 159.9Kb
Man Pages (Zip) - 262.9Kb
Info (Gzip) - 2.6Mb
Info (Zip) - 2.6Mb
Excerpts from this Manual Slave Status Logs

A replication slave server creates two logs. By default, these logs are files named and and created in the data directory. The names and locations of these files can be changed by using the --master-info-file option and relay_log_info_file system variable, respectively. See Section 17.1.3, “Replication and Binary Logging Options and Variables”.

The two status logs contain information similar to 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.

Access to the master info log should be restricted because it contains the password for connecting to the master. See Section, “Passwords and Logging”.

The slave I/O thread updates the master info log. The following table shows the correspondence between the lines in the file and the columns displayed by SHOW SLAVE STATUS. File Line SHOW SLAVE 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 list of possible ciphers used in the handshake 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 log. The following table shows the correspondence between the lines in the file and the columns displayed by SHOW SLAVE STATUS.

Line in 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 file and the states shown by the SHOW SLAVE STATUS statement might not match if the file has not been flushed to disk. Ideally, you should only view 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.