mysql 原理 ~ 并行复制

一 概念
1 MTS（Prepared transactions slave parallel applier）
   主库在同一时间进入prepare状态的事务可以被从库并行回放
2 传统与改进
   mariadb 从库回放处理(Commit-Parent-Based模式) 一组事务全部执行完才会执行下一组事务,时间:所有一组事务并行执行的总和 问题 一旦一组事务其中一个为大事务,那么整组事务的执行时间会被拖延,导致并行复制下的延时,拖累回放进度
   mysql5.7 从库回放处理(Lock-Based模式) 一组事务其中一个事务执行完,那么后续事务只要cq小于等于上一组事务最小seq号(代表不会有锁冲突),就可以继续执行,这样加快了执行的效率
3 线程
  模型:生产者 Coordinator
   消费者模型 Worker
4 并行复制须知
  1 普通复制也支持并行复制,但是还是提倡采用GTID复制
  2 并行复制并不能完全避免大事务和DDL产生的延时问题,只能尽量缓解,
  3 并行复制所要实现的目标是完全按照主库情况回放,这里要注意,主库如果串行,那么从库也一定是串行.
     这里存在的一种情况就是在业务不繁忙的情况下,DBA或者研发进行删除数据或者执行DDL操作,这样的并行复制情况下一定会有延时
  4 并行复制进程可能存在单个线程应用错误,但是IO and sql thread 为YES的情况
5 监控
  健康监控 IO_THREAD,SQL_THREAD Seconds_Behind_Master
  replication_applier_status_by_worker 查看worker的消费并行读
6 参数
  1 slave_pending_jobs_size_max
    说明 如果event大小已经超过了等待任务大小的上限（配置slave-pending-jobs-size-max )，就报event太大的错，然后返回
    调优 在多线程复制时，在队列中Pending的事件所占用的最大内存，默认为16M，如果内存富余，或者延迟较大时，可以适当调大;注意这个值要比主库的max_allowed_packet大,主要针对大事务
  2 slave-parallel-type=LOGICAL_CLOCK //事务级别复制
  3 slave-parallel-workers=16 //消费者线程
  4 relay_log_recovery=ON //保证relay-log的完整性
  5 master_info_repository=TABLE
   relay_log_info_repository=TABLE //复制信息记录
 6 slave_preserve_commit_order //并行应用relay-log,但是顺序提交,防止数据紊乱(这里理解的应该是同一时间事务组的顺序提交)