作者：手辨
實為吾之愚見,望諸君酌之!聞過則喜，與君共勉
第一節并行複制
Mysql5.6的mts(并行複制)是基于database來分發事務的，coordinator(原來的sql
thread)按照slave worker與db的對應關系進行處理來分發事務給相應的slave worker，slave worker代替了sql thread來執行事務中的event。并且mysql預設認為資料是以database來分布的，跨庫的事務在slave應用的時候可能就需要等待了。
Waiting for Slave Worker to release
partition第一次看到是在開啟MTS的mysql5.6主從複制的時候，在Slave_SQL_Running_State:出現Waiting for Slave
Worker to release partition，Slave_SQL_Running_State的狀态比較多，但是這個狀态翻譯過來是指“等待slave worker 釋放
分區(partitions)”,其中的partitions解釋成中文不是很正确，partitions可以了解成”按照slave worker與db的對應關系進行分發事務後的對象”（有更好的解釋請留言），它既不是事務也不是event，也不是單純的對應關系，起碼可以确定這種情況并不是異常的情況（大部分時候），slave worker正在應用coordinator配置設定的内容但是還沒結束，coordinator需要等待之前配置設定的内容應用完成才可以繼續配置設定(coordinator還沒有将其放入slave worker的queue)，下面嘗試測試和複現Waiting for Slave Worker to release partition。
當不開啟并行複制時(
slave_parallel_workers
為0),show processlist是這樣的：
當開啟并行複制時(slave_parallel_workers為2)，show
processlist是這樣的：
差別是增加了兩個slave worker程序，原來的sql thread變成了
coordinator。
第二節測試和複現
2.1 建立測試資料
1，建立兩個測試的database：slavetest,slavetest1
2，在這兩個db中分布建立一張表test，向裡面寫入200w左右的測試資料
通過測試一些場景，通過其結果來反應一些問題，以下測試多是基于自建mysql進行
2.2 測試1
确認slave worker與db的在串行執行時對應關系，先打開一個session，分别執行
update slavetest.test set
trade='slavetest';
update slavetest1.test set
trade='slavetest1';
檢視slave的slave worker狀态，找到slavetest對應的slave worker
通過上面測試slavetest對應的slave worker的程序id為5812476
使用同樣的方法，得出如下對應:
slavetest 5812476
slavetest1 5812475
這樣單線程執行的時候，兩個db在執行update更新時，coordinator都配置設定給了5812476的slave worker
2.3 測試2
确認slave worker與db的在并行執行時對應關系，同僚打開2個session，每個session分别執行更新，中間間隔10s
update slavetest.test set trade='slavetest11';
trade='slavetest22';
檢視slave的slave worker狀态，找到slavetest對應的slave worker（可以寫一個腳本來循環執行show processlist監控）
通過執行資訊看，slavetest1的事務先完成，slavetest2的事務後完成，看下slave的程序資訊:
過濾後如下：
通過上面測試并不能在slave上執行完這兩個事務的時候，保證一個slave worker完全對應其中的一個dbname(個人以為上一個事務裡面，slave worker與db的對應是不會變的)，暫且得出的結論是當并行執行兩個db的事務的時候，其中的兩個slave worker都産生了影響。
這樣多線程執行的時候，兩個db在執行update更新時，coordinator會把事務配置設定給兩個slave worker同時并行執行，并且也出現了Waiting for Slave Worker to release partition，并且還出現了Waiting
for Slave Worker queue，按照之前的描述，mysql假設資料是按照database來分布的，是以不會存在跨庫的情況，下面進行事務跨庫的測試
2.4 測試3
确認slave worker與db的在一個事務裡跨庫執行時對應關系，隻打開1個session，執行:
begin;
trade='slavetest2';
commit;
模拟一個事務内跨庫執行更新，檢視slave的程序資訊：
通過過濾的結果看，執行event的程序隻有一個5812476，coordinator并沒有配置設定給5812475的slave worker來執行，且也出現了Waiting for Slave Worker to release partition
通過測試和複現問題，Waiting for Slave Worker to release partition一般來說是一個正常的中間狀态，但是也有可能出現問題，有一些特殊情況可以參考：
https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fbugs.mysql.com%2Fbug.php%3Fid%3D73066 https://bugs.mysql.com/bug.php?id=73066 https://yq.aliyun.com/go/articleRenderRedirect?url=https%3A%2F%2Fbugs.mysql.com%2Fbug.php%3Fid%3D72794 https://bugs.mysql.com/bug.php?id=72794另外包括Waiting for Slave Worker queue,System lock等狀态大部分也是正常的中間狀态