(bugfix in 5.6.21) DUPLICATES IN UNIQUE SECONDARY INDEX BECAUSE OF FIX OF BUG#68021

(bugfix in 5.6.21) DUPLICATES IN UNIQUE SECONDARY INDEX BECAUSE OF FIX OF BUG#68021

在MySQL5.6.21版本里,fix了这样一个有趣(坑爹)的bug,影响5.6.12之后及5.6.21之间的版本
InnoDB: With a transaction isolation level less than or equal to READ COMMITTED, gap locks were not taken when scanning a unique secondary index to check for duplicates. As a result, duplicate check logic failed allowing duplicate key values in the unique secondary index.

参考的bug号为:
http://bugs.mysql.com/bug.php?id=68021 (由于fix bug#68021导致的上述问题)
http://bugs.mysql.com/bug.php?id=73170 (在bug#73170中移除了对应的fix)

根据上述信息,我有意识的在里面加了些DEBUG SYNC点,并重现了该过程

root@sb 03:45:16>select * from t1 where b >=7;
+—-+——+——+
| a | b | c |
+—-+——+——+
| 7 | 8 | 9 |
| 16 | 7 | 8 |
| 26 | 7 | 8 |
+—-+——+——+
3 rows in set (0.00 sec)

可以看到,这里b为uk,却插入了两条相同的记录。

root@sb 03:45:27>show create table t1;
+——-+————————————————————————————————————————————————————————————–+
| Table | Create Table |
+——-+————————————————————————————————————————————————————————————–+
| t1 | CREATE TABLE `t1` (
`a` int(11) NOT NULL,
`b` int(11) DEFAULT NULL,
`c` int(11) DEFAULT NULL,
PRIMARY KEY (`a`),
UNIQUE KEY `b` (`b`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
+——-+————————————————————————————————————————————————————————————–+
1 row in set (0.00 sec)

root@sb 10:34:57>check table t1;
+——-+——-+———-+——————————————+
| Table | Op | Msg_type | Msg_text |
+——-+——-+———-+——————————————+
| sb.t1 | check | Warning | InnoDB: Index “b” is marked as corrupted |
| sb.t1 | check | error | Corrupt |
+——-+——-+———-+——————————————+
2 rows in set (0.15 sec)

简单的解释下,我使用的是READ COMMIT隔离级别。

step 1:
在某个session 执行flush tables tbname for export….这会使purge操作停下来

step 2:
删除某条记录,其二级索引为uk1, 执行的是标记删除,由于purge被我们人为的停止,因此这条记录不会立刻被清理掉

step 3:
插入记录,包含唯一索引记录uk1,由于step2的记录还在(没被purge),因此需要检查唯一性,在函数row_ins_scan_sec_index_for_duplicate中,根据隔离级别在记录上加S NOT GAP 锁.唯一性检查后commit mini transaction

step 4
和step 3 类似,另外一个session也插入uk1, 同样加上S NOT GAP锁,并commit mini transaction

step 5
两个session现在可以进行插入,因为受block x锁限制,插入过程是顺序的。但两次插入都能成功,原因是在做插入锁检查时,会检查相邻记录是否存在LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION)相冲突的锁, 而GAP锁和NOT GAP的S锁是不冲突的(参考lock_rec_has_to_wait), 因此两次插入都能顺利进行下去。

ref: btr_cur_optimistic_insert->lock_rec_insert_check_and_lock

Fix:
官方的fix是把对bug#68021的补丁给恢复掉。也就是说,在检查duplicate key时,总是加GAP S 锁,也就是LOCK_ORDINARY S锁
这样过程归纳为:
session 1 hold LOCK_ORDINARY S LOCK
session 2 hold LOCK_ORDINARY S LOCK
session 1 INSERT RECORD…CONFLICT, ENQUEUE (LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION) ——> WAIT
session 2 INSERT RECORD…CONFLICT, ENQUEUE LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION ——> DEAD LOCK HAPPEN

如上描述,这会有一定的几率发生死锁,并且通常会让人摸不着头脑。。。当然,死锁肯定比让二级索引corruption掉要好多了…

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

本文链接地址: (bugfix in 5.6.21) DUPLICATES IN UNIQUE SECONDARY INDEX BECAUSE OF FIX OF BUG#68021

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 *