Проблема с расшифровкой тупика в журнале состояния innodb

Мы обращаемся к MySQL из коннектора Microsoft ADO.NET.

Иногда мы видим следующую тупиковую ситуацию в нашем состоянии 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 получает строку B, а затем строку A. В этом случае это TX1, и TX2 являются доступ к одной и той же строке, но изменение двух разных столбцов (iphone_device_time, last_checkin).

Значения не имеют никакого смысла. В 5:24:42 ваша последняя регистрация была 5:35:07. Через десять минут и 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 является кластеризованным индексом в InnoDB, ключ PRIMARY и сама строка находятся вместе. Таким образом, прохождение строки и и ПЕРВИЧНЫЙ КЛЮЧ - это одно и то же. Следовательно, любая блокировка индекса на PRIMARY KEY также является блокировкой на уровне строк.

ОБНОВЛЕНИЕ 2011-06-06 19:21

Проверьте , что auocommit значение , которое вы имеете . Если автокоммит выключен, я вижу две (2) возможные проблемы

1. обновление одной и той же строки дважды в одной и той же транзакции
2. обновление одной и той же строки в двух разных транзакциях

На самом деле, СТАТУС SHOW ENGINE INNODB, который вы показываете в вопросе, имеет точно оба сценария.

Ответ Роландо, безусловно, помог нам найти правильное решение. Однако мы не в конечном счете настроить нашу автоматическую фиксацию конфигурации, наши уровни изоляции или innodb_locks_unsafe_for_binlog конфигурации.

Мы считаем, что журнал тупиков, который мы разместили по первому вопросу, является результатом тупика, который мы впоследствии обнаружили и разместили здесь . Поскольку мы решили проблему с этими двумя запросами, с тех пор мы не видели никаких тупиков.