web-dev-qa-db-ja.com

どうすればトランザクションのデッドロックを解消できますか？

「show engine innodb status」を使用すると、wordpressに2つのデッドロックがあることがわかります。これらを解消したいのですが、これらのコマンドのいずれかに対してアクティブなプロセスが表示されません（つまり、 「キル」し、うまくいけばロールバックを強制します）。

スレッドID、クエリIDなどを確認できますが、どちらのジョブも停止できません。

これを解決する方法についての提案？

編集：ここにステータスの（関連？）部分があります：

------------------------
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)
mysqldeadlock
17
ethrbunny

次のような '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

デッドロックされた2つのクエリの1つを強制終了します。クエリは強制終了されますが、接続は開いたままにしておきます。接続を強制終了したい場合は、KILL 197。

22
Marc B

「show engine innodb status」を使用すると、wordpressに2つのデッドロックがあることがわかります...これを解決する方法についての提案？

同様の問題を解決するのに役立つ情報をいくつか提供したいと思いました。 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)でした。これを強制終了するには、指定された「スレッドID＃」を使用して実行する必要があります-この場合：

_kill 12505095
_

これは、AWS MySQL RDSとローカルMySQLで機能しました。

TRANSACTIONSセクションには、以下も表示されます。

_---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_メッセージの両方を探します。

11
Gray -- SO stop being evil

私はこれが古いことを知っていますが、通常、このようなものが表示されるのは、デッドロックが発生し、デッドロックをトリガーしたアプリがずっと前に移動したためです-デッドロックの犠牲者は警告されて失敗したか、エラーを記録したか再試行しました、そしてどちらの方法も他の生産的なものに移行しました。ソフトウェアを作成している場合は、通常、デッドロックの原因を調べ、将来のデッドロックを回避する以外に何もする必要はありません。ソフトウェアを使用しているだけの場合（例Wordpress Wordpressで働いていない場合）、デッドロックをバグとして報告できます。

7
Geoffrey Wiseman