Очистить тупик транзакции?

Question

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

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

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

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

------------------------
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)

Answer 1

Учитывая некоторый вывод '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,

Answer 2

Используя '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 10177 1.3.5.7 mpsp cleaning up

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

Answer 3

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