Проблема розшифровки тупику в журналі статусу 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)

Ми читаємо цю статтю про наступне блокування ключа, але вона, схоже, не стосується нас, оскільки ми не робимо вибір для оновлення.

Оновлення

Сьогодні вранці я виявив дещо інший підпис тупикового зв'язку, який міг би бути першопричиною цього тупика. Я опублікував цей глухий кут як окреме питання, щоб все було просто. Я оновлю тут, якщо зможу підтвердити, що інше питання є причиною.

— RedBlueThing
джерело

Я оновив свою відповідь більшою пропускною здатністю та пропускною здатністю.

— RolandoMySQLDBA

Я оновив свою відповідь чимось про

— автокомісію

BTW Ви отримуєте +1 за це питання, оскільки такий тип запитань повинен тримати DBA на ногах.

— RolandoMySQLDBA

Відповіді:

Ось що я бачу

Я бачу три запити, всі майже однакові.

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. доступ до одного рядка, але зміна двох різних стовпців (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 (спільний замок) вказує на те, що два блоки були накладені (або намагаються накласти) в одному рядку. Можливо, відбудеться деяка внутрішня серіалізація, роблячи блокування наступного ряду. За замовчуванням вимкнено. Прочитавши це, можливо, вам доведеться розглянути можливість його включення.

ОНОВЛЕННЯ 2011-06-06 10:03

Ще однією причиною вивчення цієї лінії думки є той факт, що всі транзакції проходять через ПЕРВИЧНИЙ ключ. Оскільки PRIMARY - це кластерний індекс в InnoDB, ключ PRIMARY і сам рядок є разом. Таким чином, проходження ряду і ПЕРВИЧНИЙ КЛЮЧ - це одне і те саме. Тому будь-яке блокування індексу на ПЕРВИЧНОМ КЛЮЧІ також є блокуванням рівня рядків.

ОНОВЛЕННЯ 2011-06-06 19:21

Перевірте, яке значення аудіокомісії у вас є . Якщо автокомісія вимкнена, я бачу дві (2) можливі проблеми

оновлення того ж рядка двічі в одній транзакції
оновлення одного і того ж рядка у двох різних транзакціях

Насправді, ПОКАЗУЙТЕ СТАТУС ДЛЯ ДВИГАТЕЛЯ, який ви показуєте у запитанні, має саме обидва сценарії.

— RolandoMySQLDBA
джерело

Дякуємо за ваш внесок. Ми це також помітили. Мене бентежить, чому зміни в двох стовпцях в одному рядку можуть призвести до тупикового зв'язку.

— RedBlueThing

Дякуємо за ваші оновлення Щойно я перевірив наші налаштування і ввімкнено функцію автокомісії (тобто ми не змінили типовий режим).

— RedBlueThing

@RedBlueThing Перегляньте рівень ізоляції транзакцій (змінна - tx_isolation dev.mysql.com/doc/refman/5.5/uk/… ). Якщо ви не встановите це, за замовчуванням буде REPEATABLE-READ. можливо, в цій унікальній ситуації може допомогти інший рівень ізоляції транзакцій.

— RolandoMySQLDBA

Спасибі. Я перевірю це і повернуся до вас. Ще раз дякую за вашу наполегливість :)

— RedBlueThing

Я виявив різний глухий кут в наших журналах сьогодні вранці, який може пролити трохи світла на цю проблему. Я розмістив це як окреме питання, щоб все було просто. dba.stackexchange.com/questions/3223/…

— RedBlueThing

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

Ми вважаємо, що журнал тупикових ситуацій, який ми розмістили у цьому першому запитанні, є результатом тупикового туалету, який ми згодом знайшли та розмістили тут . Оскільки ми вирішили проблему з цими двома запитами, з тих пір ми не бачили жодних тупиків.

— RedBlueThing
джерело

Хоча я не зміг знайти рішення, я був радий, що можу допомогти !!!

— RolandoMySQLDBA

Дякую, що розглядали мої пропозиції та випадкові балачки MySQL (+1) !!!

— RolandoMySQLDBA

@RolandoMySQLDBA Немає проблем;) Дякую за допомогу.

— RedBlueThing