一 概念說明
1 模型 並行復制是典型的生產者、消費者模式，Coordinator作為生產者，worker線程作為消費者。
2 Waiting for preceding transaction to commit 當前事務無法和正在回放的事務並發回放出現的等待
二 延遲出現的err日志打印說明
可以根據日志統計進行分析
Multi-threaded slave statistics for channel ”:
seconds elapsed = 121;
eventsassigned = 100374529; 總共有多少個event被分配執行，計的是總數。
queues filled over overrun level = 0; 多線程同步中，worker 的私有隊列長度超長的次數，計的是總數。
waited due aWorker queue full = 0; 因為worker的隊列超長而產生等待的次數，計的是總數
waited due the total size = 0; 超過最大size的次數
waited at clock conflicts= 1451875661700
waited (count) when Workers occupied = 3211993 因為workder被占用而出現等待的次數。（總計值）。
waited when Workers occupied = 445032386000 因為workder被占用而出現等待的總時間，總計值，單位是納秒。
三 出現的幾種情況
1 主從同步發生錯誤,導致從庫延時
觀察 這里可以對sql_error和雙線程進行觀察,就能觀察出問題
解決方式 進行數據修復,保證主從數據的一致性
2 主從同步發生大事務,導致從庫延時
觀察
1 通過show processlist進行觀察
2 exec_master_position 一直不會變
3 SQL STATUS 出現 Waiting for preceding transaction to commit
分析 大表->DDL/大事務的執行是並行復制所無法解決的,會拖累甚至卡住整個復制進度
解決方式 大事務進行拆分,表進行拆分,避免或者減少這種情況的發生
3 SQL STATUS 出現 Waiting for Slave Workers to free pending events
分析 當事件的大小超過了slave_pending_jobs_size_max的大小，而當時間大小低於slave_pending_jobs_size_max的限制時調度器才會恢復調度。
解決方式 適當調大 slave_pending_jobs_size_max進行解決,可能是由於大字段引起的,請解析binlog確定下然后進行修改
3 主庫壓力很大,同時並發數高,導致從庫應用繁忙
觀察 1 觀察主庫binlog生成量和事務監控峰值
2 從庫執行語句
SELECT thread_id,count_star FROM performance_schema.events_transactions_summary_by_thread_by_event_name
WHERE thread_id IN (
SELECT thread_id FROM performance_schema.replication_applier_status_by_worker);
這條語句是用來統計worker線程應用事務的並發度數量的,可以進行推測
3 從庫的util值非常高
解決方式 分庫分表,改造業務,減少單台集群的壓力
四 總結
和我之前排查異步復制的思路差不多,只是在並行復制的角度下