Documentation Home
MySQL 5.6 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 31.2Mb
PDF (A4) - 31.2Mb
PDF (RPM) - 30.4Mb
EPUB - 7.7Mb
HTML Download (TGZ) - 7.5Mb
HTML Download (Zip) - 7.6Mb
HTML Download (RPM) - 6.5Mb
Eclipse Doc Plugin (TGZ) - 8.3Mb
Eclipse Doc Plugin (Zip) - 10.1Mb
Man Pages (TGZ) - 183.8Kb
Man Pages (Zip) - 295.2Kb
Info (Gzip) - 2.9Mb
Info (Zip) - 2.9Mb
Excerpts from this Manual

MySQL 5.6 Reference Manual  /  ...  /  Replication Relay and Status Logs

17.2.2 Replication Relay and Status Logs

During replication, a slave server creates several logs that hold the binary log events relayed from the master to the slave, and to record information about the current status and location within the relay log. There are three types of logs used in the process, listed here:

  • The relay log consists of the events read from the binary log of the master and written by the slave I/O thread. Events in the relay log are executed on the slave as part of the SQL thread.

  • The master info log contains status and current configuration information for the slave's connection to the master. This log holds information on the master host name, login credentials, and coordinates indicating how far the slave has read from the master's binary log.

    Prior to MySQL 5.6, this log was always a file (master.info), but in MySQL 5.6 and later, this log can be written to the mysql.slave_master_info table instead of a file, by starting the slave with --master-info-repository=TABLE.

  • The relay log info log holds status information about the execution point within the slave's relay log.

    Prior to MySQL 5.6, this log was always a file (relay-log.info), but in MySQL 5.6 and later, this log can be written to the mysql.slave_relay_log_info table instead of a file by starting the slave with --relay-log-info-repository=TABLE.

Prior to MySQL 5.6.7, the Master_id column of the slave_master_info and slave_relay_log_info tables showed the slave's server ID instead of the master's server ID. (Bug #12334346)

In MySQL 5.6, setting relay_log_info_repository and master_info_repository to TABLE can improve resilience to unexpected halts (crash-safe replication). See Section 17.3.2, “Handling an Unexpected Halt of a Replication Slave”. In order for replication to be resilient to an unexpected halt when using tables for logging status and relay information, these tables must use a transactional storage engine, such as InnoDB. Beginning with MySQL 5.6.6, these tables are created using InnoDB. (Bug #13538891)

Prior to MySQL 5.6.6, if mysqld was unable to initialize the replication logging tables, the slave refused to start. In MySQL 5.6.6 and later, a warning is given when this occurs, but the slave is allowed to continue starting. (Bug #13971348) This situation is most likely to occur when upgrading from a version of MySQL that does not support slave logging tables to one in which they are supported.

In MySQL 5.6.5 and earlier, the slave_master_info and slave_relay_log_info tables used MyISAM by default, which meant that it was necessary before starting replication to change the storage engine used by these tables by issuing ALTER TABLE ... ENGINE=InnoDB, as shown here:

ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;

The ALTER TABLE statements must be executed by the MySQL root or other user account with the appropriate privileges on the mysql database. You should not attempt to do this while replication is running; beginning with MySQL 5.6.3, trying to execute an ALTER TABLE on either these tables while replication is ongoing is disallowed. Starting with MySQL 5.6.4, execution of any statement requiring a write lock on either or both of these tables is disallowed while replication is ongoing, while statements that perform only reads are permitted at any time.

Important

Do not attempt to update or insert rows in the slave_master_info or slave_relay_log_info table manually. Doing so can cause undefined behavior, and is not supported.

Prior to MySQL 5.6.4, mysqldump did not dump the replication log tables unless they were specified by name and the --master-data option was used.


User Comments
Sign Up Login You must be logged in to post a comment.