前言：周末春游的時候收到短信報警鸥昏，從庫延遲很高。手機(jī)VPN連進(jìn)數(shù)據(jù)庫以后排查情況姐帚，看到cpu使用率吏垮、磁盤IO、以及其他資源占用也不高罐旗。
一膳汪、登錄數(shù)據(jù)庫查看狀態(tài)
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 |
二九秀、原因分析
從上面看到遗嗽，進(jìn)程3770663一直處于Waiting for room in worker thread event queue的狀態(tài),因為該從庫開啟了并行復(fù)制，查閱MariaDB官方文檔了解到執(zhí)行 Replication 時鼓蜒，會有兩個 Thread痹换，一個是 SQL_THREAD，另一個是 IO_THREAD友酱，顧名思義晴音，SQL_THREAD 就是處理SQL 作業(yè)的 Thread，IO_THREAD 就是管理Binlog 從 Master 拿來然后回放在自己的 Relay Log 的 Thread缔杉。
在沒有啟用并行復(fù)制時锤躁，sql線程就自己分配給自己，也因為沒法先看一下Binlog后面的事務(wù)或详，也許后面可以先做的系羞，但是還是得一個一個回放。
當(dāng)有并行復(fù)制時霸琴，sql線程除了自己變成分配工作的線程以外椒振，會產(chǎn)生出
slave_parallel_threads數(shù)量的線程來處理事務(wù)，在分配工作時就知道哪些事務(wù)沒有順序關(guān)系梧乘，哪些有一定的順序澎迎，這樣回放就會快得多庐杨。
但是怎么會出現(xiàn)Waiting for room in worker thread event queue.呢？
從官方文檔 slave-parallel-max-queued
文章看一半就不會注意到這個參數(shù)夹供，如果你的事務(wù)在每個slave-parallel-max-queued大小的Transation Logs都能被解析灵份，這樣就有助于平行處理，但是如果無法解析哮洽，那就執(zhí)行等到預(yù)讀先做完填渠，有空間了再讀后面的Log并且繼續(xù)執(zhí)行，這樣可能平行處理的順序會被打亂鸟辅。
所以適當(dāng)?shù)卦O(shè)定 slave-parallel-max-queued是必須的氛什，但是它跟 slave_parallel_threads的使用是有關(guān)系的
slave_parallel_threads * slave_parallel_max_queued 為占用的總內(nèi)存，如果太大會造成OOM匪凉，我這里設(shè)置的128M枪眉，后續(xù)再進(jìn)行觀察。
