一 概念说明
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值非常高
解决方式 分库分表,改造业务,减少单台集群的压力
四 总结
和我之前排查异步复制的思路差不多,只是在并行复制的角度下