web-dev-qa-db-ja.com

innodbステータスログのデッドロックを解読できない

Microsoft ADO.NETコネクタからMySQLにアクセスしています。

ときどき、innodbステータスで次のデッドロックが発生し、問題の原因を特定できません。トランザクション（2）が同じロックを待って保持しているように見えますか？

------------------------
LATEST DETECTED DEADLOCK
------------------------
110606  5:35:09
*** (1) TRANSACTION:
TRANSACTION 0 45321452, ACTIVE 0 sec, OS thread id 3804 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 368, 1 row lock(s)
    MySQL thread id 84, query id 3265713 localhost 127.0.0.1 famdev Updating
    UPDATE people SET company_id = 1610, name = '<name>', password = '<hash>', temp_password = NULL, reset_password_hash = NULL, email = '<redacted>@yahoo.com', phone = NULL, mobile = '<phone>', iphone_device_id = 'Android:<id>-<id>', iphone_device_time = '2011-06-06 05:35:09', last_checkin = '2011-06-06 05:24:42', location_lat = <lat>, location_long = -<lng>, gps_strength = 3296, picture_blob_id = 1190, authority = 1, active = 1, date_created = '2011-04-13 20:21:20', last_login = '2011-06-06 05:35:09', panic_mode = 0, battery_level = NULL, battery_state = NULL WHERE people_id = 3125
    *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
    RECORD LOCKS space id 0 page no 11144 n bits 152 index `PRIMARY` of table `family`.`people` trx id 0 45321452 lock_mode X locks rec but not gap waiting
    Record lock, heap no 12 PHYSICAL RECORD: n_fields 25; compact format; info bits 0
    0: len 8; hex 8000000000000c35; asc        5;; 1: len 6; hex 000002b38ce6; asc       ;; 2: len 7; hex 00000002801f89; asc        ;; 3: len 8; hex 800000000000064a; asc        J;; 4: len 4; hex <data>; asc <name>;; 5: len 30; hex <data>; asc <data>;...(truncated); 6: SQL NULL; 7: SQL NULL; 8: len 16; hex <data>; asc <redacted>@yahoo.com;; 9: SQL NULL; 10: len 10; hex <data>; asc <phone>;; 11: len 30; hex <data>; asc Android:<id>;...(truncated); 12: len 8; hex <data>; asc    J]  Z;; 13: len 8; hex <data>; asc    J]  Z;; 14: len 8; hex a39410acaa9b4340; asc       C@;; 15: len 8; hex <data>; asc     m S ;; 16: len 2; hex 8ce0; asc   ;; 17: len 8; hex 80000000000004a6; asc         ;; 18: len 4; hex 80000001; asc     ;; 19: len 1; hex 81; asc  ;; 20: len 8; hex <data>; asc    JR   ;; 21: len 8; hex <data>; asc    J]   ;; 22: len 1; hex 80; asc  ;; 23: SQL NULL; 24: SQL NULL;

    *** (2) TRANSACTION:
    TRANSACTION 0 45321448, ACTIVE 0 sec, OS thread id 3176 starting index read, thread declared inside InnoDB 500
    mysql tables in use 1, locked 1
    5 lock struct(s), heap size 1216, 2 row lock(s), undo log entries 1
    MySQL thread id 85, query id 3265714 localhost 127.0.0.1 famdev Updating
    UPDATE people SET company_id = 1610, name = '<name>', password = '<hash>', temp_password = NULL, reset_password_hash = NULL, email = '<redacted>@yahoo.com', phone = NULL, mobile = '<phone>', iphone_device_id = 'Android:<id>-<id>-<id>-<id>', iphone_device_time = '2011-06-06 05:24:42', last_checkin = '2011-06-06 05:35:07', location_lat = <lat>, location_long = -<lng>, gps_strength = 3296, picture_blob_id = 1190, authority = 1, active = 1, date_created = '2011-04-13 20:21:20', last_login = '2011-06-06 05:35:09', panic_mode = 0, battery_level = NULL, battery_state = NULL WHERE people_id = 3125
    *** (2) HOLDS THE LOCK(S):
        RECORD LOCKS space id 0 page no 11144 n bits 152 index `PRIMARY` of table `family`.`people` trx id 0 45321448 lock mode S locks rec but not gap
        Record lock, heap no 12 PHYSICAL RECORD: n_fields 25; compact format; info bits 0
        0: len 8; hex 8000000000000c35; asc        5;; 1: len 6; hex 000002b38ce6; asc       ;; 2: len 7; hex 00000002801f89; asc        ;; 3: len 8; hex 800000000000064a; asc        J;; 4: len 4; hex <data>; asc <name>;; 5: len 30; hex <data>; asc <data>;...(truncated); 6: SQL NULL; 7: SQL NULL; 8: len 16; hex <data>; asc <redacted>@yahoo.com;; 9: SQL NULL; 10: len 10; hex <data>; asc <phone>;; 11: len 30; hex <data>; asc Android:<id>;...(truncated); 12: len 8; hex <data>; asc    J]  Z;; 13: len 8; hex <data>; asc    J]  Z;; 14: len 8; hex a39410acaa9b4340; asc       C@;; 15: len 8; hex <data>; asc     m S ;; 16: len 2; hex 8ce0; asc   ;; 17: len 8; hex 80000000000004a6; asc         ;; 18: len 4; hex 80000001; asc     ;; 19: len 1; hex 81; asc  ;; 20: len 8; hex <data>; asc    JR   ;; 21: len 8; hex <data>; asc    J]   ;; 22: len 1; hex 80; asc  ;; 23: SQL NULL; 24: SQL NULL;

        *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
        RECORD LOCKS space id 0 page no 11144 n bits 152 index `PRIMARY` of table `family`.`people` trx id 0 45321448 lock_mode X locks rec but not gap waiting
        Record lock, heap no 12 PHYSICAL RECORD: n_fields 25; compact format; info bits 0
        0: len 8; hex 8000000000000c35; asc        5;; 1: len 6; hex 000002b38ce6; asc       ;; 2: len 7; hex 00000002801f89; asc        ;; 3: len 8; hex 800000000000064a; asc        J;; 4: len 4; hex <data>; asc <name>;; 5: len 30; hex <data>; asc <data>;...(truncated); 6: SQL NULL; 7: SQL NULL; 8: len 16; hex <data>; asc <redacted>@yahoo.com;; 9: SQL NULL; 10: len 10; hex <data>; asc <phone>;; 11: len 30; hex <data>; asc Android:<id>;...(truncated); 12: len 8; hex <data>; asc    J]  Z;; 13: len 8; hex <data>; asc    J]  Z;; 14: len 8; hex a39410acaa9b4340; asc       C@;; 15: len 8; hex <data>; asc     m S ;; 16: len 2; hex 8ce0; asc   ;; 17: len 8; hex 80000000000004a6; asc         ;; 18: len 4; hex 80000001; asc     ;; 19: len 1; hex 81; asc  ;; 20: len 8; hex <data>; asc    JR   ;; 21: len 8; hex <data>; asc    J]   ;; 22: len 1; hex 80; asc  ;; 23: SQL NULL; 24: SQL NULL;

        *** WE ROLL BACK TRANSACTION (1)

次のキーロックについて この記事 を読みましたが、更新の選択を行っていないため、適用されないようです。

更新

今朝、私はこのデッドロックの根本的な原因である可能性があるわずかに異なるデッドロック署名を発見しました。私は デッドロックを別の質問として投稿しました 物事を簡単に保つために持っています。他の質問が原因であることが確認できたら、こちらで更新します。

mysqlinnodbdeadlockado.net
16
RedBlueThing

Rolando の答えは確かに私たちを正しい解決策へと導くのに役立ちました。ただし、最終的に autocommit 構成、分離レベル、または innodb_locks_unsafe_for_binlog 構成を調整しませんでした。

この最初の質問に投稿したデッドロックログは、後で見つけて投稿したデッドロックの結果であると信じています here 。これら2つのクエリで問題を解決したため、それ以降デッドロックは発生していません。

1
RedBlueThing

これが私が見ているものです

3つのクエリがあり、すべてほぼ同じです。

UPDATE people SET company_id = 1610, name = '<name>', password = '<hash>',
temp_password = NULL, reset_password_hash = NULL, email = '<redacted>@yahoo.com',
phone = NULL, mobile = '<phone>', iphone_device_id = 'Android:<id>-<id>',
iphone_device_time = '2011-06-06 05:35:09', last_checkin = '2011-06-06 05:24:42',
location_lat = <lat>, location_long = -<lng>, gps_strength = 3296,
picture_blob_id = 1190,authority = 1, active = 1,
date_created = '2011-04-13 20:21:20',
last_login = '2011-06-06 05:35:09', panic_mode = 0, battery_level = NULL,
battery_state = NULL WHERE people_id = 3125;

違い

トランザクション1

iphone_device_time = '2011-06-06 05：24：42'、last_checkin = '2011-06-06 05:35:07'

トランザクション2

iphone_device_time = '2011-06-06 05：35：09'、last_checkin = '2011-06-06 05:24:42'

列の値が反転していることに注意してください。通常、2つの異なるトランザクションが2つのテーブルから2つのロックにアクセスし、TX1（トランザクション1）が行A、次に行Bを取得しているときにデッドロックが発生しますが、TX2は行B、次に行Aを取得します。この場合、TX1とTX2は同じ行にアクセスするが2つの異なる列を変更する（iphone_device_time、last_checkin）。

値は意味がありません。 5:24:42の最終チェックインは5:35:07でした。 10分27秒後（5:35:07-05:24:42）、列の値が逆になります。

大きな問題は、なぜTX1がほぼ11分間保持されるのかということです。

これは本当に答えではありません。これは単なる帯域幅であり、私にとっては全体です。これらの観察がお役に立てば幸いです。

更新2011-06-06 09:57

innodb_locks_unsafe_for_binlogに関するこのリンクを確認してください ：これを読むことをお勧めする理由は、INNODBステータス表示で他に見たものです。 lock_mode X（排他ロック）およびlock_mode S（共有ロック）というフレーズは、両方のロックが同じ行に課されている（または課そうとしている）ことを示しています。次の行のロックを行う内部シリアル化が行われている可能性があります。デフォルトはオフです。これを読んだ後、それを有効にすることを検討する必要があるかもしれません。

更新2011-06-06 10:03

この考え方を検討するもう1つの理由は、すべてのトランザクションがPRIMARYキーを通過しているという事実です。 PRIMARYはInnoDBのクラスター化インデックスであるため、PRIMARYキーと行自体は一緒になっています。したがって、行とPRIMARY KEYをトラバースすることはまったく同じです。したがって、PRIMARY KEYのインデックスロックは、行レベルのロックでもあります。

アップデート2011-06-06 19:21

auocommit の値を確認します。自動コミットがオフの場合、2つの問題が発生する可能性があります

  1. 同じトランザクションで同じ行を2回更新する
  2. 2つの異なるトランザクションで同じ行を更新する

実際、質問で表示するSHOW ENGINE INNODB STATUSには、両方のシナリオがあります。

6
RolandoMySQLDBA