একটি ইনডোডাব স্থিতি লগতে অচলাবস্থাকে বোঝাতে সমস্যা

আমরা মাইক্রোসফ্ট ADO.NET সংযোগকারী থেকে মাইএসকিউএল অ্যাক্সেস করছি।

মাঝেমধ্যে আমরা আমাদের ইনডোডাব স্থিতিতে নিম্নলিখিত অচলাবস্থাটি দেখতে পাচ্ছি এবং সমস্যার কারণটি সনাক্ত করতে সক্ষম হইনি। দেখে মনে হচ্ছে লেনদেন (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

বিটিডাব্লু আপনি এই প্রশ্নের জন্য একটি +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

আইফোন_দেবী_কাল = '2011-06-06 05:24:42', সর্বশেষ_চেকিন = '2011-06-06 05:35:07'

লেনদেন 2

আইফোন_দেবা_কাল = '2011-06-06 05:35:09', সর্বশেষ_চেকিন = '2011-06-06 05:24:42'

দয়া করে লক্ষ্য করুন যে কলামের মানগুলি উল্টানো হয়েছে। সাধারণত, একটি অচলাবস্থা ঘটে যখন দুটি পৃথক লেনদেন দুটি টেবিল থেকে দুটি লক অ্যাক্সেস করে TX1 (লেনদেন 1) দিয়ে সারি এ এবং তারপরে সারি বি পাওয়া যায় যখন টিএক্স 2 সারি বি এবং তার পরে সারি এ পাচ্ছে এই ক্ষেত্রে, এটি টিএক্স 1 এবং টিএক্স 2 হয় একই সারিতে অ্যাক্সেস করা হলেও দুটি পৃথক কলাম পরিবর্তন করা হচ্ছে (আইফোন_দেখার সময়, শেষ_চেকিন)।

মানগুলি কোনও অর্থবোধ করে না। 5:24:42 এ, আপনার শেষ চেকিনটি 5:35:07 ছিল। দশ মিনিট এবং 27 সেকেন্ড পরে (5:35:07 - 05:24:42), কলাম মানগুলি বিপরীত হয়।

বড় প্রশ্নটি: টিএক্স 1 প্রায় 11 মিনিটের জন্য কেন ধরে রাখা হয় ???

এটি আসলে কোনও উত্তর নয়। এটি কেবল ব্যান্ডউইথ এবং আমার কাছ থেকে। আমি আশা করি এই পর্যবেক্ষণগুলি সাহায্য করবে।

আপডেট ২০১১-০6-০6 09:57

অনুগ্রহ করে এই লিঙ্কটি যা ইনডোড_ব্লকস_অনস্যাফ_ফর্ম_বিন্লগ সম্পর্কিত দেখুন : আমি যে কারণটি পড়ার পরামর্শ দিচ্ছি তা আপনার INNODB পরিস্থিতি প্রদর্শনে আমি অন্য কিছু দেখেছি। লক_মোড এক্স (এক্সক্লুসিভ লক) এবং লক_মোড এস (ভাগ করা লক) বাক্যাংশটি উভয় লককে একই সারিতে চাপিয়ে দেওয়া হয়েছে (বা চাপিয়ে দেওয়ার চেষ্টা করছে) indicates পরের সারিতে লক করা কিছু অভ্যন্তরীণ সিরিয়ালাইজেশন হতে পারে। ডিফল্ট অফ। এটি পড়ার পরে আপনার এটি সক্ষম করার বিষয়ে বিবেচনা করা প্রয়োজন।

আপডেট ২০১১-০6-০6 10:03

চিন্তার এই রেখাটি পরীক্ষা করার আরেকটি কারণ হ'ল সমস্ত লেনদেনগুলি মূল কীটি অনুসরণ করছে। যেহেতু প্রাথমিকটি ইনোডিবিতে একটি ক্লাস্টার্ড সূচক, তাই মূল কী এবং সারি নিজেই একসাথে রয়েছে। সুতরাং, একটি সারি অতিক্রম করে এবং প্রাথমিক কী এক এবং একই। সুতরাং, প্রাথমিক কীতে যে কোনও সূচক লকটিও একটি সারি স্তরের লক।

আপডেট ২০১১-০6-০6 ১৯:২১

আপনার কি অউকোমিট মান আছে তা পরীক্ষা করুন । যদি স্বতঃসীমা বন্ধ থাকে তবে আমি দুটি (২) সম্ভাব্য সমস্যা দেখতে পাচ্ছি

একই লেনদেনে দু'বার একই সারিকে আপডেট করা
দুটি ভিন্ন লেনদেনে একই সারিকে আপডেট করা

প্রকৃতপক্ষে, প্রশ্নটিতে আপনি যে ইঞ্জিন ইনোডব পরিস্থিতি দেখান তার ঠিক উভয় দৃশ্যাবলী রয়েছে।

— RolandoMySQLDBA
সূত্র

আপনার ইনপুট জন্য ধন্যবাদ। আমরা এটাও লক্ষ্য করেছি। আমি বিভ্রান্ত হয়েছি কেন একই সারিতে দুটি কলামে পরিবর্তনের ফলে একটি অচলাবস্থার সৃষ্টি হবে।

— রেড ব্লুথিং

আপনার আপডেটের জন্য ধন্যবাদ। আমি কেবলমাত্র আমাদের সেটিংস পরীক্ষা করেছি এবং স্বতঃবীক্ষণ চালু করা হয়েছে (যেমন আমরা ডিফল্টটি পরিবর্তন করি নি)।

— রেড ব্লুথিং

@ রেডব্লিউথিং দয়া করে আপনার লেনদেনের বিচ্ছিন্নতা স্তরটি দেখুন (পরিবর্তনশীলটি tx_isolation dev.mysql.com/doc/refman/5.5/en/… )) আপনি যদি এটি সেট না করে থাকেন তবে ডিফল্টটি হ'ল রিপিএটেবল-রিড। এটি সম্ভবত কোনও ভিন্ন লেনদেনের বিচ্ছিন্নতা স্তরটি এই অনন্য পরিস্থিতির সাথে সহায়তা করতে পারে।

— রোল্যান্ডোমাইএসকিউএলডিবিএ

ধন্যবাদ। আমি এটি পরীক্ষা করে আপনার কাছে ফিরে যাব to আপনার অধ্যবসায়ের জন্য আবার ধন্যবাদ :)

— রেড ব্লুথিং

আমি আজ সকালে আমাদের লগগুলিতে একটি পৃথক অচলাবস্থা আবিষ্কার করেছি যা এই সমস্যাটির জন্য কিছুটা আলোকপাত করতে পারে। বিষয়গুলি সহজ রাখতে একটি পৃথক প্রশ্ন হিসাবে আমি পোস্ট করেছি। dba.stackexchange.com/questions/3223/…

— রেড ব্লুথিং

রোল্যান্ডোর উত্তর অবশ্যই সঠিক সমাধানের পথে আমাদের পেতে সহায়ক ছিল। তবে আমরা শেষ পর্যন্ত আমাদের সমন্বয় করা হয়নি autocommit কনফিগারেশন, আমাদের বিচ্ছিন্নতা মাত্রা বা innodb_locks_unsafe_for_binlog কনফিগারেশন।

আমরা বিশ্বাস করি যে এই প্রথম প্রশ্নটিতে আমরা পোস্ট করা অচলাবস্থাটি পরবর্তীকালে আমরা এখানে খুঁজে পেয়েছি এবং পোস্ট করেছি সেই অচলাবস্থার ফলাফল । যেহেতু আমরা এই দুটি প্রশ্নের সাথে সমস্যার সমাধান করেছি, তখন থেকে আমরা কোনও অচলাবস্থা দেখিনি।

— RedBlueThing
সূত্র

যদিও আমি সমাধানটি সন্ধান করতে পারি নি, আমি খুশি হয়েছিলাম যে আমি সহায়তা করতে পারি !!!

— রোল্যান্ডোমাইএসকিউএলডিবিএ

আমার পরামর্শ এবং র্যান্ডম মাইএসকিউএল বাবলিংস (+1) বিবেচনা করার জন্য আপনাকে ধন্যবাদ !!!

— RolandoMySQLDBA

@ রোল্যান্ডোমাইএসকিউএলডিবিএ কোনও সমস্যা নেই;) সহায়তার জন্য ধন্যবাদ।

— রেড ব্লুথিং