Mysql impasse explication nécessaire
J'ai reçu la suite de l'impasse journal par "SHOW INNODB STATUS". Quelqu'un peut-il soin d'expliquer pourquoi la transaction a été annulée? Il semble que l'Opération 2 est maintenant le verrou, mais il est aussi coincé demandant la même serrure (sauf pour le "en attente"), ce qui conduit à un blocage lors de la Transaction de 1 exige ainsi.
=====================================
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)OriginalL'auteur BrainCore | 2009-12-05
Vous devez vous connecter pour publier un commentaire.
La première étape est de déterminer ce que les deux requêtes sont:
..et:
La première est un choix, la deuxième est une mise à JOUR. Mais la clé est la
FOR UPDATEà la fin de la sélection, qui je l'ai souligné en gras.La
FOR UPDATEsyntaxe est pour un verrouillage en lecture, vous pouvez lire la documentation sur le sujet ici. Le MySQL impasse de la documentation suggestes à l'aide deREAD COMMITTEDsi vous rencontrez des problèmes de verrouillage comme celles-là.SHOW INNODB STATUS marcher à travers
set SERRURE EN MODE de PARTAGE et DE mise à JOUR les lectures sont libérés lorsque la transaction est validée ou annulée.
Poneys: j'ai vu que l'énoncé d'un nombre incalculable de fois dans le passé. Est-ce son raisonnable: Transaction 2 obtenu ces verrous "lock_mode verrous X rec mais pas de gap" sur la table. Opération 1 puis attend sur les serrures "lock_mode X en attente" pour que le tableau, qui sont la propriété de Transaction 2. Transaction 2 puis une autre requête qui nécessite "lock_mode verrous X rec, mais pas d'espace d'attente" (qui est en attente d'un réel de type de verrou?). Depuis, elle a déjà, ces verrous, pourquoi n'est-il pas juste de les utiliser? Est-ce être "coincé" derrière de Transaction 1 demande, ala file d'attente FIFO?
Exactement - Opération 2 est "coincé" derrière de Transaction 1 demande, la file d'attente FIFO.
OriginalL'auteur OMG Ponies
Je ne suis pas sûr à 100% mais je crois qu'ils ne sont pas "la même serrure".
Tx(2) détient des "tas 61" verrouillage d'enregistrement et est en attente de "tas n ° 73" verrouillage d'enregistrement. Tx(1) est en attente de "tas 61". Le journal ne dit pas qui détient des "tas n ° 73", mais peut-être que c'est juste une limitation de "MONTRER du MOTEUR INNODB STATUS".
Vous pouvez confirmer que le journal similaire sera généré par simple blocage.
OriginalL'auteur Toshiya