[MySQL bug] unique key corruption again…..

最近Percona的研发人员report了一个uk corruption的bug,这个Bug不同于之前发现的bug(见我的另外一篇博客http://mysqllover.com/?p=1041),而是影响从5.1 到5.8全系列MySQL版本,应该算是设计上的缺陷吧。

创建测试表
CREATE TABLE t1 (      
a INT NOT NULL,      
b INT NOT NULL,      
PRIMARY KEY(b),      
UNIQUE KEY(a)) ENGINE=INNODB;

INSERT INTO t1 VALUES (1,1),(2,2);

 

0. 停止Purge操作:SET GLOBAL innodb_purge_stop_now = ON; 防止标记删除的记录被purge掉
删除表上的数据:DELETE FROM t1;  //这时候表上物理记录还存在,只是被标记删除了。
1. SESSION 1: REPLACE INTO t1 VALUES (1,2);
由于有一条标记删除的记录,检查pk上duplicate key,在聚集索引上加锁:mode=1027 (1024 +3 = LOCK_REC_NOT_GAP | LOCK_X)
堆栈:
row_ins_clust_index_entry 
|--> row_ins_clust_index_entry_low 
	|--> row_ins_duplicate_error_in_clust 
		|--> row_ins_set_exclusive_rec_lock 
			|-->lock_clust_rec_read_check_and_lock
检查二级索引duplicate key,由于存在标记删除的记录,这里需要加锁,类型为X锁
堆栈:
row_ins_index_entry 
|-->row_ins_sec_index_entry 
	|--> row_ins_sec_index_entry_low 
		|--> row_ins_scan_sec_index_for_duplicate 
			|--> row_ins_set_exclusive_rec_lock 
				|--> lock_sec_rec_read_check_and_lock

 

当完成duplicate key检测后 (当然这里是成功的),我们让SESSION1稍微等一会(设置DEBUG SYNC同步点)
2. SESSION 2:REPLACE INTO t1 VALUES (1,3);  
尝试插入第二条记录,这条记录和SESSION1插入的uk是冲突的,pk不冲突,因此先插入pk成功,然后检查uk上的duplicate key加锁:mode =3,但是session1已经在uk为1的记录上加X锁了,因此Session 2进入锁等待
加锁堆栈:
row_ins_index_entry  
|--> row_ins_sec_index_entry 
	|--> row_ins_sec_index_entry_low 
		|--> row_ins_scan_sec_index_for_duplicate 
			|--> row_ins_set_exclusive_rec_lock 
				|--> lock_sec_rec_read_check_and_lock
mysql> select * from information_schema.innodb_locks;
+------------+-------------+-----------+-----------+-------------+------------+------------+-----------+----------+-----------+
| lock_id | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data |
+------------+-------------+-----------+-----------+-------------+------------+------------+-----------+----------+-----------+
| 1300:6:4:2 | 1300 | X | RECORD | `test`.`t1` | a | 6 | 4 | 2 | 1 |
| 1299:6:4:2 | 1299 | X | RECORD | `test`.`t1` | a | 6 | 4 | 2 | 1 |
+------------+-------------+-----------+-----------+-------------+------------+------------+-----------+----------+-----------+
2 rows in set (0.00 sec)
3. 开启Purge操作:SET GLOBAL innodb_purge_run_now=ON;
后台Purge线程会去清理标记删除的二级索引记录,但之前session1和session2都有请求uk上的排他锁,记录没有了,这些锁对象也需要做对应的处理,理论上锁请求应该被下一条记录锁继承,并转换成GAP锁
堆栈:
row_purge_step 
|--> row_purge 
	|--> row_purge_record_func 
		|--> row_purge_del_mark 
			|--> row_purge_remove_sec_if_poss 
				|--> row_purge_remove_sec_if_poss_leaf 
					|--> btr_cur_optimistic_delete_func 
						|--> lock_update_delete 
							|--> lock_rec_inherit_to_gap
我们来看看锁继承的逻辑,函数为lock_rec_inherit_to_gap:
        for (lock = lock_rec_get_first(block, heap_no);
             lock != NULL;
             lock = lock_rec_get_next(heap_no, lock)) {
                if (!lock_rec_get_insert_intention(lock)
                    && !((srv_locks_unsafe_for_binlog
                          || lock->trx->isolation_level
                          <= TRX_ISO_READ_COMMITTED)
                         && lock_get_mode(lock) == LOCK_X)) {

                        lock_rec_add_to_queue(
                                LOCK_REC | LOCK_GAP | lock_get_mode(lock),
                                heir_block, heir_heap_no, lock->index,
                                lock->trx, FALSE);
                }
        }

 

对于如下场景,不会做锁继承:
a. 锁类型为插入意向锁
b. srv_locks_unsafe_for_binlog打开且锁类型为X锁
c. 锁对应事务的隔离级别小于等于RC且锁类型为X锁
由于在执行类似REPLACE, LOAD DATAFILE REPLACE, INSERT ON DUPLICATE KEY UPDATE等操作时,当检查duplicate key时加的是X锁,本测试样例的隔离级别为RC,因此锁对象未被继承,而是直接解除了,随后等待锁的线程(session2)被唤醒(lock_update_delete –> lock_rec_reset_and_release_wait)。
从IS表也可以看出来这一变化:
mysql> select * from information_schema.innodb_locks;
Empty set (0.00 sec)

 

此时innodb_locks里面已经没有记录了,purge操作“悄悄”的破坏了InnoDB的锁协议。
随后唤醒SESSION2继续操作。
4. SESSION 2: 由于获得了记录锁,因此可以继续插入记录
5. SESSION 1:由于已经完成了duplicate key检查,因此可以继续插入记录
mysql> select * from t1;
+---+---+
| a | b |
+---+---+
| 1 | 2 |
| 1 | 3 |
+---+---+
2 rows in set (0.00 sec)

mysql> check table t1;
+---------+-------+----------+-----------------------------------------------+
| Table   | Op    | Msg_type | Msg_text                                      |
+---------+-------+----------+-----------------------------------------------+
| test.t1 | check | Warning  | InnoDB: The B-tree of index "a" is corrupted. |
| test.t1 | check | error    | Corrupt                                       |
+---------+-------+----------+-----------------------------------------------+
2 rows in set (0.00 sec)
问题及解决
问题的原因Alexey其实在bug上已经解释的很清楚,Innodb认为只可能加S锁来维持一致性约束,因此当记录被物理删除时,只有S类型的锁才被继承。但对于REPLACE这样的操作,加的是X类型的锁,这种锁类型必须也要考虑进去,将其继承给下一条记录。Alexey已经将patch push到percona server,改动也就一行:
 lock_gap
Ref:

 

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

本文链接地址: [MySQL bug] unique key corruption again…..

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


Comments

  • a thought by jusonalien

    您好博主,我想请问一下有没有什么能够测试MySQL对于裸设备的读写IO性能测试的较好的方案呢?

    Reply

    • a thought by zhaiwx1987

      表示没测过裸设备 :(

      Reply

  • a thought by MySQL · 引擎特性 · InnoDB 事务锁简介-IT大道

    […] 从上述判断可以看出,即使在RC隔离级别下,也有可能继承LOCK GAP锁,这也是当前版本InnoDB唯一的意外:判断Duplicate key时目前容忍GAP锁。上面这段代码实际上在最近的版本中才做过更新,更早之前的版本可能存在二级索引损坏,感兴趣的可以阅读我的 这篇博客 […]

    Reply

Leave a Reply

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


Current month ye@r day *