The relay log, like the binary log, consists of a set of numbered files containing events that describe database changes, and an index file that contains the names of all used relay log files. The default location for relay log files is the data directory.

The term“relay log file”generally denotes an individual numbered file containing database events. The term“relay log”collectively denotes the set of numbered relay log files plus the index file.

Relay log files have the same format as binary log files and can be read usingmysqlbinlog(seemysqlbinlog — Utility for Processing Binary Log Files). If binary log transaction compression (available as of MySQL 8.0.20) is in use, transaction payloads written to the relay log are compressed in the same way as for the binary log. For more information on binary log transaction compression, seeBinary Log Transaction Compression.

For the default replication channel, relay log file names have the default formhost_name-relay-bin.nnnnnn, wherehost_nameis the name of the replica server host andnnnnnnis a sequence number. Successive relay log files are created using successive sequence numbers, beginning with000001. For non-default replication channels, the default base name ishost_name-relay-bin-channel, wherechannelis the name of the replication channel recorded in the relay log.

The replica uses an index file to track the relay log files currently in use. The default relay log index file name ishost_name-relay-bin.indexfor the default channel, andhost_name-relay-bin-channel.indexfor non-default replication channels.

The default relay log file and relay log index file names and locations can be overridden with, respectively, therelay_logandrelay_log_indexsystem variables (seeSection 2.6, “Replication and Binary Logging Options and Variables”).

If a replica uses the default host-based relay log file names, changing a replica's host name after replication has been set up can cause replication to fail with the errorsFailed to open the relay logandCould not find target log during relay log initialization. This is a known issue (see Bug #2122). If you anticipate that a replica's host name might change in the future (for example, if networking is set up on the replica such that its host name can be modified using DHCP), you can avoid this issue entirely by using therelay_logandrelay_log_indexsystem variables to specify relay log file names explicitly when you initially set up the replica. This causes the names to be independent of server host name changes.

If you encounter the issue after replication has already begun, one way to work around it is to stop the replica server, prepend the contents of the old relay log index file to the new one, and then restart the replica. On a Unix system, this can be done as shown here:

$> catnew_relay_log_name.index >>old_relay_log_name.index $> mvold_relay_log_name.indexnew_relay_log_name.index

A replica server creates a new relay log file under the following conditions:

The replication SQL (applier) thread automatically deletes each relay log file after it has executed all events in the file and no longer needs it. There is no explicit mechanism for deleting relay logs because the replication SQL thread takes care of doing so. However,FLUSH LOGSrotates relay logs, which influences when the replication SQL thread deletes them.