本文简述下之前我们线上频繁碰到的“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