MySQL 8.4 Release Notes
19.2.3.2 监控复制应用程序工作线程
在多线程副本中，性能 Schema 表replication_applier_status_by_coordinator和replication_applier_status_by_worker显示副本的协调线程和应用程序工作线程的状态信息。对于具有多个通道的副本，每个通道的线程都可以被识别。
多线程副本的协调线程也会在设置了显示信息性消息的 verbosity 设置的情况下，定期将统计信息写入副本的错误日志。统计信息的打印是根据协调线程分配给应用程序工作线程的事件数量而定的，最大频率为每 120 秒。消息列出了与相关的复制通道或默认复制通道（未命名）的以下统计信息：
- Seconds elapsed
-
自上次打印错误日志以来的时间差（以秒为单位）。
- Events assigned
-
自协调线程启动以来，协调线程将事件队列到所有应用程序工作线程的总数。
- Worker queues filled over overrun level
-
当前队列中超过溢出水平（90% 的最大队列长度 16384 事件）的事件数量。如果该值为零，则没有应用程序工作线程达到其容量。
- Waited due to worker queue full
-
协调线程由于应用程序工作线程队列满而等待的次数。如果该值为零，则没有应用程序工作线程达到其容量。
- Waited due to the total size
-
协调线程由于
replica_pending_jobs_size_max限制而等待的次数。这系统变量设置了应用程序工作线程队列中的事件队列大小（以字节为单位）。如果 unusually 大的事件超过该大小，事务将被保持直到所有应用程序工作线程队列为空，然后处理。所有后续事务都将被保持直到大事务完成。 - Waited at clock conflicts
-
协调线程由于依赖于未提交的事务而等待的时间（以纳秒为单位）。如果
replica_parallel_type设置为DATABASE（而不是LOGICAL_CLOCK），则该值始终为零。 - Waited (count) when workers occupied
-
协调线程睡眠的次数，这可能发生在两个情况下。第一个情况是协调线程分配事件时，发现应用线程队列已满，超过了10%的最大队列长度的下溢值，在这种情况下，它睡眠最长1毫秒。第二个情况是
replica_parallel_type设置为LOGICAL_CLOCK，协调线程需要将事务的第一个事件分配给应用线程队列，如果没有空队列，协调线程睡眠直到队列之一变空。 - Waited when workers occupied
-
协调线程等待空应用线程队列（即上述第二个情况，
replica_parallel_type设置为LOGICAL_CLOCK，需要将事务的第一个事件分配给应用线程队列）所 slept的纳秒数。