Bir innodb durum günlüğünde bir kilitlenmenin deşifre edilmesi sorunu

MySQL'e Microsoft ADO.NET bağlayıcısından erişiyoruz.

Bazen innodb durumumuzda aşağıdaki kilitlenmeyi görüyoruz ve sorunun nedenini tespit edemedik. İşlem (2) aynı kilidi bekliyor ve tutuyor gibi mi görünüyor?

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

Bir sonraki tuş kilidi ile ilgili bu makaleyi okuduk , ancak güncelleme için seçimler yapmadığımız için bizim için geçerli görünmüyor.

Güncelleme

Bu sabah, bu kilitlenmenin temel nedeni olabilecek biraz farklı bir kilitlenme imzası buldum. Ben var ayrı bir soru olarak kilitlenme yayınlanmıştır şeyler basit tutmak için. Diğer sorunun neden olduğunu teyit edebilirsem burada güncelleyeceğim.

İşte gördüğüm şey

Üç sorgu görüyorum, neredeyse aynı.

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;

Farklılıklar

İŞLEM 1

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

İŞLEM 2

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

Lütfen sütun değerlerinin ters çevrildiğine dikkat edin. Normalde, iki farklı işlem iki tablodan TX1 (İşlem 1) A satırını ve sonra B satırını alırken TX2 B satırını ve sonra A satırını alırken iki kilide eriştiğinde bir kilitlenme oluşur. aynı satıra erişerek iki farklı sütunu değiştirerek (iphone_device_time, last_checkin).

Değerler bir anlam ifade etmiyor. 5:24:42 saatinde son check-ininiz 5:35:07 idi. On dakika 27 saniye sonra (5:35:07 - 05:24:42) sütun değerleri ters çevrilir.

Büyük soru şudur: TX1 neden neredeyse 11 dakika bekletiliyor ???

Bu gerçekten bir cevap değil. Bu sadece bant genişliği ve benden. Umarım bu gözlemler yardımcı olur.

GÜNCELLEME 2011-06-06 09:57

Lütfen innodb_locks_unsafe_for_binlog ile ilgili bu bağlantıya göz atın : Bunu okumanızı önermemin nedeni INNODB STATUS ekranınızda gördüğüm başka bir şey. Lock_mode X (özel kilit) ve lock_mode S (paylaşılan kilit) ifadesi, aynı satıra her iki kilidin de uygulandığını (veya empoze etmeye çalıştığını) belirtir. Bir sonraki sıra kilitlemesini yapmaya devam eden bazı dahili serileştirmeler olabilir. Varsayılan KAPALI değeridir. Bunu okuduktan sonra etkinleştirmeyi düşünmeniz gerekebilir.

GÜNCELLEME 2011-06-06 10:03

Bu düşünceyi incelemenin bir başka nedeni de tüm işlemlerin PRIMARY anahtarını geçmesidir. PRIMARY, InnoDB'de kümelenmiş bir dizin olduğundan, PRIMARY anahtarı ve satırın kendisi birlikte. Böylece, bir satır ve ve PRIMARY KEY geçiş bir ve aynıdır. Bu nedenle, PRIMARY KEY üzerindeki herhangi bir dizin kilidi de satır düzeyinde bir kilittir.

GÜNCELLEME 2011-06-06 19:21

Hangi auocommit değerine sahip olduğunuzu kontrol edin . Otomatik taahhüt kapalıysa, iki (2) olası sorun görüyorum

1. aynı işlemde aynı satırı iki kez güncelleme
2. aynı satırı iki farklı işlemde güncelleme

Aslında, soruda gösterdiğiniz SHOW ENGINE INNODB STATUS tam olarak her iki senaryoya da sahiptir.

Rolando'nın cevabı kesinlikle doğru çözüme giden yolda bize yardımcı oldu. Ancak sonuçta otomatik taahhüt yapılandırmamızı , yalıtım düzeylerimizi veya innodb_locks_unsafe_for_binlog yapılandırmasını ayarlamadık.

Bu ilk soruya gönderdiğimiz kilitlenme günlüğünün, daha sonra burada bulduğumuz ve yayınladığımız kilitlenme sonucu olduğuna inanıyoruz . Bu iki soruyla ilgili sorunu çözdüğümüz için, o zamandan beri herhangi bir kilitlenme görmedik.