Explication de l'interblocage Mysql nécessaire

J'ai reçu le journal de blocage suivant via "SHOW INNODB STATUS". Quelqu'un peut-il se soucier d'expliquer pourquoi la transaction a été abandonnée? Il semble que Transaction 2 conserve le verrou, mais est également bloqué en demandant le même verrou (à l'exception de la partie "en attente"), ce qui entraîne un blocage lorsque la transaction 1 l'exige également.Explication de l'interblocage Mysql nécessaire

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

Source

2009-12-05 BrainCore

La première étape consiste à déterminer ce que les deux requêtes sont:

SELECT api_key, complété, compute_units, créé, supprimé, drapeaux, func_name, group_id, nom d'hôte, is_meta, JID, l'étiquette, la langue , num_children, parent_ujid, priorité, process_id, redémarrant, état, type, uid, ujid, version wid des emplois où le statut = 'new' et is_meta = 0 ORDER BY priorité asc, JID asc FOR UPDATE

..et:

emploi MISE À JOUR état SET = 'fait' OÙ JID = 10099

Le premier est un SELECT, le second est un UPDATE. Mais la clé est le FOR UPDATE à la fin du SELECT, que j'ai souligné en gras.

La syntaxe FOR UPDATE est pour une lecture de verrouillage - vous pouvez read the documentation about it here. Le MySQL deadlock documentation suggère d'utiliser READ COMMITTED si vous rencontrez des problèmes de verrouillage comme ceux-ci.

SHOW INNODB STATUS walk through

Source

2009-12-05 08:19:59

Merci pour la réponse rapide. J'ai identifié les deux requêtes, et je vois cela pour les conflits de mise à jour avec la mise à jour. Ma question est plus comme suit: Pourquoi la requête UPDATE ne peut-elle pas se terminer? Sa transaction détient déjà le verrou approprié. De plus, READ COMMITTED n'est pas une solution possible car je ne peux pas avoir de résultats obsolètes à partir d'une requête SELECT. – BrainCore

@BrainCore: 'Les verrous définis par LOCK IN SHARE MODE et FOR UPDATE reads sont validés lorsque la transaction est validée ou annulée. –

@OMG Poneys: J'ai déjà vu cette affirmation dans le passé. Cela semble-t-il raisonnable? La transaction 2 a obtenu ces verrous "lock_mode X locks rec mais pas gap" sur la table. La transaction 1 attend alors sur les verrous "lock_mode X waiting" pour cette table, qui appartiennent à Transaction 2. La transaction 2 fait ensuite une autre requête qui nécessite "lock_mode X verrouille rec mais pas d'attente en attente" (attend un type de verrou réel?) . Puisqu'il a déjà ces verrous, pourquoi ne les utilise-t-il pas? Est-ce que ça devient "bloqué" derrière la requête de Transaction 1, ala file FIFO? – BrainCore

Je ne suis pas sûr à 100% mais je crois qu'ils ne sont pas « le même verrou ».

* (1) ATTENDANT CE CADENAS A ACCORDER: RECORD BLOCAGE espace id 0 page No 17549 de n bits 128 Indice PRIMARY de la table takeyourorder/jobs TRX id 0 479286429 Lock_Mode X attente de verrouillage enregistrement, tas n ° 61 REPERTOIRE PHYSIQUE: n_fields 26; format compact; information bits de 0

* (2) TIENT LE LOCK (S): RECORD BLOCAGE espace id 0 page No 17549 de n bits 128 Indice PRIMARY de la table takeyourorder/jobs TRX id 0 479286425 serrures Lock_Mode X rec mais pas vide verrouillage enregistrement , tas no 61 REPERTOIRE PHYSIQUE: n_fields 26; format compact; information bits de 0

* (2) ATTENDANT CE CADENAS A ACCORDER: RECORD BLOCAGE espace id 0 page No 17548 de n bits 144 Indice PRIMARY de la table takeyourorder/jobs TRX id 0 479286425 serrures Lock_Mode X rec mais pas espace d'attente Enregistrement serrure, tas n ° 73 DOSSIER PHYSIQUE: n_fields 26; format compact; infos les bits 0

Tx (2) occupe "tas n ° 61" de verrouillage de la fiche et est en attente de verrou d'enregistrement "tas n ° 73". Tx (1) attend "tas no 61". Le journal ne dit pas qui détient "tas n ° 73" mais peut-être que c'est juste une limitation de "SHOW ENGINE INNODB STATUS". Vous pouvez confirmer qu'un journal similaire sera généré par un simple scénario de blocage.

Source

2011-10-17 06:56:14 Toshiya

Explication de l'interblocage Mysql nécessaire

Répondre

Questions connexes