You are not logged in.
Bonjour,
après plusieurs test (validés) de migration de ma version 0.72 vers la 0.84, j'ai décidé de faire le grand saut ce mois d'août.
Le scenario: migration vers la 0.78 (migration du plugin validation) puis migration vers la 0.84.
Mes tests se basaient toujours sur ma base de prod montée sur un serveur de test, copie exact de mon serveur de prod (machines vmware)
Je partais donc confiant sauf que.... ca ne fonctionne pas (je dirai même ca ne fonctionne plus).
Dans la phase de migration, pas de problème jusqu'à la phase d'upgrade vers la 0.78 et là ça bloque sans aucun message d'erreur, sans trace dans le php-errors.log et dans le sql-errors.log.
Voici ce qui s'affiche à l'écran:
"
Mise à jour
Connexion à la base de données réussie
Mise à jour -> 0.72.1
Traitement terminé. (0 Sec(s))
Mise à jour -> 0.72.2
Traitement terminé. (0 Sec(s))
Mise à jour -> 0.72.3
Traitement terminé. (0 Sec(s))
Mise à jour -> 0.78
Modification du schéma - Clean DB : update text fields (1 Sec(s))
"
J'ai fait plusieurs tentatives en repartant de ma sauvegarde valide mais sans succès.
Je désespère. J'ai pour objectif de migrer au mois d'août.
Merci de toute aide.
Last edited by pchauvin (2012-08-07 15:39:56)
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Je viens de faire une nouveau test:
j'ai, sur le même serveur, créé une nouvelle base glpi en version 0.72, vierge donc.
j'ai pu ainsi comparer la structure de cette base 0.72 toute neuve avec ma base de prod 0.72. J'ai supprimé tous les plugins de ma base de prod et fait ensuite le ménage de qques tables backup pour que ma structure de base de prod soit indentique avec la vierge.
J'ai ensuite effectué la migration en 0.78.5 sur de la base vierge sans soucis.
Mais la migration de la base de prod pose toujours le même soucis.
Cela vient donc soit de la structure d'une ou plusieurs tables qui diffèrerait de celles de la base vierge, soit de données posant problème.
Je vais essayer de repérer des différences de structure de table pour commencer. Je suis bien évidemment preneur de tout conseil.
Merci
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
En copiant la structure seule de base de prod (+les donnés de glpi_config) vers une nouvelle base, la migration de la nouvelle base en 0.78 est OK
Si je copie l'ensemble des données, le problème itinial se produit.
Cela semble donc bien venir des données.
Une idée?
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Je viens de voir ce topic qui semble évoquer le même problème que moi.
http://www.glpi-project.org/forum/viewt … p?id=21799
J'ai modifié les php.ini en conséquence (/etc/php5/apache2/php.ini et /etc/php5/cli/php.ini)
J'ai relancé une migration. Ca fait déjà 10min et toujours le même blocage à l'écran.
Comment peut-on vérifier si ca bosse vraiment?
En tout cas, je suis sceptique quant à cette solution puisque dans mon environnement de test (= à la prod), j'avais déjà plusieurs fois effectué cette migration sans soucis...
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
J'ai laissé la fenêtre de migration dans l'état toute la nuit: rien n'a bougé.
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Tu n'a aucun message d'erreur dans les logs de GLPI et/ou d'apache?
Offline
Et bien non justement, et c'est bien ça qui m'embête.
Ceci dit, je n'ai paut être pas regarder dans tous les logs. Peux-tu m'indiquer les fichiers de logs à regarder?
J'ai déjà regardé php-errors.log et sql-errors.log dans les logs GLPI.
Merci
Last edited by pchauvin (2012-08-08 12:36:18)
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
rien non plus dans le /var/log/apache2/error.log
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
En fait, a partir du moment ou je lance la migration, plus aucune activité sur le serveur n'est observé après 30 secondes seulement à peine.
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Humm là c'est un peu difficile à voir ce qu'il se passe si t'as pas de logs
Offline
Merci pour tes réponses.
Ceci dit, ca ne me rassure pas. S'il m'est impossible de migrer, c'est la mort assuré de GLPI dans ma société, ce que je regretterai vraiment.
Question bête: tu ferai quoi à ma place?
Merci
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
avez-vous essayé le script de migration en ligne de commande ? (tools/cliupdate.php)
Offline
Au pire du pire envoyer un dump de ta base à un des dev pour regarder ce qui se passe
Offline
Merci pour vos réponses,
Wawa, je ne trouve le script cliupdate.php sur mon serveur. J'ai cherché avec la commande locate sans résultat.
Comment puis-je procéder pour tenter ce que tu proposes?
Merci
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Le dossier tools n'est pas distribué dans l'archive officielle, il faut récupérer le script sur le SVN.
Par contre il ne prends en charge que les migrations depuis les versions >= 0.78
Dév. Fedora 29 - PHP 5.6/7.0/7.1/7.2/7.3/7.4 - MariaDB 10.3 - GLPI master
Certifié ITILv3 - RPM pour Fedora, RHEL et CentOS sur https://blog.remirepo.net/
Offline
Donc je ne peut pas l'utiliser dans mon cas puisque je part d'une 0.72 pour migrer vers une 0.78.
C'est bien ça?
Et si c'est le cas, quelles autres solutions sont envisageables pour me débloquer?
ddurieux parlait d'un dump à faire parvenir aux dev... Est-ce envisageable?
J'espère vraiment trouver une solution à ce qui commence à devenir un cauchemar.
Juste pour vérifier que ca ne vienne pas de ma conf (php, mysql ...?) je suis en train de monter une nouvelle machine virtuelle et réinstallant tout. Je ne vois plus que ça à mon niveau.
Merci
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Tu peux m'envoyer ton dump sql => d.durieux@siprossii.com
Faut juste qu'on soit d'accord sur la version de destination (que je ne migre pas trop loin )
Offline
Bonjour et merci de ta proposition.
Mon Dump compressé pèse plus de 14Mo (pour plus de 100 Mo). Par messagerie, ca va poser un problème pour moi.
Si tu as un FTP, je peux te le transférer. Sinon, je peux te le déposer via notre service externalisé d'échange de gros fichiers pour que tu le récupère.
Je souhaite migré d'abord en 0.78.5 afin de pouvoir migrer mon plugin validation, qui m'a d'ailleur posé un problème non résolu à ce jour: obliger de migrer mes validations lot par lot:
Voir ce topic: http://www.glpi-project.org/forum/viewt … p?id=27162
Ensuite, passer à la dernière version stable de GLPI (0.83.4).
Cependant, histoire de ne pas t'embêter pour rien, je peux finir mon test de migration depuis le nouveau serveur virtuel, pour être sûr...
Qu'en penses-tu?
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
plutot ok pour ton service d'échange.
Pour le plugin validation, t'en a plus besoin en 0.83, il est désormais intégré dans le coeur de GLPI
Offline
Je sais qu'en 0.83, le plugin n'est plus nécessaire. Mais il faut que je migre tout le contenu de ses tables. Et pour cela, il faut que je passe par la 0.78, version à partir de laquelle la validation a été intégrée au coeur de GLPI. De là, on peut migrer le contenu des tables du plugin vers les nouvelles tables GLPI. Puis on désinstalle le plugin. (voir réponse Tsmr dans le topic: http://www.glpi-project.org/forum/viewt … p?id=27162).
Pour info, j'ai retenter une migration depuis mon serveur tout neuf. Ca bloque toujours. Je suis même parti d'une sauvegarde d'avril car j'avasi réalisé mes tests concluants vers après cette date. Mais toujours rien.
Je t'envoi le dump en espérant que tu auras plus de succès que moi. Le mail que tu recevras contiendra un lien.
Merci encore
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Juste pour savoir si ca ouvre des pistes:
Sur mon nouveau serveur (DEBIAN 6 / MYSQL 5.1.63-0+squeeze1 / PHP Version 5.3.3-7+squeeze13), j'obtiens une entrée dans le fichier error.log d'apache lorsque je tente une migration vers 0.78:
PHP Notice: Undefined index: priority_matrix in /var/www/glpi/config/config.php on line 119
Et à l'écran, je reste bloqué à ce stade:
Mise à jour -> 0.78
Redressement des données - glpi_tickets (10 Sec(s))
Des fois ou ça parlerai à quelqu'un....
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
En fait j'ai vérifié: ce message n'est remonté qu'au moment de l'affichage de la page indiquant les status avant migration. Donc je ne crois pas que ce soit une piste.
Si quelqu'un pouvait m'envoyer un php.ini et éventuellement un my.conf assurément valide pour une migration vers la 0.78, ca me permettrai de voir quoi modifier dans les miens. J'ai déjà passé en revu les paramètres classiques de timeout et de mémoire.
Merci
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Bien, grâce à l'aide précieuse de ddurieux, j'ai enfin pû migrer en 0.83.4.
Ceci dit, c'est ddurieux qui a dû s'occuper de la migration de ma base en 0.78 car cela restait impossible de mon côté.
Du coup, la question de savoir qu'est ce qui bloque chez moi pour assurer la migration vers la 0.78 se pose toujours car j'ai bien peur que lors d'une prochaine migration majeur, je sois de nouveau confronté au problème.
A part le php.ini et my.cnf, qu'est ce qui peut provoquer mon problème.
Rappel: pas de message d'erreur dans aucun des logs, pas de message à l'écran, bloquage de la migration.
Merci si quelqu'un a des idées.
GLPI 0.90.3 - MySql 5.5.46-0 - Apache 2.4.10 - Debian 8u1
Offline
Même problème pour moi (cf. mon post) : j'ai migré à la main, en exportant les tables en CSV, puis en les reformatant avec Libreoffice, et enfin en les important dans la nouvelle base. Heureusement, toutes les tables n'avaient pas à être migrées (une trentaine seulement étaient utilisées).
Offline
Vous avez des versions bizarres (apache, php et peut être MySQL) parce que celle de pchauvin est passée comme une lettre à la poste
Offline