InnoDB दोन यंत्रणा एकत्र करते. MVCC साध्या SELECT ना lock न करता एक consistent snapshot वाचू देते, त्यामुळे readers कधीही writers ना block करत नाहीत. Locks writes चे रक्षण करतात: // row locks घेतात, आणि InnoDB REPEATABLE READ खाली phantoms रोखण्यासाठी (row + त्याच्या आधीचा gap) देखील वापरते.
UPDATEDELETESELECT ... FOR UPDATEDeadlock हे एक चक्र आहे: T1 lock A धरून ठेवतो आणि B हवे असते, तर T2 B धरून ठेवतो आणि A हवे असते. दोघांपैकी कोणीही पुढे जाऊ शकत नाही. InnoDB चक्र शोधते आणि एक transaction roll back करते (स्वस्त बळी) error 1213 सह, त्यामुळे दुसरे पूर्ण होते.
-- T1 -- T2
BEGIN; BEGIN;
UPDATE acct SET bal=bal-1 UPDATE acct SET bal=bal-1
WHERE id=1; -- locks row 1 WHERE id=2; -- locks row 2
UPDATE acct SET bal=bal+1 UPDATE acct SET bal=bal+1
WHERE id=2; -- waits for T2 WHERE id=1; -- waits for T1 => DEADLOCK
-- ERROR 1213: Deadlock found; transaction rolled back
WHERE index करा जेणेकरून InnoDB विशिष्ट rows lock करेल, ranges नाही किंवा (index शिवाय) प्रत्यक्षात scan केलेली प्रत्येक row नाही.SHOW ENGINE INNODB STATUS\G -- LATEST DETECTED DEADLOCK explains who waited on what
खऱ्या concurrency खाली, lock contention आणि deadlocks हेच scale होणारे database आणि अडकणारे database यांच्यातील फरक आहेत. Readers MVCC वापरतात (त्यामुळे ते block होत नाहीत), deadlocks अपेक्षित आणि retry करण्यायोग्य आहेत, आणि consistent lock ordering त्यातील बहुतेक रोखते — हे जाणणे नेमके तेच आहे जे senior on-call कामाची मागणी करते.
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या