InnoDB: Failing assertion: trx->isolation_level == TRX_ISO_READ_UNCOMMITTED

最近再次碰到之前遇到的断言失败的bug，错误信息如下：

InnoDB: Failing assertion: trx->isolation_level == TRX_ISO_READ_UNCOMMITTED

 

这是一个已知的bug（bug#62037），在MySQL5.5.22版本中被fix掉，在lauchpad上可以看到具体是如何修复的

 

如何重现

重现case，使用gdb的non-stop模式很容易重现：

启动gdb，使用non-stop

set target-async 1

set pagination off

set non-stop on



断点：

row0upd.c：2033   (Percona Server5.5.18)



case:



session 1:

 CREATE TABLE `t1` (   `a` int(11) DEFAULT NULL,   `b` text,   `c` text ) ENGINE=InnoDB DEFAULT CHARSET=gbk;

insert into t1 values (1,repeat(‘b’, 7000), repeat(‘c’, 100));

update t1 set c = concat(c, repeat(‘c’, 2000));

这时候会因为更新列c而导致b列的数据被外部存储(b的列长最大)，停在断点

session 2:执行查询

select * from t1 where a = 1;

该bug主要包含两个问题：

问题一：运行时断言失败

主要原因是：

1.更新记录时，undo中只记录了那些被更新的列，而由于其他列更新，导致某个列需要外部存储时，这个列的值不会写入undo。

也就是说，在从函数btr_cur_pessimistic_update中返回后，记录上某个未被更新的列，可能存储的是无效的指针

例如上述场景b列被选出来外部存储，因为它的长度最大，因此b列的数据被修改成一个尚未生效的值全为0的指针；

在悲观更新返回后，由于先mtr commit，再更新外部存储数据，这导致block及索引上的排他锁都被释放掉；这时候其他连接的查询是可以看到这条记录的。

2.虽然MVCC保证查询可以看到修改过的列，但1提到的未修改但被选作外部存储的列没有做undo，因此查询看到的是指针，导致触发断言失败，实例crash

解决：

官方的解决办法是在悲观更新和更新完外部存储列后，才进行mtr commit，这可以保证中间不会有其他查询看到未完成的更新（被阻塞住）

问题二：断言失败crash后，无法crash recovery

原因：

如果在完成悲观更新和写入外部存储列的过程中crash，记录更新可能完成了，但外部存储列是失败的，在crash recovery后，记录依然维持在不一致的状态。这样只要一访问该记录，就会报和问题一一样的断言crash错误

解决：

将上述逻辑修改为：

1.对原记录进行修改，mtr不提交（用btr_mtr代表该mtr）

2.扩展新的外部存储页(不能使用btr_mtr之前释放掉的page，暂时没搞明白为什么…)，对新的外部存储页的写入（包括初始化）使用另外一个mtr（称为blob_mtr），对记录上指针的更新使用btr_mtr

3.commit blob_mtr

4.commit btr_mtr

这样在crash recovery的时候，就会先恢复blob页，再恢复记录上的操作；最差的情况就是丢失更新，ibd中存在一个有部分数据的无效blob页，但记录本身仍然能保持一致的状态

 

另外在插入记录时也可能触发该bug，例如，当一条记录被标记删除，但未被purge掉时，如果再次插入该聚集索引记录，被标记删除的记录就会被更新成现在的记录，这时候触发bug的逻辑就和上述Update的逻辑类似了。