[MySQL学习] Innodb锁系统(4) Insert/Delete 锁处理及死锁示例分析

A.INSERT

插入操作在函数btr_cur_optimistic_insert->btr_cur_ins_lock_and_undo->lock_rec_insert_check_and_lock这里进行锁的判断,我们简单的看看这个函数的流程:

1.首先先看看欲插入记录之后的数据上有没有锁,

   next_rec = page_rec_get_next_const(rec);

   next_rec_heap_no = page_rec_get_heap_no(next_rec);

   lock = lock_rec_get_first(block, next_rec_heap_no);

如果lock为空的话,对于非聚集索引,还需要更新page上的最大事务ID。

实际上这里是比较松散的检查,大并发插入的时候,可以大大的降低创建锁开销。

那么其他事务如何发现这些新插入的记录呢(重复插入同一条记录显然应该被阻塞),这里会有个判断,其他事务去看看

新插入记录的事务是否还是活跃的,如果还是活跃的,那么就为这个事务主动增加一个锁记录(所谓的隐式锁就是么有锁。。。。),这个判断是在检查是否存在冲突键的时候进行的(row_ins_duplicate_error_in_clust->row_ins_set_shared_rec_lock->lock_clust_rec_read_check_and_lock->lock_rec_convert_impl_to_expl

row_ins_set_shared_rec_lock的目的是为了向记录上加一个LOCK_REC_NOT_GAP的LOCK_S锁,也就是非GAP的记录S锁,如果发现记录上有X锁(隐式锁转换为LOCK_REC | LOCK_X | LOCK_REC_NOT_GAP),显然是需要等待的(返回DB_LOCK_WAIT)

 

这里设置inherit为FALSE,然后返回DB_SUCCESS;

至于inherit的作用,稍后再议!


2.如果lock不为空,这意味着插入记录的下一个记录上存在锁,设置inherit为TRUE.

检查下一个记录上的锁是否和LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION相互冲突

    if (lock_rec_other_has_conflicting(

            LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION,

            block, next_rec_heap_no, trx)) {


        /* Note that we may get DB_SUCCESS also here! */

        err = lock_rec_enqueue_waiting(LOCK_X | LOCK_GAP

                           | LOCK_INSERT_INTENTION,

                           block, next_rec_heap_no,

                           index, the);


如果有别的事务在下一个记录上存在显式的锁请求,并且和锁模式( LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION) 冲突,那么

这时候当前事务就需要等待。


如果别的事务持有一个GAP类型的锁以等待插入,我们认为这个锁和当前插入不冲突。

如何判定锁之间是否冲突,在上一篇博客(http://mysqllover.com/?p=425)已经介绍过,不再赘述.


当检查到存在冲突的事务,我们就将一个锁模式为LOCK_X | LOCK_GAP|LOCK_X | LOCK_GAP 加入到请求队列中(调用函数lock_rec_enqueue_waiting),这里也会负责去检查死锁。


注意在加入等待队列的时候可能会返回DB_SUCCESS,例如死锁发生,但选择另外一个事务为牺牲者。


我们上面提到变量inherit,在存在下一个记录锁时会设置为TRUE,在上层函数btr_cur_optimistic_insert,会据此进行判断:

    if (!(flags & BTR_NO_LOCKING_FLAG) && inherit) {

        lock_update_insert(block, *rec);

    }  

注意当我们执行到这部分逻辑时err为DB_SUCCESS,表示锁检查已经通过了。

BTR_NO_LOCKING_FLAG表示不做记录锁检查

对于optimistic_insert, flags值为0

对于pessimistic_insert,flags值为BTR_NO_UNDO_LOG_FLAG | BTR_NO_LOCKING_FLAG | BTR_KEEP_SYS_FLAG


因此对于乐观更新(无需修改BTREE结构),当inherit被设置为TRUE时,总会调用lock_update_insert

根据注释,lock_update_insert用于继承下一条记录的GAP锁,流程如下

1.首先获取插入的记录的heap no和下一条记录的heap no

        receiver_heap_no = rec_get_heap_no_new(rec);

        donator_heap_no = rec_get_heap_no_new(

            page_rec_get_next_low(rec, TRUE));


其中receiver_heap_no是当前记录,donator_heap_no是下一条记录


2.调用lock_rec_inherit_to_gap_if_gap_lock函数,将donator_heap_no上所有非INSERT INTENTION且非LOCK_REC_NOT_GAP的记录锁

转移给receiver_heap_no

遍历donator_heap_no上的所有记录锁,继承锁的判定条件如下:

        if (!lock_rec_get_insert_intention(lock)

            && (heap_no == PAGE_HEAP_NO_SUPREMUM

            || !lock_rec_get_rec_not_gap(lock))) {


            lock_rec_add_to_queue(LOCK_REC | LOCK_GAP

                          | lock_get_mode(lock),

                          block, heir_heap_no,

                          lock->index, lock->trx);

        }


注意这里有对SUPREMUM记录的特殊处理。

也就是说,成功插入了一条记录,其他持有该记录的下一条记录上锁的事务也会持有新插入记录上的GAP锁。


说起INSERT,就不得不提到一个有趣的死锁案例。也就是bug#43210(http://bugs.mysql.com/bug.php?id=43210)

DROP TABLE t1;

CREATE TABLE `t1` (

  `a` int(11) NOT NULL,

  `b` int(11) DEFAULT NULL,

  PRIMARY KEY (`a`),

  KEY `b` (`b`)

) ENGINE=InnoDB;

insert into t1 values (1,19),(8,12);


Session 1:

set autocommit = 0;

insert into t1 values (6,12);


Session 2:

set autocommit = 0;

insert into t1 values (6,12);  //阻塞住,同时将session1的锁转换为显示锁。等待记录上的S锁 (查找dup key)

/****

session 1上的转为显式锁:lock_mode X locks rec but not gap

session 2等待的锁:lock mode S locks rec but not gap waiting

***/

Session 3:

set autocommit = 0;

insert into t1 values (6,12);  //阻塞住,和session2 同样等待S锁,lock mode S locks rec but not gap waiting


Session 1:

ROLLBACK;


Session 2:

执行插入成功

这时候Session 2持有的锁为主键记录上的:

lock mode S locks rec but not gap

lock mode S locks gap before rec

lock_mode X locks gap before rec insert intention


Session3:

被选为牺牲者,回滚掉。


很容易重现,当session 1回滚时,session2和session3提示死锁发生。


这里的关键是当ROLLBACK时,实际上是在做一次delete操作,backtrace如下:

trx_general_rollback_for_mysql->….->row_undo->row_undo_ins->row_undo_ins_remove_clust_rec->btr_cur_optimistic_delete->lock_update_delete->lock_rec_inherit_to_gap


我们来跟踪一下创建锁的轨迹

s1的事务0x7fdfd80265b8

s2的事务0x7fdfe0007c68

s3的事务0x7fdff00213f8


s1 , type_mode=1059     //s2为s1转换隐式锁为显式锁,

s2,  type_mode=1282    //检查重复键,需要加共享锁,被s1 block住,等待S锁

s3,  type_mode=1282    // 被s1 block住,等待S锁


s1, type_mode=547       //s1回滚,删除记录,lock_update_delete锁继承,

s2, type_mode=546        //创建s锁  LOCK_GAP | LOCK_REC | LOCK_S

s3, type_mode=546        //创建s锁   LOCK_GAP | LOCK_REC | LOCK_S


s2, type_mode=2819   // LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION

s3, type_mode=2819   //  LOCK_X | LOCK_GAP | LOCK_INSERT_INTENTION


看看show engine innodb status打印的死锁信息:

insert into t1 values (6,12)

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 137 page no 3 n bits 72 index `PRIMARY` of table `test`.`t1` trx id FE3BFA70 lock_mode X locks gap before rec insert intention waiting

*** (2) TRANSACTION:

TRANSACTION FE3BFA6F, ACTIVE 143 sec inserting, thread declared inside InnoDB 1

mysql tables in use 1, locked 1

4 lock struct(s), heap size 1248, 2 row lock(s)

MySQL thread id 791, OS thread handle 0x7fe2d4ea1700, query id 2613 localhost root update

insert into t1 values (6,12)

*** (2) HOLDS THE LOCK(S):

RECORD LOCKS space id 137 page no 3 n bits 72 index `PRIMARY` of table `test`.`t1` trx id FE3BFA6F lock mode S locks gap before rec

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 137 page no 3 n bits 72 index `PRIMARY` of table `test`.`t1` trx id FE3BFA6F lock_mode X locks gap before rec insert intention waiting

*** WE ROLL BACK TRANSACTION (2)


从上面的分析,我们可以很容易理解死锁为何发生。s1插入记录,s2插入同一条记录,主键冲突,s2将s1的隐式锁转为显式锁,同时s2向队列中加入一个s锁请求;

s3同样也加入一个s锁请求;

当s1回滚后,s2和s3获得s锁,但随后s2和s3又先后请求插入意向锁,因此锁队列为:

s2(S GAP)<—s3(S GAP)<—s2(插入意向锁)<–s3(插入意向锁)   s3,s2,s3形成死锁。

B.DELETE

Innodb的delete操作实际上只是做标记删除,而不是真正的删除记录;真正的删除是由Purge线程来完成的。

DELETE操作的记录加锁,是在查找记录时完成的。这一点,我们在上一节已经提到了。

上面我们有提到,对插入一条记录做回滚时,实际上是通过undo来做delete操作。这时候有一个lock_update_insert操作,我们来看看这个函数干了什么:

1.首先获取将被移除的记录HEAP NO和下一条记录的HEAP NO

        heap_no = rec_get_heap_no_new(rec);

        next_heap_no = rec_get_heap_no_new(page

                           + rec_get_next_offs(rec,

                                       TRUE));

2.然后获取kernel mutex锁,执行:

将被删除记录上的GAP锁转移到下一条记录上:

lock_rec_inherit_to_gap(block, block, next_heap_no, heap_no);

遍历heao_no上的锁对象,满足如下条件时为下一个记录上的事务创建新的锁对象:

        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);

        }

 

条件1:锁对象不是插入意向锁(INSERT INTENTION LOCK)

条件2:srv_locks_unsafe_for_binlog被设置为FALSE且隔离级别大于READ COMMITTED, 或者锁类型为LOCK_S     


和lock_update_insert类似,这里也会创建新的GAP锁对象


当完成锁表更新操作后,重置锁bit并释放等待的事务lock_rec_reset_and_release_wait(block, heap_no):

>>正在等待当前记录锁的(lock_get_wait(lock)),取消等待(lock_rec_cancel(lock))

>>已经获得当前记录锁的,重置对应bit位(lock_rec_reset_nth_bit(lock, heap_no);)


lock_update_delete主要在INSERT回滚及Purge线程中被调用到。


在查找数据时,DELETE会给记录加锁,在进行标记删除时,也会调用到锁检查函数:

聚集索引:

row_upd->row_upd_clust_step->row_upd_del_mark_clust_rec->btr_cur_del_mark_set_clust_rec->lock_clust_rec_modify_check_and_lock

这个backtrace,会从lock_clust_rec_modify_check_and_lock直接返回DB_SUCCESS,因为函数btr_cur_del_mark_set_clust_rec的参数flags总是

值为BTR_NO_LOCKING_FLAG

用户线程不做调用,但在btr_cur_upd_lock_and_undo则会继续走lock_clust_rec_modify_check_and_lock的流程。


二级索引:

row_upd->row_upd_sec_step->row_upd_sec_index_entry->btr_cur_del_mark_set_sec_rec->lock_sec_rec_modify_check_and_lock

用户线程里lock_sec_rec_modify_check_and_lock的flags参数为0,而在row_undo_mod_del_unmark_sec_and_undo_update、row_undo_mod_del_mark_or_remove_sec_low函数里则设置为BTR_NO_LOCKING_FLAG,表示不做检查。


lock_sec_rec_modify_check_and_lock用于检查是否有其他事务阻止当前修改一条二级索引记录(delete mark or delete unmark),


如果开始修改二级索引,则表示我们已经成功修改了聚集索引,因此不应该有其他事务在该记录上的隐式锁,也不应该有其他活跃事务修改了二级索引记录。该函数会调用:

    err = lock_rec_lock(TRUE, LOCK_X | LOCK_REC_NOT_GAP,

                block, heap_no, index, the);

第一个函数为TRUE,则当无需等待时,不会创建新的锁对象。


如果err返回值为DB_SUCCESS或者DB_SUCCESS_LOCKED_REC,就更新当前二级索引Page上的最大事务ID。

如果当前存在和LOCK_X|LOCK_REC_NOT_GAP相冲突的锁对象,则可能需要等待。


回到在之前博文提到的死锁,信息如下:

*** (1) TRANSACTION:

TRANSACTION 1E7D49CDD, ACTIVE 69 sec fetching rows

mysql tables in use 1, locked 1

LOCK WAIT 4 lock struct(s), heap size 1248, 4 row lock(s), undo log entries 1

MySQL thread id 1385867, OS thread handle 0x7fcebd956700, query id 837909262 10.246.145.78 im updating

delete    from        msg    WHERE     target_id = ‘Y25oaHVwYW7mmZbmmZblpKnkvb8=’      and         gmt_modified <= ‘2012-12-14 15:07:14′

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 203 page no 475912 n bits 88 index `PRIMARY` of table `im`.`msg` trx id 1E7D49CDD lock_mode X locks rec but not gap waiting

*** (2) TRANSACTION:

TRANSACTION 1E7CE0399, ACTIVE 1222 sec fetching rows, thread declared inside InnoDB 272

mysql tables in use 1, locked 1

1346429 lock struct(s), heap size 119896504, 11973543 row lock(s), undo log entries 1

MySQL thread id 1090268, OS thread handle 0x7fcebf48c700, query id 837483530 10.246.145.78 im updating

delete    from        msg    WHERE     target_id = ‘Y25oaHVwYW7niLHkuZ3kuYU5OQ==’      and         gmt_modified <= ‘2012-12-14 14:13:28′

*** (2) HOLDS THE LOCK(S):

RECORD LOCKS space id 203 page no 475912 n bits 88 index `PRIMARY` of table `im`.`msg` trx id 1E7CE0399 lock_mode X

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 203 page no 1611099 n bits 88 index `PRIMARY` of table `im`.`msg` trx id 1E7CE0399 lock_mode X waiting


表结构为:

CREATE TABLE `msg` (

  `id` bigint(20) NOT NULL AUTO_INCREMENT,

  `target_id` varchar(100) COLLATE utf8_bin NOT NULL ,

       ……

       ……

  `flag` tinyint(4) NOT NULL ,

  `gmt_create` datetime NOT NULL,

  `gmt_modified` datetime NOT NULL,

  `datablob` blob,

  `nickname` varchar(64) COLLATE utf8_bin DEFAULT NULL ,

  `source` tinyint(4) DEFAULT NULL ,

  PRIMARY KEY (`id`),

  KEY `idx_o_tid` (`target_id`,`gmt_modified`,`source`,`flag`)

) ENGINE=InnoDB 

首先我们从死锁信息里来看,发生死锁的是两个delete语句,

delete    from        offmsg_0007    WHERE     target_id = ‘Y25oaHVwYW7mmZbmmZblpKnkvb8=’      and         gmt_modified <= ‘2012-12-14 15:07:14′

delete    from        offmsg_0007    WHERE     target_id = ‘Y25oaHVwYW7niLHkuZ3kuYU5OQ==’      and         gmt_modified <= ‘2012-12-14 14:13:28′

 

我们再看看这个表上的索引,一个主键索引(target_id),一个二级索引(`target_id`,`gmt_modified`,`source`,`flag`)

根据前缀索引的原则,理论上我们应该可以通过二级索引来查找数据,从上一节的分析,我们知道,如果根据二级索引查找数据:

>>二级索引上加X 锁,记录及GAP

>>聚集索引上加记录X锁

我们再看死锁信息:

第一条SQL等待聚集索引Page 475912上的lock_mode X locks rec but not gap, 这说明该锁请求等待是走二级索引的

第二条SQL持有聚集索引Page 475912上的lock_mode X锁,等待聚集索引Page 1611099上的 lock_mode X

因此我们大致可以认为第二条SQL总是在请求聚集索引上的LOCK_ORDINARY类型的锁,简单的gdb我们可以知道走聚集索引做范围删除,锁模式值为3,也就是LOCK_X

因此,可以推测delete操作走错了索引,导致出现资源的互相占用。从而死锁;至于为什么走错索引,这就是优化器的问题了,暂不明;

C.释放锁

在事务提交或回滚时,会释放记录锁,调用函数为lock_release_off_kernel

函数的逻辑很简单,遍历trx->trx_locks。

对于记录锁,调用lock_rec_dequeue_from_page(lock)

–>从lock_sys中删除

–>检查lock所在page上的等待的锁对象是否能被grant(lock_grant),如果可以,则唤醒等待的事务。

对于表锁,调用lock_table_dequeue(lock)


上一篇:操作系统的理念—以windows和linux为例


下一篇:在 CentOS 7.1 上安装分布式存储系统 Ceph