È necessaria la spiegazione del deadlock Mysql

Ho ricevuto il seguente registro di deadlock tramite "SHOW INNODB STATUS". Qualcuno può preoccuparsi di spiegare perché la transazione è stata interrotta? Sembra che Transaction 2 trattiene il blocco, ma è bloccato anche richiedendo lo stesso blocco (eccetto per la parte "waiting"), che porta a un deadlock quando Transaction 1 lo richiede.È necessaria la spiegazione del deadlock Mysql

=====================================                                           
091205 6:25:01 INNODB MONITOR OUTPUT                                           
=====================================                                           
Per second averages calculated from the last 39 seconds                                       
----------                                                  
SEMAPHORES                                                  
----------                                                  
OS WAIT ARRAY INFO: reservation count 233826, signal count 229982                                    
Mutex spin waits 0, rounds 1569878, OS waits 4740                                        
RW-shared spins 517345, OS waits 227127; RW-excl spins 4390, OS waits 1945                                  
------------------------                                              
LATEST DETECTED DEADLOCK                                              
------------------------                                              
091205 6:19:35                                                 
*** (1) TRANSACTION:                                               
TRANSACTION 0 479286429, ACTIVE 0 sec, process no 17618, OS thread id 2963139472 fetching rows                             
mysql tables in use 1, locked 1                                             
LOCK WAIT 176 lock struct(s), heap size 11584                                         
MySQL thread id 330396, query id 97467367 64-71-26-218.static.wiline.com 64.71.26.218 autotaggeruser Sorting result                        
SELECT api_key,completed,compute_units,created,deleted,flags,func_name,group_id,hostname,is_meta,jid,label,language,num_children,parent_ujid,priority,process_id,restartable,status,type,uid,ujid,version,wid FROM jobs WHERE status='new' and is_meta=0 ORDER BY priority asc,jid asc FOR UPDATE                                
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:                                         
RECORD LOCKS space id 0 page no 17549 n bits 128 index `PRIMARY` of table `takeyourorder/jobs` trx id 0 479286429 lock_mode X waiting                
Record lock, heap no 61 PHYSICAL RECORD: n_fields 26; compact format; info bits 0                                
0: len 8; hex 800000000000277c; asc  '|;; 1: len 6; hex 00001c915499; asc  T ;; 2: len 7; hex 00000006e21e2a; asc  *;; 3: len 8; hex 8000000000000002; asc   ;; 4: len 8; hex 8000000000000845; asc  E;; 5: SQL NULL; 6: len 8; hex 8000000000002773; asc  's;; 7: len 1; hex 80; asc ;; 8: len 8; hex 8000000000000002; asc   ;; 9: len 16; hex 636f72656f66746865627261696e2d75; asc coreofthebrain-u;; 10: len 4; hex 80000eb8; asc  ;; 11: len 1; hex 01; asc ;; 12: len 30; hex 322e362e32202872656c6561736532362d6d61696e742c20417072203139; asc 2.6.2 (release26-maint, Apr 19;...(truncated); 13: len 30; hex 5f5f6d61696e5f5f2e3c6c616d6264613e206174203c737464696e3e3a31; asc __main__.<lambda> at <stdin>:1;; 14: len 5; hex 8000000001; asc  ;; 15: len 0; hex ; asc ;; 16: len 4; hex 80000000; asc  ;; 17: len 4; hex 80000005; asc  ;; 18: len 4; hex 4b19fb58; asc K X;; 19: len 4; hex 4b19fb77; asc K w;; 20: len 1; hex 07; asc ;; 21: len 1; hex 80; asc ;; 22: len 4; hex 80000000; asc  ;; 23: len 4; hex 80000000; asc  ;; 24: len 1; hex 80; asc ;; 25: len 4; hex 80001415; asc  ;;                            

*** (2) TRANSACTION: 
TRANSACTION 0 479286425, ACTIVE 0 sec, process no 17618, OS thread id 2971134864 starting index read, thread declared inside InnoDB 500 
mysql tables in use 1, locked 1                           
7 lock struct(s), heap size 1024, undo log entries 3                     
MySQL thread id 330430, query id 97467371 64-71-26-218.static.wiline.com 64.71.26.218 autotaggeruser Updating       
UPDATE jobs SET status='done' WHERE jid=10099                       
*** (2) HOLDS THE LOCK(S):                            
RECORD LOCKS space id 0 page no 17549 n bits 128 index `PRIMARY` of table `takeyourorder/jobs` trx id 0 479286425 lock_mode X locks rec but not gap 
Record lock, heap no 61 PHYSICAL RECORD: n_fields 26; compact format; info bits 0                    
0: len 8; hex 800000000000277c; asc  '|;; 1: len 6; hex 00001c915499; asc  T ;; 2: len 7; hex 00000006e21e2a; asc  *;; 3: len 8; hex 8000000000000002; asc   ;; 4: len 8; hex 8000000000000845; asc  E;; 5: SQL NULL; 6: len 8; hex 8000000000002773; asc  's;; 7: len 1; hex 80; asc ;; 8: len 8; hex 8000000000000002; asc   ;; 9: len 16; hex 636f72656f66746865627261696e2d75; asc coreofthebrain-u;; 10: len 4; hex 80000eb8; asc  ;; 11: len 1; hex 01; asc ;; 12: len 30; hex 322e362e32202872656c6561736532362d6d61696e742c20417072203139; asc 2.6.2 (release26-maint, Apr 19;...(truncated); 13: len 30; hex 5f5f6d61696e5f5f2e3c6c616d6264613e206174203c737464696e3e3a31; asc __main__.<lambda> at <stdin>:1;; 14: len 5; hex 8000000001; asc  ;; 15: len 0; hex ; asc ;; 16: len 4; hex 80000000; asc  ;; 17: len 4; hex 80000005; asc  ;; 18: len 4; hex 4b19fb58; asc K X;; 19: len 4; hex 4b19fb77; asc K w;; 20: len 1; hex 07; asc ;; 21: len 1; hex 80; asc ;; 22: len 4; hex 80000000; asc  ;; 23: len 4; hex 80000000; asc  ;; 24: len 1; hex 80; asc ;; 25: len 4; hex 80001415; asc  ;;                            

*** (2) WAITING FOR THIS LOCK TO BE GRANTED: 
RECORD LOCKS space id 0 page no 17548 n bits 144 index `PRIMARY` of table `takeyourorder/jobs` trx id 0 479286425 lock_mode X locks rec but not gap waiting 
Record lock, heap no 73 PHYSICAL RECORD: n_fields 26; compact format; info bits 0                      
0: len 8; hex 8000000000002773; asc  's;; 1: len 6; hex 00001c9151f5; asc  Q ;; 2: len 7; hex 800000003c0110; asc  < ;; 3: len 8; hex 8000000000000002; asc   ;; 4: len 8; hex 800000000000083d; asc  =;; 5: SQL NULL; 6: SQL NULL; 7: len 1; hex 81; asc ;; 8: len 8; hex 8000000000000002; asc   ;; 9: len 16; hex 636f72656f66746865627261696e2d75; asc coreofthebrain-u;; 10: len 4; hex 80000eb8; asc  ;; 11: len 1; hex 01; asc ;; 12: len 30; hex 322e362e32202872656c6561736532362d6d61696e742c20417072203139; asc 2.6.2 (release26-maint, Apr 19;...(truncated); 13: len 30; hex 5f5f6d61696e5f5f2e3c6c616d6264613e206174203c737464696e3e3a31; asc __main__.<lambda> at <stdin>:1;; 14: len 5; hex 8000000001; asc  ;; 15: len 0; hex ; asc ;; 16: len 4; hex 80000000; asc  ;; 17: len 4; hex 80000005; asc  ;; 18: len 4; hex 4b19fb58; asc K X;; 19: SQL NULL; 20: len 1; hex 02; asc ;; 21: len 1; hex 80; asc ;; 22: len 4; hex 80000014; asc  ;; 23: len 4; hex 80000000; asc  ;; 24: len 1; hex 80; asc ;; 25: SQL NULL;                                               

*** WE ROLL BACK TRANSACTION (1)

fonte

2009-12-05 BrainCore

Il primo passo è determinare quali sono le due domande sono:

SELEZIONA api_key, completato, compute_units, creati, cancellati, bandiere, func_name, group_id, hostname, is_meta, jid, etichetta, la lingua , num_children, parent_ujid, la priorità, process_id, riavviabile, status, tipo, uid, ujid, versione, wid DA posti di lavoro dove lo status = 'nuovo' e is_meta = 0 ORDER BY asc priorità, jid asc FOR UPDATE

..e quelle:

UPDATE lavori status = SET 'fatto' DOVE jid = 10099

Il primo è una SELECT, il secondo è un aggiornamento. Ma la chiave è la FOR UPDATE alla fine della SELECT, che ho sottolineato in grassetto.

La sintassi FOR UPDATE è per una lettura di blocco - è possibile read the documentation about it here. Il MySQL deadlock documentation suggerisce di utilizzare READ COMMITTED se si verificano problemi di blocco come questi.

SHOW INNODB STATUS walk through

fonte

2009-12-05 08:19:59

Grazie per la risposta rapida. Ho identificato le due query e lo vedo per i conflitti di aggiornamento con l'aggiornamento. La mia domanda è più simile alla seguente: Perché la query UPDATE non può essere completata? La sua transazione sta già tenendo il lucchetto appropriato. Inoltre, READ COMMITTED non è una soluzione possibile in quanto non è possibile ottenere risultati obsoleti da una query SELECT. – BrainCore

@BrainCore: 'I blocchi impostati da LOCK IN SHARE MODE e FOR UPDATE le letture vengono rilasciate quando la transazione viene confermata o ripristinata. –

@OMG Ponies: ho visto quell'affermazione innumerevoli volte in passato. Suona ragionevole: Transaction 2 ha ottenuto questi blocchi "lock_mode X lock rec ma non gap" sul tavolo. La transazione 1 attende quindi i blocchi "lock_mode X waiting" per quella tabella, che sono di proprietà di Transaction 2. Transaction 2 quindi esegue un'altra query che richiede "lock_mode X lock rec ma non gap waiting" (è in attesa di un tipo di blocco effettivo?) . Dal momento che ha già quelle serrature, perché non le usa solo? Si sta "bloccando" dietro la richiesta della Transaction 1, ala coda FIFO? – BrainCore

non sono sicuro al 100%, ma credo che non sono "lo stesso blocco".

* (1) in attesa di questo SERRATURA DA EROGARE: RECORD SERRATURE spazio id 0 pagina No 17549 n bit 128 indice PRIMARY di tabella takeyourorder/jobs TRX id 0 479.286.429 Lock_Mode X attesa serratura Record, mucchio no 61 RECORD FISICO: n_fields 26; formato compatto; Info bit 0

* (2) contiene il blocco (S): RECORD SERRATURE spazio id 0 pagina No 17549 n bit 128 indice PRIMARY di tabella takeyourorder/jobs TRX id 0 479286425 Lock_Mode X serrature rec ma non gap serratura Record , numero di heap 61 REGISTRAZIONE FISICA: n_fields 26; formato compatto; Info bit 0

* (2) in attesa di questo SERRATURA DA CONCESSO: RECORD SERRATURE spazio id 0 pagina No 17548 n bit 144 indice PRIMARY di tabella takeyourorder/jobs TRX id 0 479.286.425 Lock_Mode X serrature rec ma non gap attesa Record lock, heap no 73 REGISTRAZIONE FISICA: n_fields 26; formato compatto; informazioni bit 0

Tx (2) tiene "cumulo no 61" record lock ed è in attesa per "cumulo senza 73" record lock. Tx (1) sta aspettando "heap no 61". Il log non dice chi detiene "heap no 73" ma forse è solo una limitazione di "SHOW ENGINE INNODB STATUS". È possibile confermare che il registro simile verrà generato dallo scenario di deadlock semplice.

fonte

2011-10-17 06:56:14 Toshiya

È necessaria la spiegazione del deadlock Mysql

risposta

Problemi correlati