Relay Log and Replication Metadata Repositories For the default replication channel, relay log file names have the default form  host_name -relay- bin. nnnnnn , where  host_name  is the name of the replica server host and  nnnnnn  is a sequence number. Successive relay log files are created using successive sequence numbers, beginning with  000001 . For non-default replication channels, the default base name is  host_name -relay- bin- channel , where  channel  is 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 is  host_name -relay-bin.index  for the default channel, and  host_name -relay- bin- channel .index  for non-default replication channels. The default relay log file and relay log index file names and locations can be overridden with, respectively, the  relay_log  and  relay_log_index  system variables (see Section 17.1.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 errors  Failed to open the relay log  and  Could 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 the  relay_log  and  relay_log_index  system 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: A replica server creates a new relay log file under the following conditions: The replication SQL 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 LOGS  rotates relay logs, which influences when the replication SQL thread deletes them. A replica server creates two replication metadata repositories, the connection metadata repository and the applier metadata repository. The replication metadata repositories survive a replica server’s shutdown. If binary log file position based replication is in use, when the replica restarts, it reads the two repositories to determine how far it previously proceeded in reading the binary log from the source and in processing its own relay log. If GTID-based replication is in use, the replica does not use the replication metadata repositories for that purpose, but does need them for the other metadata that they contain. 3600 17.2.4.2 Replication Metadata Repositories •Each time the replication I/O thread starts. •When the logs are flushed (for example, with  FLUSH LOGS  or  mysqladmin flush-logs ). •When the size of the current relay log file becomes too large, which is determined as follows: •If the value of  max_relay_log_size  is greater than 0, that is the maximum relay log file size. •If the value of  max_relay_log_size  is 0,  max_binlog_size  determines the maximum relay log file size. shell>  cat  new_relay_log_name .index >>  old_relay_log_name .index shell>  mv  old_relay_log_name .index  new_relay_log_name .index