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

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

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

Ядро: Linux box2 2.6.18-128.el5 # 1 SMP Wed Jan 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)
------------

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

НТН

Ответ 3

Используйте ПОКАЗАТЬ ДВИГАТЕЛЬ INNODB STATUS, чтобы определить причину последнего тупика. Это поможет вам настроить ваше приложение, чтобы избежать взаимоблокировок.

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