Si vous suivez une situation suivante, un bug dans mysql? SMP mercredi 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU / Linux P>
------------------------ LATEST DETECTED DEADLOCK ------------------------ 100125 4:24:41 *** (1) TRANSACTION: TRANSACTION 0 210510625, ACTIVE 155 sec, process no 28125, OS thread id 1243162944 starting index read mysql tables in use 1, locked 1 LOCK WAIT 5 lock struct(s), heap size 1216, undo log entries 1 MySQL thread id 162928579, query id 527252744 box22 172.16.11.105 user updating delete from user_grid_items where user_id = 669786974 and START_X = 45 and START_Y = 65 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210510625 lock_mode X locks rec but not gap waiting Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 0: len 8; hex 0000000027ec235e; asc ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc @ ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc ;; 9: len 1; hex 80; asc ;; *** (2) TRANSACTION: TRANSACTION 0 210505911, ACTIVE 555 sec, process no 28125, OS thread id 1184323904 starting index read, thread declared inside InnoDB 500 mysql tables in use 1, locked 1 5 lock struct(s), heap size 1216, undo log entries 1 MySQL thread id 162924258, query id 527252762 box22 172.16.11.105 user updating delete from user_grid_items where user_id = 669786974 and START_X = 45 and START_Y = 65 *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210505911 lock mode S locks rec but not gap Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 0: len 8; hex 0000000027ec235e; asc ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc @ ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc ;; 9: len 1; hex 80; asc ;; *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210505911 lock_mode X locks rec but not gap waiting Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 0: len 8; hex 0000000027ec235e; asc ' #^;; 1: len 4; hex 0000002d; asc -;; 2: len 4; hex 00000041; asc A;; 3: len 6; hex 00000b561243; asc V C;; 4: len 7; hex 80000040070110; asc @ ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc ;; 9: len 1; hex 80; asc ;; *** WE ROLL BACK TRANSACTION (2) ------------
3 Réponses :
Utilisez Afficher le moteur Innodb Statut pour déterminer le cause de la dernière impasse. Cela peut vous aider à accorder votre application pour éviter les blocages.
Soyez toujours prêt à ré-émettre une transaction si elle échoue en raison de l'impasse. Les blocages ne sont pas dangereux. Juste essayer à nouveau.
Ce n'est pas une réponse, mais plutôt une régurgitation de 14.2.7.9 Comment faire face à des blocages dans le manuel MySQL ( dev.mysql.com/doc/refman/5.0/fr/innodb-deadlocks.html ). Pire encore, cela ne fait rien pour répondre à la question de l'OP. Si j'avais le représentant pour indiquer cela, je le ferais.
Je lis quelque chose il y a longtemps, et je ne sais pas si vous voulez être ce que vous courez en conséquence ou non ... sans voir du code de la transaction du courant VS ce qu'il est en conflit avec.
Lors du traitement de vos transactions, vous devriez essayer de les faire bloquer toujours dans la même séquence ... pour un système de détail de commande / de commande / paiements, effectuez les activités dans l'ordre indiqué comme exemple ici pour tous. Si vous avez un autre processus qui essaie sa transaction par ordre de "détail de commande / ordre", qui peut provoquer une impasse.
Une transaction verrouille d'abord le numéro de commande, puis en fonctionnement de la commande. L'autre transaction verrouillait d'abord le détail de la commande, puis essayant d'obtenir l'en-tête de commande.
htth
Parfois, le statut InnoDB Moteur Show Moteur peut être difficile à déchiffrer, car il ne montre que l'instruction en cours dans la transaction. Il ne montre pas de déclarations survenues auparavant dans la même transaction qui auraient pu acquérir les verrous qui sont effectivement détenus.
Dans votre cas, une déclaration précédente dans la transaction 2 a acquis un verrou partagé sur la ligne en question.
Ensuite, la transaction 1 a tenté d'acquérir une serrure exclusive sur la même ligne et attend joyeusement que le verrou partagé soit supprimé.
Ensuite, la transaction 2, dans une autre déclaration, tenté d'acquérir une serrure exclusive sur la même ligne. Impasse classique. Aucune transaction ne peut finir.
Une solution pour aider à éviter une telle impasse serait de saisir une serrure exclusive de la ligne dans la transaction 2 avec un Sélectionner pour la mise à jour , avant l'instruction qui acquiert le verrou partagé.
Avez-vous pu trouver une solution à ce problème?
numéro similaire ici. Avez-vous trouvé une solution?
Les deux verrous requis sont différents (les modes sont différents, déjà attribué à verrouillage, le mode est partagé / lu et son attendant le verrouillage exclusif / écriture). Lire TPO Comprendre dev.mysql.com/doc/refman /5.0/fr/innodb-lock-modes.html
Donc, vous trouverez simplement une réponse à votre propre question et approuvez!