(mysql.info.gz) Slave logs
Info Catalog
(mysql.info.gz) Slave SQL thread states
(mysql.info.gz) Replication Implementation Details
6.3.4 Replication Relay and Status Files
----------------------------------------
By default, relay logs are named using filenames of the form
`HOST_NAME-relay-bin.NNNNNN', where HOST_NAME is the name of the slave
server host and NNNNNN is a sequence number. Successive relay log
files are created using successive sequence numbers, beginning with
`000001' (`001' in MySQL 4.0 or older). The slave keeps track of relay
logs currently in use in an index file. The default relay log index
filename is `HOST_NAME-relay-bin.index'. By default, these files are
created in the slave's data directory. The default filenames may be
overridden with the `--relay-log' and `--relay-log-index' server
options. Replication Options.
Relay logs have the same format as binary logs, so you can use
`mysqlbinlog' to read them. A relay log is automatically deleted by
the SQL thread as soon as it has executed all its events and no longer
needs it). There is no explicit mechanism for deleting relay logs,
because the SQL thread takes care of doing so. However, from MySQL
4.0.14, `FLUSH LOGS' rotates relay logs, which will influence when the
SQL thread deletes them.
A new relay log is created under the following conditions:
* When the I/O thread starts for the first time after the slave
server starts. (In MySQL 5.0, a new relay log is created each
time the I/O thread starts, not just the first time.)
* When the logs are flushed; for example, with `FLUSH LOGS' or
`mysqladmin flush-logs'. (This creates a new relay log only as of
MySQL 4.0.14.)
* When the size of the current relay log file becomes too large. The
meaning of "too large" is determined as follows:
- `max_relay_log_size', if `max_relay_log_size' > 0
- `max_binlog_size', if `max_relay_log_size' = 0 or MySQL is
older than 4.0.14
A slave replication server creates two additional small files in the
data directory. These are status files and are named `master.info' and
`relay-log.info' by default. They contain information like that shown
in the output of the `SHOW SLAVE STATUS' statement ( Replication
Slave SQL for a description of this statement). As disk files, they
survive a slave server's shutdown. The next time the slave starts up,
it reads these 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 is updated by the I/O thread. Before MySQL 4.1,
the correspondence between the lines in the file and the columns
displayed by `SHOW SLAVE STATUS' is as follows:
*Line* *Description*
1 `Master_Log_File'
2 `Read_Master_Log_Pos'
3 `Master_Host'
4 `Master_User'
5 Password (not shown by `SHOW SLAVE STATUS')
6 `Master_Port'
7 `Connect_Retry'
As of MySQL 4.1, the file includes a line count and information about
SSL options:
*Line* *Description*
1 Number of lines in the file
2 `Master_Log_File'
3 `Read_Master_Log_Pos'
4 `Master_Host'
5 `Master_User'
6 Password (not shown by `SHOW SLAVE STATUS')
7 `Master_Port'
8 `Connect_Retry'
9 `Master_SSL_Allowed'
10 `Master_SSL_CA_File'
11 `Master_SSL_CA_Path'
12 `Master_SSL_Cert'
13 `Master_SSL_Cipher'
14 `Master_SSL_Key'
The `relay-log.info' file is updated by the SQL thread. The
correspondence between the lines in the file and the columns displayed
by `SHOW SLAVE STATUS' is as follows:
*Line* *Description*
1 `Relay_Log_File'
2 `Relay_Log_Pos'
3 `Relay_Master_Log_File'
4 `Exec_Master_Log_Pos'
When you back up your slave's data, you should back up these two small
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. This requires that the binary logs still exist on the
master server.
If your slave is subject to replicating `LOAD DATA INFILE' statements,
you should also back up any `SQL_LOAD-*' files that exist in the
directory that the slave uses for this purpose. The slave needs these
files to resume replication of any interrupted `LOAD DATA INFILE'
operations. The directory location is specified using the
`--slave-load-tmpdir' option. Its default value, if not specified, is
the value of the `tmpdir' variable.
Info Catalog
(mysql.info.gz) Slave SQL thread states
(mysql.info.gz) Replication Implementation Details
automatically generated byinfo2html