MySQL多线程复制故障(slave_pending_jobs_size_max)

最近,经常遇到mysql多线程复制故障的问题,报错有以下几种:

第一种:

Last_Error: Cannot schedule event Rows_query, relay-log name ./db-s18-relay-bin.000448, position 419156572 to Worker thread because its size 18483519 exceeds 16777216 of slave_pending_jobs_size_max.

第二种:

[Note] Multi-threaded slave: Coordinator has waited 701 times hitting slave_pending_jobs_size_max; current event size = 8167.

BUG地址:https://bugs.mysql.com/bug.php?id=68462

以上两种报错,初步判断问题可能在 slave_pending_jobs_size_max 的大小上,此值,官方默认是 16M,此值可以动态调整
关于此值的一些说明:

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

此值有如下几种情况:

     1.- 如果event大小已经超过了等待任务大小的上限(配置slave-pending-jobs-size-max ),就报event太大的错,然后返回;
     2.- 如果event大小+已经在等待的任务大小超过了slave-pending-jobs-size-max,就等待,至到等待队列变小;
     3.- 如果当前的worker的队列满的话,也等待。

下面是官方关于此参数的一些说明:(图片看不了,可点击查看大图)

QQ图片20160524124437

 

 

mysql 5.6在gtid复制模式下复制错误,如何跳过??

这里就不粘贴复制的报错状态信息,简要说一下当前的环境:

系统为:red hat linux 6 (2.6.32)

mysql版本为:5.6.10

采用的一机多实例的部署方式

前言:

gtid 复制模式下,不要使用 replicate_wild_do_table 此参数,使用此类参数,会复制异常(即状态信息正常,但从机没有复制过来)

下面进入正题:

在我们遇到复制错误时,如果复制没有特别的错误时,我们一般采用 set global sql_slave_skip_counter=1 来跳过错误,但是,在mysql 5.6 的gtid模式下,此方法是没有作用的。我们采取如下方式:

1.查看从机的复制状态信息:(主要是以下几个值)

Retrieved_Gtid_Set: D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:141-151

Executed_Gtid_Set: D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-140

Retrieved_Gtid_Set项:记录了relay日志从Master获取了binlog日志的位置

Executed_Gtid_Set项:记录本机执行的binlog日志位置(如果是从机,包括Master的binlog日志位置和slave本身的binlog日志位置)

2.在从机上执行如下操作,以下所有操作,如果没有特别说明,均在从机上执行:

> reset master;

> reset slave all;

> set global grid_purged=’D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-141′;

> change master to master_host=’****’,master_user=’****’,master_password=’******’,master_port=3306,master_auto_position=1;

> start slave;

> show slave status\G;

此时再查看复制状态信息,重复以上操作 set global grid_purged=’D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-141′; 此值依次往后推,直到复制正常为止

其它相关信息,可以参考下面博客链接:

http://imysql.cn/2014/07/31/mysql-faq-exception-replication-with-gtid.shtml