Bonjours,
je travaille sur un relativement gros site d'e-commerce, et on a un énorme pb!
tout d'abors le contexte :
- le code n'a pas ete changé depuis hier
- seule la taille des données stockée en base a (forcement augmanté)
maintenant, le pb :
- soudainement, est apparut le bug suivant (en production!)
l'appel a la procedure stockée suivante :
provoque l'erreur suivante :
Code : Sélectionner tout - Visualiser dans une fenêtre à part creerCaddie( <params> );
voici le code de la proc sto :Lock wait timeout exceeded;
nous avons eu ce pb durant plussieures heures, le seul moyen de le resorber etait de redémarrer le serveur MySQL. Mais il reaparaissait.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11 DELIMITER $$; CREATE DEFINER=`user`@`%` PROCEDURE `creerCaddie`( <params> ) BEGIN SET AUTOCOMMIT=0; START TRANSACTION; INSERT INTO Caddie ( <tables> ) VALUES ( <ParamEntree> ); COMMIT; SELECT LAST_INSERT_ID() as panierid; END$$ DELIMITER ;$$
il a disparut tout seul, depuis, nous avons supprimés la transaction inutile.
le code de la procedure stockée etait fonctionnel et inchangé depuis janvier.
Mon intérogation est la suivante :
apres renseignements sur internet, avec innoDB, seules les row liés a des requetes d'insert / update sont lockés dans la/les table concernée.
donc, comment un insert / update peut etre bloqué par une transaction qui, de plus, effectue bien un commit a sa fin ??
la table concerné fait 5.5Mo, avec 10Mo d'indexes, et compte ~30 000 enregistrements. ca ne me semble pas enorme...
elle possede en outre 2 foreign key pointants vers des tables relativement plus legeres.
la resultante de ce bug est que toute reservation est impossible lorsqu'il survient!
si quelqu'un a une piste... :'(
edit : sous mySQL Administrator, on pouvait voir des threads d'ecriture sur cette table en attente lorsque le bug survenait, leut etat etait 'locked'
Partager