Relay Log and Replication Metadata Repositories halt. For information on the combination of settings on a replica that is most resilient to unexpected halts, see Section 17.4.2, “Handling an Unexpected Halt of a Replica” . When you back up the replica’s data or transfer a snapshot of its data to create a new replica, ensure that you include the  mysql.slave_master_info  and  mysql.slave_relay_log_info  tables containing the replication metadata repositories. For cloning operations, note that when the replication metadata repositories are created as tables, they are copied to the recipient during a cloning operation, but when they are created as files, they are not copied. When binary log file position based replication is in use, the replication metadata repositories are needed to resume replication after restarting the restored, copied, or cloned replica. If you do not have the relay log files, but still have the applier metadata repository, you can check it to determine how far the replication SQL thread has executed in the source’s binary log. Then you can use a  CHANGE REPLICATION SOURCE TO  statement (from MySQL 8.0.23) or  CHANGE MASTER TO  statement (before MySQL 8.0.23) with the  SOURCE_LOG_FILE  |  MASTER_LOG_FILE  and SOURCE_LOG_POS  |  MASTER_LOG_POS  options to tell the replica to re-read the binary logs from the source from that point (provided that the required binary logs still exist on the source). One additional repository, the applier worker metadata repository, is created primarily for internal use, and holds status information about worker threads on a multithreaded replica. The applier worker metadata repository includes the names and positions for the relay log file and the source’s binary log file for each worker thread. If the applier metadata repository is created as a table, which is the default, the applier worker metadata repository is written to the  mysql.slave_worker_info  table. If the applier metadata repository is written to a file, the applier worker metadata repository is written to the  worker-relay- log.info  file. For external use, status information for worker threads is presented in the Performance Schema  replication_applier_status_by_worker  table. The replication metadata repositories originally contained information similar to that shown in the output of the  SHOW REPLICA | SLAVE STATUS  statement, which is discussed in Section 13.4.2, “SQL Statements for Controlling Replica Servers” . Further information has since been added to the replication metadata repositories which is not displayed by the  SHOW REPLICA | SLAVE STATUS  statement. For the connection metadata repository, the following table shows the correspondence between the columns in the  mysql.slave_master_info  table, the columns displayed by  SHOW REPLICA | SLAVE STATUS , and the lines in the deprecated  master.info  file. 3602 slave_master_info Table Column SHOW REPLICA | SLAVE STATUS  Column master.info  File Line Description Number_of_lines [None] 1 Number of columns in the table (or lines in the file) Master_log_name Source_Log_File 2 The name of the binary log currently being read from the source Master_log_pos Read_Source_Log_Pos 3 The current position within the binary log that has been read from the source Host Source_Host 4 The host name of the replication source server User_name Source_User 5 The replication user account name used to connect to the source User_password Password (not shown by  SHOW REPLICA | SLAVE STATUS ) 6 The replication user account password used to connect to the source