前言：周末春游的时候收到短信报警，从库延迟很高。手机VPN连进数据库以后排查情况，看到cpu使用率、磁盘IO、以及其他资源占用也不高。
一、登录数据库查看状态
MariaDB [trswcmtest]> show processlist;
+---------+-------------------+---------------------+------------+---------+------+-----------------------------------------------+------------------------------------------------------------------------------------------------------+----------+
| Id | User | Host | db | Command | Time | State | Info | Progress |
+---------+-------------------+---------------------+------------+---------+------+-----------------------------------------------+------------------------------------------------------------------------------------------------------+----------+
| 3769833 | system user | | NULL | Connect | 4484 | Waiting for master to send event | NULL | 0.000 |
| 3769885 | trs | 10.200.74.146:63067 | trswcmtest | Sleep | 4404 | | NULL | 0.000 |
| 3770353 | root | localhost | trswcmtest | Query | 0 | init | show processlist | 0.000 |
| 3770655 | system user | | trswcmtest | Connect | 0 | updating | update xxx set xxx=6925613 where xxx= 6925613 | 0.000 |
| 3770656 | system user | | trswcmtest | Connect | 0 | updating | update xxxx set xxx=0,xxx=0,xxx=0,xxx='' where Me | 0.000 |
| 3770657 | trs | % | trswcmtest | Connect | 0 | Sending data | UPDATE xxxx SET xxx='<br>uwbdhlnqvybejm (d:\\temp\\收到附件， | 0.000 |
| 3770658 | system user | | trswcmtest | Connect | 0 | updating | update xxxx set xxx=1032, xxx='system', xxx='2018-03-31 12:08:38' where xxx| 0.000 |
| 3770659 | system user | | NULL | Connect | 0 | Waiting for prior transaction to commit | NULL | 0.000 |
| 3770660 | system user | | trswcmtest | Connect | 0 | updating | UPDATE xxxx SET xxx=1032,xxx='2018-03-31 12:08:38' where xxx=7150769 | 0.000 |
| 3770661 | system user | | NULL | Connect | 0 | Waiting for prior transaction to commit | NULL | 0.000 |
| 3770662 | system user | | NULL | Connect | 0 | Waiting for prior transaction to commit | NULL | 0.000 |
| 3770663 | system user | | NULL | Connect | 1583 | Waiting for room in worker thread event queue |
二、原因分析
从上面看到，进程3770663一直处于Waiting for room in worker thread event queue的状态,因为该从库开启了并行复制，查阅MariaDB官方文档了解到执行 Replication 时，会有两个 Thread，一个是 SQL_THREAD，另一个是 IO_THREAD，顾名思义，SQL_THREAD 就是处理SQL 作业的 Thread，IO_THREAD 就是管理Binlog 从 Master 拿来然后回放在自己的 Relay Log 的 Thread。
在没有启用并行复制时，sql线程就自己分配给自己，也因为没法先看一下Binlog后面的事务，也许后面可以先做的，但是还是得一个一个回放。
当有并行复制时，sql线程除了自己变成分配工作的线程以外，会产生出
slave_parallel_threads数量的线程来处理事务，在分配工作时就知道哪些事务没有顺序关系，哪些有一定的顺序，这样回放就会快得多。
但是怎么会出现Waiting for room in worker thread event queue.呢？
从官方文档 slave-parallel-max-queued
文章看一半就不会注意到这个参数，如果你的事务在每个slave-parallel-max-queued大小的Transation Logs都能被解析，这样就有助于平行处理，但是如果无法解析，那就执行等到预读先做完，有空间了再读后面的Log并且继续执行，这样可能平行处理的顺序会被打乱。
所以适当地设定 slave-parallel-max-queued是必须的，但是它跟 slave_parallel_threads的使用是有关系的
slave_parallel_threads * slave_parallel_max_queued 为占用的总内存，如果太大会造成OOM，我这里设置的128M，后续再进行观察。
