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)

다음 키 잠금에 대해서는 이 기사 를 읽었 지만 업데이트를 위해 선택하지 않기 때문에 적용되지 않는 것 같습니다.

최신 정보

오늘 아침에이 교착 상태의 근본 원인 인 약간 다른 교착 상태 서명을 발견했습니다. 나는 그 교착 상태를 간단하게 유지하기 위해 별도의 질문으로 게시했습니다 . 다른 질문이 원인임을 확인할 수 있으면 여기에서 업데이트하겠습니다.

여기 내가보고있는 것입니다

세 가지 쿼리가 거의 동일합니다.

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'

열 값이 뒤집혀 있습니다. 일반적으로 교착 상태는 두 개의 서로 다른 트랜잭션이 TX1 (트랜잭션 1)이 행 A를 받고 행 B를 가져 오는 동안 TX2 (행 1)가 행 B와 행 A를 갖는 두 테이블에서 두 개의 잠금에 액세스 할 때 발생합니다.이 경우 TX1과 TX2는 동일한 행에 액세스하지만 두 개의 다른 열 (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 STATUS 디스플레이에서 본 다른 이유입니다. lock_mode X (독점 잠금) 및 lock_mode S (공유 잠금)라는 문구는 동일한 행에서 두 잠금이 부과 (또는 부과하려고 함) 함을 나타냅니다. 다음 행 잠금을 수행하는 내부 직렬화가있을 수 있습니다. 기본 설정은 OFF입니다. 이 내용을 읽은 후에는 사용하도록 설정해야합니다.

업데이트 2011-06-06 10:03

이 사고 방식을 조사하는 또 다른 이유는 모든 거래가 PRIMARY 키를 통과하고 있다는 사실입니다. PRIMARY는 InnoDB의 클러스터형 인덱스이므로 PRIMARY 키와 행 자체가 함께 있습니다. 따라서 행 순회 및 기본 키는 하나이며 동일합니다. 따라서 PRIMARY KEY의 인덱스 잠금도 행 수준 잠금입니다.

업데이트 2011-06-06 19:21

가지고 있는 auocommit 값을 확인하십시오 . 자동 커밋이 해제되어 있으면 가능한 두 가지 문제를 볼 수 있습니다

1. 같은 트랜잭션에서 같은 행을 두 번 업데이트
2. 두 개의 다른 트랜잭션에서 동일한 행을 업데이트

실제로 질문에 표시하는 엔진 INNODB 상태 표시에는 두 가지 시나리오가 모두 있습니다.

Rolando 의 답변은 우리가 올바른 솔루션으로 나아가는 데 도움이되었습니다. 그러나 궁극적으로 자동 커밋 구성, 격리 수준 또는 innodb_locks_unsafe_for_binlog 구성 은 조정하지 않았습니다 .

우리는이 첫 번째 질문에 게시 한 교착 상태 로그가 이후에 찾아서 여기에 게시 한 교착 상태의 결과라고 생각합니다 . 이 두 쿼리의 문제를 해결 한 이후 교착 상태는 발견되지 않았습니다.