Rắc rối giải mã bế tắc trong nhật ký trạng thái innodb

Chúng tôi đang truy cập MySQL từ trình kết nối Microsoft ADO.NET.

Đôi khi, chúng ta đang thấy sự bế tắc sau đây trong tình trạng bẩm sinh của mình và không thể xác định được nguyên nhân của vấn đề. Có vẻ như giao dịch (2) đang chờ và giữ cùng một khóa?

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

Chúng tôi đọc bài viết này về khóa phím tiếp theo, nhưng dường như nó không áp dụng cho chúng tôi vì chúng tôi không chọn để cập nhật.

Cập nhật

Sáng nay tôi phát hiện ra một chữ ký bế tắc hơi khác có thể là nguyên nhân gốc rễ cho sự bế tắc này. Tôi đã đăng bế tắc đó như một câu hỏi riêng biệt để giữ cho mọi thứ đơn giản. Tôi sẽ cập nhật ở đây nếu tôi có thể xác nhận rằng câu hỏi khác là nguyên nhân.

Đây là những gì tôi đang thấy

Tôi thấy ba truy vấn, tất cả gần như giống hệt nhau.

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;

Sự khác biệt

GIAO DỊCH 1

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

GIAO DỊCH 2

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

Xin lưu ý rằng các giá trị cột được lật. Thông thường, bế tắc xảy ra khi hai giao dịch khác nhau đang truy cập hai khóa từ hai bảng với TX1 (Giao dịch 1) nhận hàng A và sau đó hàng B trong khi TX2 đang nhận hàng B và sau đó là hàng A. Trong trường hợp này, đó là TX1 và TX2 truy cập vào cùng một hàng nhưng thay đổi hai cột khác nhau (iphone_device_time, last_checkin).

Các giá trị không có ý nghĩa gì. Vào 5:24:42, lần đăng ký cuối cùng của bạn là 5:35:07. Mười phút và 27 giây sau (5:35:07 - 05:24:42), các giá trị cột bị đảo ngược.

Câu hỏi lớn là: Tại sao TX1 được giữ trong gần 11 phút ???

Đây không thực sự là một câu trả lời. Đây chỉ là băng thông và trong suốt từ tôi. Tôi hy vọng những quan sát này giúp.

CẬP NHẬT 2011-06-06 09:57

Vui lòng kiểm tra liên kết này liên quan đến innodb_locks_unsafe_for_binlog : Lý do tôi khuyên bạn nên đọc đây là một cái gì đó khác mà tôi đã thấy trong màn hình TÌNH TRẠNG TÌNH TRẠNG của bạn. Cụm từ lock_mode X (khóa độc quyền) và lock_mode S (khóa chung) cho biết cả hai khóa được áp đặt (hoặc cố gắng áp đặt) trên cùng một hàng. Có thể có một số tuần tự nội bộ đang diễn ra khóa hàng tiếp theo. Mặc định là TẮT. Sau khi đọc nó, bạn có thể cần phải xem xét kích hoạt nó.

CẬP NHẬT 2011-06-06 10:03

Một lý do khác để kiểm tra dòng suy nghĩ này là thực tế là tất cả các giao dịch đang đi qua khóa CHÍNH. Vì PRIMARY là một chỉ mục được nhóm trong InnoDB, khóa PRIMARY và chính hàng được đặt cùng nhau. Do đó, đi qua một hàng và KEY PRIMary là một và giống nhau. Do đó, bất kỳ khóa chỉ mục nào trên KEY PRIMARY cũng là khóa cấp hàng.

CẬP NHẬT 2011-06-06 19:21

Kiểm tra giá trị auocommit bạn có . Nếu chế độ tự động tắt, tôi có thể thấy hai (2) sự cố có thể xảy ra

1. cập nhật cùng một hàng hai lần trong cùng một giao dịch
2. cập nhật cùng một hàng trong hai giao dịch khác nhau

Trong thực tế, TÌNH TRẠNG SHOW Engine INNODB mà bạn hiển thị trong câu hỏi có chính xác cả hai kịch bản.

Câu trả lời của Rolando chắc chắn rất hữu ích trong việc đưa chúng ta đi đến giải pháp đúng đắn. Tuy nhiên, cuối cùng chúng tôi không điều chỉnh cấu hình tự động , mức cô lập hoặc cấu hình innodb_locks_unsafe_for_binlog .

Chúng tôi tin rằng nhật ký bế tắc mà chúng tôi đã đăng trong câu hỏi đầu tiên này là kết quả của sự bế tắc mà sau đó chúng tôi đã tìm thấy và đăng ở đây . Vì chúng tôi đã giải quyết vấn đề với hai truy vấn đó, chúng tôi chưa thấy bất kỳ bế tắc nào kể từ đó.