Операция Mysql, ожидающая блокировки, которая уже предоставлена ​​.. Это вызывает тупик

Question

Если следующая ситуация ошибка в mysql ?.

Mysql Версия: mysql.x86_64 5.0.77-4.el5_4.1

Ядро: Linux box2 2.6.18-128.el5 # 1 SMP Wed 21 января 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux

------------------------ 
LATEST DETECTED DEADLOCK 
------------------------ 
100125 4:24:41 
*** (1) TRANSACTION: 
TRANSACTION 0 210510625, ACTIVE 155 sec, process no 28125, OS thread id 1243162944 starting index read 
mysql tables in use 1, locked 1 
LOCK WAIT 5 lock struct(s), heap size 1216, undo log entries 1 
MySQL thread id 162928579, query id 527252744 box22 172.16.11.105 user updating 
delete from user_grid_items where user_id = 669786974 and START_X = 45 and START_Y = 65 
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210510625 lock_mode X locks rec but not gap waiting 
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 
0: len 8; hex 0000000027ec235e; asc  ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc @ ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc  ;; 9: len 1; hex 80; asc ;; 

*** (2) TRANSACTION: 
TRANSACTION 0 210505911, ACTIVE 555 sec, process no 28125, OS thread id 1184323904 starting index read, thread declared inside InnoDB 500 
mysql tables in use 1, locked 1 
5 lock struct(s), heap size 1216, undo log entries 1 
MySQL thread id 162924258, query id 527252762 box22 172.16.11.105 user updating 
delete from user_grid_items where user_id = 669786974 and START_X = 45 and START_Y = 65 
*** (2) HOLDS THE LOCK(S): 
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210505911 lock mode S locks rec but not gap 
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 
0: len 8; hex 0000000027ec235e; asc  ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc @ ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc  ;; 9: len 1; hex 80; asc ;; 

*** (2) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210505911 lock_mode X locks rec but not gap waiting 
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 
0: len 8; hex 0000000027ec235e; asc  ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc @ ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc  ;; 9: len 1; hex 80; asc ;; 

*** WE ROLL BACK TRANSACTION (2) 
------------ 

Answer 1

Использование SHOW ENGINE INNODB STATUS определить причину последнего тупика. Это поможет вам настроить ваше приложение, чтобы избежать взаимоблокировок.

Всегда будьте готовы повторно произвести транзакцию, если она не удалась из-за тупика. Тупики не опасны. Попробуйте еще раз.

Answer 2

Я давно что-то прочитал и не уверен, что это МОЖНО быть тем, в чем вы работаете, или нет ... не видя кода транзакции текущего и противоречащего ему.

При обработке транзакций вы должны попытаться заставить их всегда делать блокировку в одной последовательности ... Для заказа/порядка заказа/системы платежей выполните действия в порядке, указанном здесь как пример для всех подобных. Если у вас есть другой процесс, который пытается выполнить транзакцию в порядке «Детали заказа/заказа», это может привести к тупиковой ситуации.

Одна транзакция - это блокировка заказа № сначала, а затем обработка детали заказа. Другая транзакция сначала блокирует детали заказа, а затем пытается получить заголовок заказа.

НТН

Answer 3

Иногда SHOW ENGINE INNODB STATUS может быть трудно расшифровать, потому что он показывает только текущее выражение в сделке. Он не показывает операторов, которые произошли ранее в той же транзакции, которая могла бы получить заблокированные блокировки.

В вашем случае предыдущий оператор транзакции 2 приобрел общую блокировку в соответствующей строке.

Затем транзакция 1 попыталась получить эксклюзивную блокировку в той же строке и с радостью ожидает удаления общей блокировки.

Затем транзакция 2 в другом заявлении попыталась получить эксклюзивную блокировку в той же строке. Классический тупик. Ни одна транзакция не может завершиться.

Одним из решений, помогающих избежать такого тупика, является захват исключительной блокировки строки в транзакции 2 с оператором SELECT FOR UPDATE до утверждения, которое приобретает общий замок.