mysql 案例 ~ 主从复制延迟之并行复制

一 概念说明
   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 主库压力很大,同时并发数高,导致从库应用繁忙
   观察 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值非常高
    解决方式 分库分表,改造业务,减少单台集群的压力

四 总结

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