一 概念说明

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

解决方式 分库分表,改造业务,减少单台集群的压力

四 总结

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