trigger et dump, référence à root

[DjinnS]

Bonsoir,

J'ai deux serveurs mysql 5.0 configurés en mater/master, derrière une VIP avec tout le tralalala heartbeat et mon. Ce "cluster" est utilisé par deux autres machines. Voila pour la première archi

J'ai dumpé une base sur le "cluster" via l'utilisateur root, depuis une machine du réseau (lamachine). J'ai donc un compte root@lamachine sur le "cluster". J'ai fait ça en root car je ne souhaitais pas donner le privilège SUPER à l'utilisateur, alors j'ai créé pour lui les trigger et procédures stockées.

J'ai fait un dump de cette base via mysqldump. Bizarrement, sans spécifier --trigger, j'ai les triggers dans le dump, mais bon, je vais pas m'en plaindre.

Voici mes options pour le dump:

Code :

--add-drop-table --add-locks

Lors de l'import de cette base, j'ai des messages d'erreurs qui remonte que l'utilisateur root@lamachine n'existe pas. Ce qui est normal ... Mais impossible de continuer l'import sans le rajouter ...

Dans le dump, j'ai des lignes de ce type (une au hasard):

Code :

/*!50003 CREATE */ /*!50017 DEFINER=`root`@`lautremachine` */ /*!50003 TRIGGER `tabx_DateCreation` BEFORE INSERT ON `gestionnaire` FOR EACH ROW SET NEW.DateCreation = CURRENT_TIMESTAMP, NEW.DateMAJ = CURRENT_TIMESTAMP */;;

Maintenant, sur un update d'une table qui a un trigger, j'ai la même erreur, il me dit que l'utilisateur n'existe pas pour root@lautremachine:

Code :

ERROR 1449 (HY000): There IS no 'root'@'lautremachine' registered

J'aimerais dans un premier temps comprendre pourquoi il y a une référence à l'utilisateur utilisé pour importer la base sur le "cluster". Mes connaissances sur les triggers mysql sont vraiment limités, et je n'ai pas trouvé d'information à ce sujet dans la documentation.

J'ai l'impression que le premier import sur le "cluster" a été "mal fait" et que je vais être obligé d'ajouter le compte root@lautremachine pour que ça marche.

Si quelqu'un a déjà rencontré le problème ou comprend ce qu'il se passe, son aide sera la bienvenue.

Merci d'avance.

[Antoun]

Pour ce qui est de mon expérience, le problème se pose y compris sur des config sans réplication, et quelle que soit la façon dont on fait le dump. La clause DEFINER= plante systématiquement ; la solution que j'ai utilisée consiste à supprimer cette clause à la main

[DjinnS]

Merci pour ton retour.

Bon, mon dump n'est pas énorme, 250Mo, mais ca fait quand même chier, si je peux me permettre, d'en arriver là.

Je fais faire quelques tests ce matin, j'ai eu quelques révélations cette nuit, si ça marche, j'en dirais plus

[Antoun]

Envoyé par DjinnS

Bon, mon dump n'est pas énorme, 250Mo, mais ca fait quand même chier, si je peux me permettre, d'en arriver là.

Une grosse chiasse ? Libérez-vous avec les regex !

[DjinnS]

Sortir l'artillerie des regex pour importer une base de données, oui, ça fait chier Je trouve la méthode, pour ma part, bien violente.

Voici les informations que j'ai pu tirer des mes recherches et les conclusions qui vont avec.

Lorsque l'objet est créé, par exemple dans mon cas un trigger, la référence à l'utilisateur ayant créé l'objet est mémorisé via le paramètre DEFINER. Lors du dump, ce paramètre est exporté. A noté qu'il est écrit dans la donc qu'il faut un --trigger pour faire le dump sauf que par défaut il semble être actif.

Lors de l'import, suivant les versions du moteur, ça pose ou non un problème. La solution que j'ai adopté consiste à ne pas modifier le dump mais à créer l'utilisateur en question. La modification du dump n'est pas une mauvaise solution, mais ça passe pour une base de 200Mo, ça sera peut être moins évident sur des grosses bases. En tout cas, cette solution ne me convient pas :p

Si l'utilisateur est créé lors de l'import pour qu'il n'échoue pas, la suite ne posera pas de problème. Sinon, il faudra aussi le créer pour pouvoir utiliser le trigger, sous n'importe quel utilisateur. J'entends par cela les utilisateurs ayant le droit par exemple de faire un update sur la table ou il y a un trigger sur l'update (de la colonne en question, toujours par exemple).

Une autre méthode consisterait à modifier le paramètre DEFINER du trigger. Mais comme il n'y a pas de ALTER TRIGGER sous la 5.0 (franchement, je sais pas ce qu'ils ont foutu les devs là ... mais bon ...), il faut le DROP et ensuite un CREATE. Lors du CREATE, pas besoin de spécifier le DEFINER, la valeur de l'utilisateur courant sera utilisé.

Je veux pas dire, mais pourquoi il n'y a pas d'option dans mysqldump pour omettre le DEFINER ? Sachant que je n'ai pas forcement les mêmes utilisateurs sur les bases (par exemple, dev, prod ...) avoir le DEFINER en dur, c'est chiant.

[Antoun]

Envoyé par DjinnS

Sortir l'artillerie des regex pour importer une base de données, oui, ça fait chier Je trouve la méthode, pour ma part, bien violente.

J'aime bien faire joujou avec les regex, donc ça ne me fait pas chier, mais sur le fond je suis d'accord sur l'usinagazitude du procédé.

Envoyé par DjinnS

(...)Lors de l'import, suivant les versions du moteur, ça pose ou non un problème. La solution que j'ai adopté consiste à ne pas modifier le dump mais à créer l'utilisateur en question. La modification du dump n'est pas une mauvaise solution, mais ça passe pour une base de 200Mo, ça sera peut être moins évident sur des grosses bases. En tout cas, cette solution ne me convient pas :p

C'est marrant, dans les tests que j'avais fait, le DEFINER plantait systématiquement, que l'utilisation existe ou non. Il faudra que je re-teste.

Envoyé par DjinnS

(...)
Une autre méthode consisterait à modifier le paramètre DEFINER du trigger. Mais comme il n'y a pas de ALTER TRIGGER sous la 5.0 (franchement, je sais pas ce qu'ils ont foutu les devs là ... mais bon ...), il faut le DROP et ensuite un CREATE.

Pas de ALTER, même pas de CREATE OR REPLACE... je crois qu'ils étaient très pressés

Envoyé par DjinnS

Je veux pas dire, mais pourquoi il n'y a pas d'option dans mysqldump pour omettre le DEFINER ?

Sans doute pour la même raison que l'absence d'ALTER...