一 概念
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,但是顺序提交,防止数据紊乱(这里理解的应该是同一时间事务组的顺序提交)