一 概念說明

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值非常高

解決方式 分庫分表,改造業務,減少單臺集群的壓力

四 總結

和我之前排查異步復制的思路差不多,只是在并行復制的角度下

總結

以上是生活随笔為你收集整理的mysql copy pending_mysql 案例 ~ 主从复制延迟之并行复制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。