ปัญหาในการถอดรหัสการหยุดชะงักในบันทึกสถานะของ 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 ในกรณีนี้มันคือ 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 ของคุณ วลี lock_mode X (ล็อคแบบเอกสิทธิ์เฉพาะบุคคล) และ lock_mode S (ล็อคแบบแบ่งใช้) บ่งชี้ว่ามีการล็อคทั้งสองแบบ (หรือพยายามกำหนด) ในแถวเดียวกัน อาจมีการทำให้เป็นอันดับภายในบางอย่างเกิดขึ้นเมื่อทำการล็อคแถวถัดไป ค่าเริ่มต้นคือปิด หลังจากอ่านสิ่งนี้แล้วคุณอาจต้องพิจารณาเปิดใช้งาน

อัพเดท 2011-06-06 10:03

อีกเหตุผลหนึ่งในการตรวจสอบแนวความคิดนี้คือข้อเท็จจริงที่ว่าธุรกรรมทั้งหมดกำลังผ่านคีย์หลัก เนื่องจาก Primary เป็นดัชนีคลัสเตอร์ใน InnoDB คีย์หลักและแถวจึงอยู่ด้วยกัน ดังนั้นการข้ามแถวและคีย์หลักคือแบบเดียวกัน ดังนั้นการล็อกดัชนีใด ๆ ในคีย์หลักคือการล็อคระดับแถวเช่นกัน

อัพเดท 2011-06-06 19:21

ตรวจสอบสิ่งที่auocommitค่าที่คุณมี หากการเติมข้อความอัตโนมัติปิดอยู่ฉันสามารถเห็นปัญหาที่เป็นไปได้สอง (2) ข้อ

อัปเดตแถวเดียวกันสองครั้งในธุรกรรมเดียวกัน
อัปเดตแถวเดียวกันในธุรกรรมที่ต่างกันสองรายการ

ในความเป็นจริงสถานะ SHOW INNODB เครื่องยนต์ที่คุณแสดงในคำถามนั้นมีทั้งสองสถานการณ์

— RolandoMySQLDBA
แหล่งที่มา

ขอบคุณสำหรับข้อมูลของคุณ เราสังเกตเห็นเช่นกันว่า ฉันสับสนว่าทำไมการเปลี่ยนแปลงสองคอลัมน์ในแถวเดียวกันจึงทำให้เกิดการหยุดชะงัก

— RedBlueThing

ขอบคุณสำหรับการอัปเดตของคุณ ฉันเพิ่งตรวจสอบการตั้งค่าของเราและเปิดใช้งานการเติมข้อความอัตโนมัติ (เช่นเราไม่ได้เปลี่ยนค่าเริ่มต้น)

— RedBlueThing

@RedBlueThing โปรดดูระดับการแยกธุรกรรมของคุณ (ตัวแปรคือ tx_isolation dev.mysql.com/doc/refman/5.5/th/ เป็นต้น ) หากคุณไม่ได้ตั้งค่านี้ค่าเริ่มต้นคือ REPEATABLE-READ อาจเป็นไปได้ว่าระดับการแยกธุรกรรมที่แตกต่างกันอาจช่วยในสถานการณ์ที่ไม่ซ้ำกันนี้

— RolandoMySQLDBA

ขอบคุณ ฉันจะตรวจสอบเรื่องนั้นและกลับไปหาคุณ ขอบคุณอีกครั้งสำหรับการคงอยู่ของคุณ :)

— RedBlueThing

ฉันค้นพบการหยุดชะงักที่แตกต่างกันในบันทึกของเราเมื่อเช้านี้ซึ่งอาจทำให้เข้าใจถึงปัญหานี้ ฉันได้โพสต์ว่าเป็นคำถามแยกต่างหากเพื่อให้สิ่งต่าง ๆ ง่ายขึ้น dba.stackexchange.com/questions/3223/…

— RedBlueThing

คำตอบของRolandoนั้นมีประโยชน์อย่างมากในการพาเราไปสู่ทางออกที่ถูกต้อง แต่เราไม่ได้ในท้ายที่สุดเราปรับautocommitการกำหนดค่าระดับการแยกของเราหรือinnodb_locks_unsafe_for_binlogการกำหนดค่า

เราเชื่อว่าการเข้าสู่ระบบการหยุดชะงักที่เราโพสต์ในคำถามแรกนี้เป็นผลมาจากการหยุดชะงักต่อมาจึงได้พบและโพสต์ที่นี่ เนื่องจากเราแก้ไขปัญหาด้วยข้อความค้นหาทั้งสองนี้เราจึงไม่เห็นการหยุดชะงักใด ๆ ตั้งแต่นั้นมา

— RedBlueThing
แหล่งที่มา

แม้ว่าฉันไม่สามารถหาวิธีแก้ปัญหาได้ แต่ฉันก็ดีใจที่ได้ช่วย !!!

— RolandoMySQLDBA

ขอบคุณสำหรับการพิจารณาข้อเสนอแนะของฉันและ MySQL babblings แบบสุ่ม (+1) !!!

— RolandoMySQLDBA

@RolandoMySQLDBA ไม่มีปัญหา;) ขอบคุณสำหรับความช่วยเหลือ

— RedBlueThing