Mysql транзакция ожидает блокировки, которая уже предоставлена ​​.. Это вызывает тупик - PullRequest
Новая
       9

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

10 голосов
/ 25 января 2010

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

MySQL версия: mysql.x86_64 5.0.77-4.el5_4.1

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

Ответы [ 3 ]

6 голосов
/ 28 июня 2012

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

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

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

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

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

1 голос
/ 13 февраля 2012

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

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

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

НТН

0 голосов
/ 25 августа 2011

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

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

...