MySQL5.6.23: fix “UNABLE TO PURGE A RECORD”

本文简述下之前我们线上频繁碰到的“UNABLE TO PURGE A RECORD”的原因

###################################################

线上实例错误日志中偶尔出现 “UNABLE TO PURGE A RECORD”,从官方bug系统来看,很多用户都遇到了类似的问题。

当change buffer模块以如下序列来缓存索引操作时:

  1. 记录被标记删除(IBUF_OP_DELETE_MARK)
  2. 随后插入相同记录–IBUF_OP_INSERT
  3. Purge线程需要物理删除二级索引记录,操作被buffer–IBUF_OP_DELETE

 

当读入物理页时,需要进行ibuf merge,当执行到IBUF_OP_DELETE时,发现记录并没有被标记删除,导致错误日志报错。

 

显然上述的操作序列是不合理的,正确的序列应该是IBUF_OP_DELETE_MARK,IBUF_OP_DELETE,IBUF_OP_INSERT。

 

为了理清逻辑,我们简单的理一下相关代码

 

注意IBUF_OP_DELETE是由第一步的标记删除操作触发,Purge线程发起;在每个buffer pool的控制结构体中,有一个成员buf_pool->watch[BUF_POOL_WATCH_SIZE],BUF_POOL_WATCH_SIZE的值为purge线程个数,用于辅助Purge操作。

 

假定内存中没有对应的Page,Purge线程会做如下几件事儿:

  • 首先查询buffer pool,看看page是否已经读入内存;

如果不在内存中,则将page no等信息存储到watch数组中,并插入page hash(buf_pool_watch_set)。如果随后page被读入内存,就会删除watch标记。

  • 判断该二级索引记录是否可以被Purge(row_purge_poss_sec,当该二级索引记录对应的聚集索引记录没有delete mark并且其trx id比当前的purge view还旧时,不可以做Purge操作)

 

  • 随后,再插入IBUF_OP_DELETE类型的ibuf记录时,还会double check下该page是否被设为sentinel (ibuf_insert_low,buf_pool_watch_occurred),如果未被设置,表明已经page已经读入内存,就可以直接去做purge,而无需缓存了。

 

  • 对于普通的操作类型,例如IBUF_OP_INSERT和IBUF_OP_DELETE_MARK,同样也会double check page 是否读入了内存。在函数ibuf_insert中会调用buf_page_hash_get进行检查, 如果page被读入内存,则不缓存操作,如果请求的Page被设为sentinel,则从buf_page_hash_get返回NULL,因此随后判定需要缓存操作。这也正是问题的所在:
  1. 标记删除记录,写入IBUF_OP_DELETE_MARK
  2. Purge线程设置page对应的sentinel,完成合法性检查,准备调用ibuf_insert
  3. 插入相同记录,写入IBUF_OP_INSERT
  4. Purge线程写入IBUF_OP_DELETE

解决

如果记录所在的page被设置了一个sentinel,那么对该page的并发插入操作就不应该缓存到change buffer中,而是直接去尝试读取物理页。

https://github.com/mysql/mysql-server/commit/ec369cb4f363161dfbbbd662b20763b54808b7d1

 

原创文章,转载请注明: 转载自Simple Life

本文链接地址: MySQL5.6.23: fix “UNABLE TO PURGE A RECORD”

Post Footer automatically generated by wp-posturl plugin for wordpress.


Comments

Leave a Reply

Your email address will not be published. Name and email are required


Current month ye@r day *