Как я могу устранить взаимоблокировку транзакции?

Используя «show engine innodb status», я вижу, что WordPress имеет две взаимоблокировки. Я хотел бы прояснить это, но я не вижу активного процесса ни для одной из этих команд (IE что-то, что нужно «убить» и, надеюсь, вызвать откат).

Я вижу идентификаторы потоков, идентификаторы запросов и т. д., но ничего, что я мог бы использовать для остановки любого задания.

Предложения о том, как это решить?

РЕДАКТИРОВАТЬ: Вот (соответствующая?) часть статуса:

------------------------
LATEST DETECTED DEADLOCK
------------------------
110327 10:54:14
*** (1) TRANSACTION:
TRANSACTION 9FBA099E, ACTIVE 0 sec, process no 14207, OS thread id 1228433728 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 12505112, query id 909492800 juno....edu 129....54 wordpress_user updating
DELETE FROM wp_options WHERE option_name = ''_site_transient_timeout_theme_roots''
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 4951009 page no 4 n bits 384 index `option_name` of table `wordpress_work`.`wp_options` trx id 9FBA099E lock_mode X waiting
Record lock, heap no 309 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 30; hex 5f736974655f7472616e7369656e745f74696d656f75745f7468656d655f; asc _site_transient_timeout_theme_; (total 35 bytes);
1: len 8; hex 0000000000002b6d; asc       +m;;

*** (2) TRANSACTION:
TRANSACTION 9FBA0995, ACTIVE 0 sec, process no 14207, OS thread id 1230031168 starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1248, 2 row lock(s)
MySQL thread id 12505095, query id 909492789 juno....edu 129.....54 wordpress_user updating
DELETE FROM wp_options WHERE option_name = ''_site_transient_timeout_theme_roots''
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 4951009 page no 4 n bits 384 index `option_name` of table `wordpress_work`.`wp_options` trx id 9FBA0995 lock_mode X locks rec but not gap
Record lock, heap no 309 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 30; hex 5f736974655f7472616e7369656e745f74696d656f75745f7468656d655f; asc   _site_transient_timeout_theme_; (total 35 bytes);
 1: len 8; hex 0000000000002b6d; asc       +m;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 4951009 page no 4 n bits 384 index `option_name` of table     `wordpress_work`.`wp_options` trx id 9FBA0995 lock_mode X waiting
Record lock, heap no 309 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 30; hex 5f736974655f7472616e7369656e745f74696d656f75745f7468656d655f; asc   _site_transient_timeout_theme_; (total 35 bytes);
1: len 8; hex 0000000000002b6d; asc       +m;;

*** WE ROLL BACK TRANSACTION (1)

mysql deadlock
person ethrbunny    schedule 28.03.2011    source источник
comment
Но указанный запрос не отображается через «показать список процессов».   -  person ethrbunny    schedule 28.03.2011
comment
Я думаю, вам нужно убить соединение   -  person Joe Phillips    schedule 28.03.2011
comment
Это последняя обнаруженная взаимоблокировка, с которой уже разобрался mysql, следовательно, *** WE ROLL BACK TRANSACTION (1)   -  person KCD    schedule 12.12.2013

Ответы (3)


arrow_upward
27
arrow_downward

Учитывая некоторый вывод «innodb status», например:

---TRANSACTION 0 0, not started, process no 1024, OS thread id 140386055603968
MySQL thread id 197, query id 771 localhost marc
show innodb status

ты хотел бы сделать

KILL QUERY 771

чтобы убить один из двух запросов, которые зашли в тупик. Это убьет запрос, но оставит соединение открытым. если вы хотите разорвать соединение, вы должны сделать KILL 197.

person Marc B    schedule 28.03.2011
comment
Это должно быть show engine innodb status в более новых версиях mysql, у меня 5.6.10 и show innodb status недопустимая команда. - person Robin Clowers; 23.08.2013
comment
Я встречал похожую ситуацию. Дело не в синтаксисе команды show. Поскольку show processlist не показывает никакой связи, связанной с этими запросами, это означает, что эти тупиковые транзакции сохраняются на уровне механизма хранения, а не на уровне API MySQL. Единственный способ, который я нашел для решения подобных проблем, - перезапустить службу MySQL. - person Sender; 05.09.2013
comment
Вы должны убить «идентификатор потока MySQL», который в этом примере равен 197. - person witkacy26; 27.10.2015
comment
Этот ответ просто неверен. Обнаружение взаимоблокировки происходит мгновенно, и когда оно регистрируется, больше никаких действий не требуется. Раздел предназначен только для ознакомительных целей. - person jkavalik; 05.11.2015
comment
@jkavalik в некоторых редких случаях поток, удерживающий блокировку, может зависать на неопределенный срок и требует ручного уничтожения, прежде чем блокировка снова будет освобождена. Это не обычно происходит в тупиковой ситуации, но у меня такое случалось вдобавок к самой тупиковой ситуации. - person Mahn; 06.07.2021
comment
@Mahn при разрешении взаимоблокировки только одна из двух транзакций уничтожается, другая продолжает работу и все еще удерживает свои блокировки, поэтому имхо в случае, когда вы описываете, что транзакция выиграла разрешение взаимоблокировки, но затем зависает на чем-то другом или по какой-то другой причине. (возможно, там ошибка, но это кажется более вероятным) - person jkavalik; 06.07.2021

arrow_upward
14
arrow_downward

Используя «show engine innodb status», я вижу, что WordPress имеет две взаимоблокировки... Предложения о том, как решить эту проблему?

Мы наблюдали проблемы со спящим режимом Java, вызывающие зависание блокировки. Мы нашли замки, прочесав вывод из:

show engine innodb status;

Это выплевывает дерьмовую тонну информации. Соответствующий раздел находится в разделе TRANSACTIONS. В вашем выводе соответствующая проблема выглядит так:

3 lock struct(s), heap size 1248, 2 row lock(s)
MySQL thread id 12505095, query id 909492789 juno....edu 129.....54

Для нас это был # lock struct(s), указывающий на застрявший замок. Чтобы убить его, вам нужно выполнить, используя указанный идентификатор потока # - в этом случае:

kill 12505095

Это работало на AWS MySQL RDS, а также на локальном MySQL.

В нашем разделе ТРАНЗАКЦИИ мы также видим следующее:

---TRANSACTION 644793773, ACTIVE 21 sec
2 lock struct(s), heap size 360, 1 row lock(s)
MySQL thread id 217, OS thread handle 0x2aef097700, query id 1177 1.3.5.7 mpsp cleaning up

Мы ищем сообщения 2 lock struct(s) и ACTIVE 21 sec.

person Gray    schedule 08.09.2016

arrow_upward
8
arrow_downward

Я знаю, что это старо, но обычно, когда вы видите что-то подобное, это происходит из-за того, что возникла взаимоблокировка, и приложение, вызвавшее взаимоблокировку, уже давно ушло — жертва взаимоблокировки была предупреждена и либо потерпела неудачу, либо зарегистрировала ошибку, либо повторила попытку. , и в любом случае перешел к другим продуктивным вещам. Обычно вам не нужно ничего делать, кроме как выяснить причину взаимоблокировки и попытаться избежать будущих взаимоблокировок, если вы пишете программное обеспечение. Если вы просто используете программное обеспечение (например, Wordpress, если вы не работаете в Wordpress), вы можете сообщить о взаимоблокировке как о возможной ошибке.

person Geoffrey Wiseman    schedule 29.08.2012