## 并行復制相關線程 在MySQL 5.6并行復制中，當設置`set global slave_parallel_workers=2`時，共有4個復制相關的線程，如下： ~~~ +----+-------------+------+-------+---------+------+------------------------------------------------------------------+------+ | ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO | +----+-------------+------+-------+---------+------+------------------------------------------------------------------+------+ | 23 | system user | | NULL | Connect | 3 | Waiting for master to send event | NULL | | 24 | system user | | mysql | Connect | 3 | Slave has read all relay log; waiting for the slave I/O thread t | NULL | | 25 | system user | | NULL | Connect | 3 | Waiting for an event from Coordinator | NULL | | 26 | system user | | NULL | Connect | 3 | Waiting for an event from Coordinator | NULL | +----+-------------+------+-------+---------+------+------------------------------------------------------------------+------+ ~~~ 其中第一個為IO線程，負責從主庫拉取binlog到備庫并存為relay log; 第二個為分發線程，負責解析relay log，并將解析后的事件分發給worker線程處理； 其余兩個為worker線程負責處理分發后的事件，類型非并行復制時的sql線程。 ## 并行復制并發策略 目前RDS MySQL并行復制是以表級別進行分發的，即同一時刻，同一個表相關的操作只能在同一個worker線程中進行。 考慮兩個事務，分別對表進行insert ~~~ trx1: begin; insert into t1 values(1); comit; trx2: begin; insert into t2 values(1); comit; ~~~ 那么這兩個事務可能分別在兩個worker中并行執行。 有些特殊情會影響worker的并發執行: * 并行退化為串行的情況 * DDL語句串行處理(RDS MySQL正在優化DDL并行處理) * binlog切換事件需串行處理 * 有外鍵關系的表需串行處理 * 并行等待的情況 當一個事務中包含多個表時，如下: ~~~ trx3: begin; insert into t1 values(3); insert into t2 values(3); comit; ~~~ 如果當前worker1正在執行t1相關的事務，worker2正在執行t2相關的事務，那么分發線程在分發trx3的t2的事件時必須等待worker2的t2相關的事務執行完成。 ## 并行復制worker分配 假設，worker線程正在執行的情況如下: ~~~ worker 1: trx1: insert t1 worker 2: trx2: insert t2; trx3: insert t3; ~~~ 然后分發線程再來一個事務trx4: ~~~ trx4: insert t4; ~~~ 分發線程該分配給哪個worker呢？ 分配線程分配會分配給最空閑的worker(`get_least_occupied_worker`); 這里最空閑是指worker當前正在執行的事務涉及的表數越少越空閑。 worker1正在執行的事務涉及的表數為1，而worker2正在執行的事務涉及的表數為2，因此trx4會分配為worker1; 表和worker存在一一對應關系，為了快速找到表對應的worker，哈希表（`mapping_db_to_worker`）存儲了這種映射關系。同時為了控制哈希表過大導致占用較多內存或哈希沖突，系統嚴格控制了哈希表的大小，不能超過16（硬編碼`mts_partition_hash_soft_max`），當超過16時，會將當前沒有執行的表從哈希表驅逐出去。 在表較多情況下，哈希表大小設為16顯得過小，可能會頻繁驅逐表，頻繁新建哈希鍵值對的情況。 ## 優化 1. 表級并行復制下，哈希表的大小16（硬編碼`mts_partition_hash_soft_max`）過小，應設為動態可調； 2. 分配線程分配會分配給最空閑的`worker(get_least_occupied_worker)`。 考慮如下情況： ~~~ worker 1: t1 1000個事務 worker 2: t2 10個事務 t3 10 個事務 ~~~ 當前worker1比worker2要繁忙，而按照當前正在執行的事務涉及的表數越少越空閑的原則，新來的事務(比如insert t4)會分配給worker1，這是不合理的。 因此，空閑的標準應改為當前正在執行的事務數越少越空閑，這樣新來的事務會分配給worker2。