Relay Log and Replication Metadata Repositories maximum queue length, in which case it sleeps for a maximum of 1 millisecond. The second situation is where  slave_parallel_type  is set to  LOGICAL_CLOCK  and the coordinator thread needs to assign the first event of a transaction to an applier worker thread’s queue, it only does this to a worker with an empty queue, so if no queues are empty, the coordinator thread sleeps until one becomes empty. The number of nanoseconds that the coordinator thread slept while waiting for an empty applier worker thread queue (that is, in the second situation described above, where  slave_parallel_type  is set to  LOGICAL_CLOCK  and the first event of a transaction needs to be assigned). Waited when workers occupied A replica server creates several repositories of information to use for the replication process: The replica’s connection metadata repository and applier metadata repository are collectively known as the replication metadata repositories. For information about these, see Section 17.2.4.2, “Replication Metadata Repositories” . Making replication resilient to unexpected halts.   The  mysql.slave_master_info  and mysql.slave_relay_log_info  tables are created using the transactional storage engine  InnoDB . Updates to the replica’s applier metadata repository table are committed together with the transactions, meaning that the replica’s progress information recorded in that repository is always consistent with what has been applied to the database, even in the event of an unexpected server halt. For information on the combination of settings on the replica that is most resilient to unexpected halts, see Section 17.4.2, “Handling an Unexpected Halt of a Replica” . 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 using  mysqlbinlog  (see Section 4.6.9, “mysqlbinlog — 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, see Section 5.4.4.5, “Binary Log Transaction Compression” . 17.2.4.1 The Relay Log 3599 17.2.4 Relay Log and Replication Metadata Repositories •The replica’s  relay log , which is written by the replication I/O thread, contains the transactions read from the replication source server’s binary log. The transactions in the relay log are applied on the replica by the replication SQL thread. For information about the relay log, see Section 17.2.4.1, “The Relay Log” . •The replica’s  connection metadata repository  contains information that the replication I/O thread needs to connect to the replication source server and retrieve transactions from the source’s binary log. The connection metadata repository is written to the  mysql.slave_master_info  table. •The replica’s  applier metadata repository  contains information that the replication SQL thread needs to read and apply transactions from the replica’s relay log. The applier metadata repository is written to the mysql.slave_relay_log_info  table.