![]() ![]() The log doesn't tell who holds "heap no 73" but maybe it's just a limitation of "SHOW ENGINE INNODB STATUS". Tx(2) holds "heap no 61" record lock and is waiting for "heap no 73" record lock. Lock, heap no 73 PHYSICAL RECORD: n_fields 26 compact format info Trx id 0 479286425 lock_mode X locks rec but not gap waiting Record * (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 17548 n bits 144 index PRIMARY of table takeyourorder/jobs * (2) HOLDS THE LOCK(S): RECORD LOCKS space id 0 page no 17549 n bits 128 index PRIMARY of table takeyourorder/jobs trx id 0Ĥ79286425 lock_mode X locks rec but not gap Record lock, heap no 61 PHYSICAL RECORD: n_fields 26 compact format info bits 0 Trx id 0 479286429 lock_mode X waiting Record lock, heap no 61 * (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 17549 n bits 128 index PRIMARY of table takeyourorder/jobs I'm not 100% sure but I believe they are not "the same lock". RECORD LOCKS space id 0 page no 17548 n bits 144 index `PRIMARY` of table `takeyourorder/jobs` trx id 0 479286425 lock_mode X locks rec but not gap waiting *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 17549 n bits 128 index `PRIMARY` of table `takeyourorder/jobs` trx id 0 479286425 lock_mode X locks rec but not gap UPDATE jobs SET status='done' WHERE jid=10099 TRANSACTION 0 479286425, ACTIVE 0 sec, process no 17618, OS thread id 2971134864 starting index read, thread declared inside InnoDB 500ħ lock struct(s), heap size 1024, undo log entries 3 RECORD LOCKS space id 0 page no 17549 n bits 128 index `PRIMARY` of table `takeyourorder/jobs` trx id 0 479286429 lock_mode X waiting ![]() *** (1) WAITING FOR THIS LOCK TO BE GRANTED: ![]() SELECT api_key,completed,compute_units,created,deleted,flags,func_name,group_id,hostname,is_meta,jid,label,language,num_children,parent_ujid,priority,process_id,restartable,status,type,uid,ujid,version,wid FROM jobs WHERE status='new' and is_meta=0 ORDER BY priority asc,jid asc FOR UPDATE LOCK WAIT 176 lock struct(s), heap size 11584 TRANSACTION 0 479286429, ACTIVE 0 sec, process no 17618, OS thread id 2963139472 fetching rows Mutex spin waits 0, rounds 1569878, OS waits 4740 OS WAIT ARRAY INFO: reservation count 233826, signal count 229982 Per second averages calculated from the last 39 seconds Can someone care to explain why the transaction was aborted? It seems that Transaction 2 is holding the lock, but is also stuck requesting the same lock (except for the "waiting" part), which leads to a deadlock when Transaction 1 requires it as well. I received the following deadlock log via "SHOW INNODB STATUS". ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |