Mysql explicación de interbloqueo necesario

He recibido el siguiente registro de interbloqueo a través de "MOSTRAR ESTADO INNODB". ¿Alguien puede explicar por qué se canceló la transacción? Parece que la Transacción 2 mantiene el bloqueo, pero también está bloqueado solicitando el mismo bloqueo (excepto la parte "en espera"), lo que conduce a un punto muerto cuando la Transacción 1 lo requiere también.Mysql explicación de interbloqueo necesario

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

Fuente

2009-12-05 BrainCore

El primer paso es determinar lo que las dos consultas son:

SELECT api_key, terminado, compute_units, creado, eliminado, banderas, func_name, group_id, nombre de host, is_meta, JID, la etiqueta, el lenguaje , num_children, parent_ujid, prioridad, process_id, reiniciable, estado, el tipo de fluido, ujid, versión, wid DE puestos de trabajo donde el estado = 'nuevo' y is_meta = 0 ORDER BY ASC prioridad, asc JID DE ACTUALIZACIÓN

..y:

ACTUALIZACIÓN trabajos estado = SET 'hecho' DONDE JID = 10099

El primero es un SELECT, la segunda es una actualización. Pero la clave es FOR UPDATE al final de SELECT, que hice hincapié en negrita.

La sintaxis FOR UPDATE es para una lectura de bloqueo - puede read the documentation about it here. El MySQL deadlock documentation sugiere utilizar READ COMMITTED si se encuentra con problemas de bloqueo como estos.

SHOW INNODB STATUS walk through

Fuente

2009-12-05 08:19:59

Gracias por la respuesta rápida. Identifiqué las dos consultas, y veo que la actualización entra en conflicto con la actualización. Mi pregunta es más similar a lo siguiente: ¿Por qué no se puede completar la consulta de ACTUALIZAR? Su transacción ya tiene el bloqueo apropiado. Además, READ COMMITTED no es una solución posible ya que no puedo tener resultados obsoletos de una consulta SELECT. – BrainCore

@BrainCore: 'Los bloqueos establecidos por LOCK IN SHARE MODE y FOR UPDATE se publican cuando la transacción se confirma o se retrotrae. –

@OMG Ponies: He visto esa afirmación innumerables veces en el pasado. Suena razonable: la Transacción 2 obtuvo estos bloqueos "lock_mode X bloquea rec pero no gap" en la tabla. La transacción 1 espera en los bloqueos "lock_mode X waiting" para esa tabla, que son propiedad de Transaction 2. La transacción 2 luego realiza otra consulta que requiere "lock_mode X bloquea rec pero no espera brecha" (¿está esperando un tipo de bloqueo real?) . Como ya tiene esos bloqueos, ¿por qué no los usa? ¿Está "atrapado" detrás de la solicitud de la transacción 1, ala cola FIFO? – BrainCore

no estoy 100% seguro, pero creo que no son "la misma cerradura".

* (1) esperando este LOCK que se concederá: RECORD LOCKS espacio Identificación del 0 página No 17549 n bits 128 índice PRIMARY de mesa takeyourorder/jobs trx ID 0 479 286 429 Lock_Mode X esperando bloqueo de registro, montón no 61 REGISTRO FÍSICO: n_fields 26; formato compacto; Datos de bits de 0

* (2) mantiene el bloqueo (S): RECORD LOCKS espacio Identificación del 0 página No 17549 n bits 128 índice PRIMARY de mesa takeyourorder/jobs Identificación del trx 0 479286425 cerraduras Lock_Mode X REC pero no brecha bloqueo de registro , pila no 61 REGISTRO FÍSICO: n_campos 26; formato compacto; Datos de los bits 0

* (2) esperando este LOCK que se conceda: Registro BLOQUEOS espacio Identificación del 0 páginas hay 17548 N bits 144 Índice PRIMARY de mesa takeyourorder/jobs TRX ID 0 479 286 425 Lock_Mode X cerraduras rec pero no brecha de espera Registro bloqueo, pila no 73 REGISTRO FÍSICO: n_campos 26; formato compacto; Info bits de 0

Tx (2) sostiene "montón no 61" bloqueo de registro y está esperando "montón no 73" bloqueo de registro. Tx (1) está esperando "montón 61". El registro no dice quién tiene "heap no 73", pero tal vez es solo una limitación de "SHOW ENGINE INNODB STATUS". Puede confirmar que se generará un registro similar mediante un escenario de interbloqueo simple.

Fuente

2011-10-17 06:56:14 Toshiya

Mysql explicación de interbloqueo necesario

Respuesta

Cuestiones relacionadas