mysql多线程复制crash_MySQL 并行复制(MTS) 从库发生异常crash分析

背景

半同步复制从库在晚上凌晨2点半发生异常crash，另一个异步复制从库在第二天凌晨3点也发生了异常crash。

版本

mysql 5.7.16

redhat 6.8

mysql> show variables like ‘%slave_para%’;

+————————+—————+

| Variable_name | Value |

+————————+—————+

| slave_parallel_type | LOGICAL_CLOCK |

| slave_parallel_workers | 16 |

+————————+—————+

分析

mysqld服务在以mysqld_safe守护进程启动的情况下，在发生mysqld异常情况(比如OOM)会自动拉起mysqld服务，但已确认两个从库实例messages中无与OOM相关的日志。

从监控中发现，两个从库与Seconds_Behind_Master没有很高的异常上升。

参数slave_pending_jobs_size_max 在多线程复制时，在队列中Pending的事件所占用的最大内存，默认为16M，如果内存富余，或者延迟较大时，可以适当调大;注意这个值要比主库的max_allowed_packet大。

参考官方文档：slave_pending_jobs_size_max

两个发生异常crash的从库日志中都出现了ibuf record inserted to page x:x ，通过查看space_id发现都是对应的同一张表(a_xxx.join_acct_flow)，疑是晚上的定时任务对这张表做了大事务的操作。从库的并行复制只有对并发提交的事务才会进行并行应用，对一个大事务，只有一个线程进行应用。