DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 

(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