Re: [HS] question aux spécialistes mysql

2011-12-02 Par sujet Thomas Clavier
Le 01/12/2011 22:20, Steven D a écrit :
 L'InnoDb gère le mode transactionnel.
 De faites à chaque update, ou insert la table est locké pour pas que
 d'autre requêtes n’interfère.

 Pour delocké la table, un unlock table suffit.

 Pour trouver d'où vient ton problème de départ, peux-tu nous donner
 plus de précision sur ta requête de départ.  

ça j'ai pas, surtout que si j'avais on pourrais corriger le problème à
la source ;-) un show full processlist quand le batch d'import plante ne
montre rien ... et en fait c'est normale.

Merci pour la piste, ce qui ce passe :
- le process d'import lock la table
- il plante et le lock n'est pas libéré

Je pensais qu'en rebootant mysql la file d'attente des lock serait
ré-initialisé ... mais non. Idem quand on drop la base, la file
d'attente des lock persiste. Il faut droper le user pour que les locks
posé par l'utilisateur soient supprimés. L'autre solution beaucoup
beaucoup plus simple c'est unlock de la table ... mais quand mysql nous
dit, la table n'existe pas difficile d'y penser :-)

-- 
Thomas Clavier http://www.tcweb.org
Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org
+33 (0)6 20 81 81 30   +33 (0)950 783 783




signature.asc
Description: OpenPGP digital signature


Re: [HS] question aux spécialistes mysql

2011-12-02 Par sujet Jean-Michel OLTRA

Bonjour,


Le vendredi 02 décembre 2011, Thomas Clavier a écrit...


 ça j'ai pas, surtout que si j'avais on pourrais corriger le problème à
 la source ;-) un show full processlist quand le batch d'import plante ne
 montre rien ... et en fait c'est normale.

 Merci pour la piste, ce qui ce passe :
 - le process d'import lock la table
 - il plante et le lock n'est pas libéré

 Je pensais qu'en rebootant mysql la file d'attente des lock serait
 ré-initialisé ... mais non. Idem quand on drop la base, la file
 d'attente des lock persiste. Il faut droper le user pour que les locks
 posé par l'utilisateur soient supprimés. L'autre solution beaucoup
 beaucoup plus simple c'est unlock de la table ... mais quand mysql nous
 dit, la table n'existe pas difficile d'y penser :-)

Pourrais tu faire un rollback lorsque le batch plante ? Quitte à mettre
des points d'arrêts (savepoints) peut-être si c'est possible, pour ne
pas tout rollback'er ?

-- 
jm

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20111202100344.GE2297@espinasse



Re: [HS] question aux spécialistes mysql

2011-12-02 Par sujet Thomas Clavier
Le 02/12/2011 11:03, Jean-Michel OLTRA a écrit :
 Pourrais tu faire un rollback lorsque le batch plante ? Quitte à mettre
 des points d'arrêts (savepoints) peut-être si c'est possible, pour ne
 pas tout rollback'er ?

L'évolution est en cours ... la bonne nouvelle c'est que ça ne plante
plus :)

-- 
Thomas Clavier http://www.tcweb.org
Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org
+33 (0)6 20 81 81 30   +33 (0)950 783 783




signature.asc
Description: OpenPGP digital signature


[HS] question aux spécialistes mysql

2011-12-01 Par sujet Thomas Clavier
Bonjour à tous et désolé pour le HS,

soit un insert en mass qui plante pour je ne sais pas trop quelle
raison, la table ma_table dans la base ma_base reste locké. Impossible
de relancer l'import. Ma table est en InnoDB.

Un second lancement me dit que que ma_base.ma_table n'existe pas (j'ai plus
le message exacte sous la main)

Pour débloquer j'ai testé :
- kill du script d'import
- relance de mysql
- mysqlcheck : il me répond que ma_base.ma_table n'existe pas 
- drop database ma_base + create database; puis chargement d'un dump de
sauvegarde : ERROR 1005 (HY000) at line 11643: Can't create table
'ma_base.ma_table' (errno: 121)
- drop database + drop user, puis create database + create user, puis
chargement du dump et la ça fonctionne.

Quelqu'un peut m'expliquer pourquoi il faut faire un drop du user pour
pouvoir recréer un objet dans une base toute neuve ?

pour info, la table en question c'est la table catalogsearch_result
d'un magento.

-- Thomas Clavier http://www.azae.net Jabber/XMPP/Gtalk :
tclav...@azae.net +33 (0)6 20 81 81 30

-- 
Thomas Clavier http://www.tcweb.org
Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org
+33 (0)6 20 81 81 30   +33 (0)950 783 783



signature.asc
Description: OpenPGP digital signature


Re: [HS] question aux spécialistes mysql

2011-12-01 Par sujet Guillaume

Le jeu. 01 déc. 2011 17:38:04 CET, Thomas Clavier a écrit :

 Bonjour à tous et désolé pour le HS,

soit un insert en mass qui plante pour je ne sais pas trop quelle
raison, la table ma_table dans la base ma_base reste locké. Impossible
de relancer l'import. Ma table est en InnoDB.

Un second lancement me dit que que ma_base.ma_table n'existe pas (j'ai plus
le message exacte sous la main)

Pour débloquer j'ai testé :
- kill du script d'import
- relance de mysql
- mysqlcheck : il me répond que ma_base.ma_table n'existe pas
- drop database ma_base + create database; puis chargement d'un dump de
sauvegarde : ERROR 1005 (HY000) at line 11643: Can't create table
'ma_base.ma_table' (errno: 121)
- drop database + drop user, puis create database + create user, puis
chargement du dump et la ça fonctionne.

Quelqu'un peut m'expliquer pourquoi il faut faire un drop du user pour
pouvoir recréer un objet dans une base toute neuve ?

pour info, la table en question c'est la table catalogsearch_result
d'un magento.

-- Thomas Clavier http://www.azae.net Jabber/XMPP/Gtalk :
tclav...@azae.net +33 (0)6 20 81 81 30



Tu peux donner les droits à une utilisateur uniquement sur une partie 
des tables d'une base. C'était peut-être le cas ?

Il aurait fallu faire les tests suivants pour répondre :
Quand tu avais le message indiquant qu'il n'y avait pas la table 
demandée, existait-elle bien ? Que donnait une insertion avec ton 
utilisateur ? Si elle échouait, que donnait l'insertion avec root ?


Bonne soirée,
Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4ed7d8ab.4010...@sfr.fr



Re: [HS] question aux spécialistes mysql

2011-12-01 Par sujet Steven D
L'InnoDb gère le mode transactionnel.
De faites à chaque update, ou insert la table est locké pour pas que
d'autre requêtes n’interfère.

Pour delocké la table, un unlock table suffit.

Pour trouver d'où vient ton problème de départ, peux-tu nous donner plus de
précision sur ta requête de départ.

Steven



Le 1 décembre 2011 20:42, Guillaume guillaume.lehm...@sfr.fr a écrit :

 Le jeu. 01 déc. 2011 17:38:04 CET, Thomas Clavier a écrit :

  Bonjour à tous et désolé pour le HS,

 soit un insert en mass qui plante pour je ne sais pas trop quelle
 raison, la table ma_table dans la base ma_base reste locké. Impossible
 de relancer l'import. Ma table est en InnoDB.

 Un second lancement me dit que que ma_base.ma_table n'existe pas (j'ai
 plus
 le message exacte sous la main)

 Pour débloquer j'ai testé :
 - kill du script d'import
 - relance de mysql
 - mysqlcheck : il me répond que ma_base.ma_table n'existe pas
 - drop database ma_base + create database; puis chargement d'un dump de
 sauvegarde : ERROR 1005 (HY000) at line 11643: Can't create table
 'ma_base.ma_table' (errno: 121)
 - drop database + drop user, puis create database + create user, puis
 chargement du dump et la ça fonctionne.

 Quelqu'un peut m'expliquer pourquoi il faut faire un drop du user pour
 pouvoir recréer un objet dans une base toute neuve ?

 pour info, la table en question c'est la table catalogsearch_result
 d'un magento.

 -- Thomas Clavier http://www.azae.net Jabber/XMPP/Gtalk :
 tclav...@azae.net +33 (0)6 20 81 81 30


 Tu peux donner les droits à une utilisateur uniquement sur une partie des
 tables d'une base. C'était peut-être le cas ?
 Il aurait fallu faire les tests suivants pour répondre :
 Quand tu avais le message indiquant qu'il n'y avait pas la table demandée,
 existait-elle bien ? Que donnait une insertion avec ton utilisateur ? Si
 elle échouait, que donnait l'insertion avec root ?

 Bonne soirée,
 Guillaume

 --
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/**FrenchListshttp://wiki.debian.org/fr/FrenchLists

 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers 
 debian-user-french-REQUEST@**lists.debian.orgdebian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/**4ed7d8ab.4010...@sfr.frhttp://lists.debian.org/4ed7d8ab.4010...@sfr.fr




Re: [HS] question aux spécialistes mysql

2011-12-01 Par sujet Jean-Yves F. Barbier
On Thu, 1 Dec 2011 22:20:07 +0100
Steven D ddebstu...@yahoo.fr wrote:

 L'InnoDb gère le mode transactionnel.
 De faites à chaque update, ou insert la table est locké pour pas que
 d'autre requêtes n’interfère.
 
 Pour delockER la table, un unlock table suffit.

Ou ptêt bin un COMMIT, histoire de refermer la transaction...

 Pour trouver d'où vient ton problème de départ, peux-tu nous donner plus de
 précision sur ta requête de départ.

-- 
If you want to know what god thinks of money, just look at the
people he gave it to.
-- Dorthy Parker

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20111201223247.3d98fcf4@anubis.defcon1