The value in the Time  column can show how late the replica is compared to the source. See Section A.14, “MySQL 8.0 FAQ: Replication” . If sufficient time elapses on the source side without activity on the Binlog Dump  thread, the source determines that the replica is no longer connected. As for any other client connection, the timeouts for this depend on the values of net_write_timeout  and net_retry_count ; for more information about these, see Section 5.1.8, “Server System Variables” . 

The SHOW REPLICA | SLAVE STATUS  statement provides additional information about replication processing on a replica server. See Section 17.1.7.1, “Checking Replication Status” . 

## 17.2.3.2 Monitoring Replication Applier Worker Threads 

On a multithreaded replica, the Performance Schema tables replication_applier_status_by_coordinator  and replication_applier_status_by_worker  show status information for the replica’s coordinator thread and applier worker threads respectively. For a replica with multiple channels, the threads for each channel are identified. 

A multithreaded replica’s coordinator thread also prints statistics to the replica’s error log on a regular basis if the verbosity setting is set to display informational messages. The statistics are printed depending on the volume of events that the coordinator thread has assigned to applier worker threads, with a maximum frequency of once every 120 seconds. The message lists the following statistics for the relevant replication channel, or the default replication channel (which is not named): 

Seconds elapsed The difference in seconds between the current time and the last time this information was printed to the error log. 

Events assigned The total number of events that the coordinator thread has queued to all applier worker threads since the coordinator thread was started. 

Worker queues filled over overrun level The current number of events that are queued to any of the applier worker threads in excess of the overrun level, which is set at 90% of the maximum queue length of 16384 events. If this value is zero, no applier worker threads are operating at the upper limit of their capacity. 

Waited due to worker queue full The number of times that the coordinator thread had to wait to schedule an event because an applier worker thread’s queue was full. If this value is zero, no applier worker threads exhausted their capacity. 

Waited due to the total size The number of times that the coordinator thread had to wait to schedule an event because the slave_pending_jobs_size_max  limit had been reached. This system variable sets the maximum amount of memory (in bytes) available to applier worker thread queues holding events not yet applied. If an unusually large event exceeds this size, the transaction is held until all the applier worker threads have empty queues, and then processed. All subsequent transactions are held until the large transaction has been completed. 

Waited at clock conflicts The number of nanoseconds that the coordinator thread had to wait to schedule an event because a transaction that the event depended on had not yet been committed. If slave_parallel_type  is set to DATABASE  (rather than LOGICAL_CLOCK ), this value is always zero. 

Waited (count) when workers occupied The number of times that the coordinator thread slept for a short period, which it might do in two situations. The first situation is where the coordinator thread assigns an event and finds the applier worker thread’s queue is filled beyond the underrun level of 10% of the 

