version de la base de données n'est pas compatible

herren · 2008-06-16 15:40:11

Bonjour,
Je fais des essais sur un serveur de test avant de l'appliquer sur le serveur en production.
Lors de la mise jour de la version 0.68.3 en 0.70.2. apparaît en boucle page représentée ci-dessous par COPIE ECRAN 1.
Voici les opérations réalisées.
1) Dans le fichier /etc/php.ini, remplacement des lignes
max_execution_time = 60
memory_limit = 32M
par les lignes
max_execution_time = 180
memory_limit = 256M

2) Désactivation des plugins en supprimant les répertoires ci-dessous
rm -rf /var/lib/mysql/glpi/plugins
rm -rf /var/www/html/glpi/plugins

3) Désactivation de l'authentification LDAP, sinon lors de l'accès à http://votreserveur/glpi/ j'obtiens une page blanche
Bouton Administration
Lien Authentification Externe
Vider tous les champs

4) décompression de l'archive
cd /var/www/html
gunzip glpi-0.70.2.tar.gz
tar -xvf glpi-0.70.2.tar

5) changement des droits sur répertoire files et fichier config
chmod -R 777 /var/www/html/glpi/files/
chmod 777 /var/www/html/glpi/config

6) Lorsque j'accède à http://votreserveur/glpi/ ci-dessous la copie d'écran obtenue
------------------------------------
COPIE ECRAN 1
Test effectué Résultats
Test la mémoire allouée Mémoire allouée > 32 Mo - Parfait !
Tests d'écriture de fichiers dump Un fichier et un dossier a été créé et supprimé - Parfait !
Test d'écriture de fichiers documents Un fichier et un dossier a été créé et supprimé - Parfait !
Test d'écriture du fichier de configuration Un fichier et un dossier a été créé et supprimé - Parfait !
Test d'écriture des fichiers de sessions Un fichier et un dossier a été créé et supprimé - Parfait !
Test d'écriture des fichiers de cron Un fichier et un dossier a été créé et supprimé - Parfait !
Test d'écriture des fichiers de cache Un fichier et un dossier a été créé et supprimé - Parfait !
Test d'écriture des fichiers de log Un fichier et un dossier a été créé et supprimé - Parfait !

Votre version de la base de données n'est pas compatible avec la version du code installé. Une mise à jour est nécessaire.
Bouton <mise à jour>
------------------------------------

7) Après action du bouton <mise à jour>, ci-dessous la copie d'écran obtenue
------------------------------------
COPIE ECRAN 2
GLPI SETUP
Update
Connexion à la base de données réussie
Strict Standards: date() [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /var/www/html/glpi/inc/common.function.php on line 99
0.7 check multiple free global licenses Erreur durant la mise à jour de la base de donnéesGot error -1 from storage engine
------------------------------------
8) Lorsque j'accède de nouveau à http://votreserveur/glpi/ , s'affiche à nouveau la COPIE ECRAN 1

Notre configuration
L'application OCS et la base de données sont sur deux VSERVER distincts
GLPI 0.68.3
MySQL: 5.0.27
phpMyAdmin - 2.9.2
Fedora Core release 6

Comme indiqué dans certains échanges de ce forum j'ai tenté une sauvegarde/restauration de la base GLPI du serveur de production vers ce serveur de tests. Cependant j'ai un doute sur la procédure de sauvegarde/restauration à appliquer.

Sur le serveur de production j'ai utilisé la commande de sauvegarde :
mysqldump -u root -p"MOT_DE_PASSE" glpi >glpi_sauv.sql

Sur le serveur de test j'ai utilisé la commande de restauration :
mysql -u root - p"MOT_DE_PASSE" glpi < glpi_sauv.sql

Questions
1) Comment éviter d'obtenir COPIE ECRAN 1 lors de l'étape de mise à jour?
2) Si je réalise une sauvegarde, sur le serveur de production (GLPI 0.68.3), de la façon suivante : Bouton <Administration>, Menu <Données>, Bouton <Sauvegarde SQL>
Où se trouve le fichier de sauvegarde qui dans notre configuration se nomme < 2008-06-16-13-24.sql>. J'ai beau chercher avec la commande <find> je ne le trouve pas?
3) Dans quel répertoire et avec quelle commande restaurer le fichier de sauvegarde, si l'interface GLPI n'est pas disponible lors de la phase de mise à jour?

JMD · 2008-06-16 22:16:18

1) Humm ça me semble être un problème de version de php

2) Le fichier se trouve dans /files/_dump

3) Avec la meme commande que celle que vous utilisez habituellement

herren · 2008-06-17 17:13:59

Pour résoudre l'anomalie signalée ici http://glpi-project.org/forum/viewtopic.php?id=10834, j'ai tenté une mise à jour de la version 0.68.3 en 0.70.2
Cette mise à jour n'aboutissant pas, j'ai choisi de faire une installation de la version 0.70.2.
Je voudrais des renseignements pour sauvegarder toutes les données disponibles sur le serveur en 0.68.3 afin de les restaurer sur le serveur en 0.70.2.

Voici les opérations réalisées.
1) Après installation de la version 0.70.2, j'ai configuré le mode OCSNG et importé avec succès toutes les machines via le menu <OUTILS/ OCSNG/ Importation de nouveaux ordinateurs>
2) Après importation avec OCSNG,
Dans <Inventaire / Ordinateur>
<onglet principal> les champs : <lieu, réseau, domaine, statut> étaient vides
<onglet gestion > tous les champs de < Informations financières> étaient vides.
Dans <Assistance / Suivi> il n'y a pas de demandes
Normal vu que j'ai réalisé une installation et non pas une mise à jour

3) J'ai sauvegardé la base sur le serveur de production en version 0.68.3 avec le menu <Administration/ Données/ Sauvegarde SQL>. Copié le fichier résultant sur le serveur de test en version 0.70.2 dans le répertoire </var/www/html/glpi/files/_dumps>

4) Restauré avec succès la base avec le menu <Administration/ Données/ Restaurer>

5) Lors de l'accès à http://votreserveur/glpi/ le message suivant s'est affiché :"Votre version de la base de données n'est pas compatible avec la version du code installé. Une mise à jour est nécessaire." Après action du bouton <Mise à Jour>. GLPI était normalement disponible contrairement à l'anomalie citée au tout début de ce message.

6) Cette fois ci dans <Inventaire / Ordinateur> <onglet principal> les champs <lieu, réseau, domaine, statut> sont renseignés. Mais dans <onglet gestion > tous les champs de <Informations financières> sont restés vides. Même chose pour <Assistance / Suivi>

Questions
1) De quelle façon faut-il sauvegarder touts les données du serveur en 0.68.3 pour les restaurer sur le serveur en 0.70.2. . Ceci pour récupérer toutes les données de <Informations financières> et <Assistance / Suivi>

Grand merci pour le temps passé à me lire et à me répondre.

JMD · 2008-06-17 19:46:58

Questions :

1) les deux serveurs ont ils des configurations identiques (matérielles et logicielles) ?

2) Pourquoi faire une importation via OCS sur une fresh install de glpi avant d'injecter l'ancienne db ?

herren · 2008-06-18 09:11:52

1 )Les deux serveurs, qui sont des VSERVER sous Fedora Core release 6, ont une configuration identique au niveau système et RPMs. C'est certain car le serveur de test est obtenu par le clonage du serveur de production via l'utilisation de la commande <rsync>.
2) Je vais faire une de restauration de la base, sans faire une importation via OCS pour voir si toutes les données sont récupérées.

herren · 2008-06-18 10:59:01

Cette fois-ci après installation de la version 0.70.2, je n'ai pas importé les machines via OCSNG.
Je me suis contenté de restaurer la base de données du serveur en production en version 0.68.3 vers le serveur de test en version 0.70.2.
Malgré cela, tous les champs de <Informations financières> sont vides. Même chose pour <Assistance / Suivi>.
Auriez-vous une suggestion à me proposer sur la méthode de sauvegarde/restauration afin de récupérer toutes les données?

JMD · 2008-06-18 20:10:04

Je pige pas , votre procédure me semble bonne (je fais des backups/restauration régulièrement soit en ligne de commande, soit en utilisant l'interface de GLPI sans problème).

S'il vous manque des données c'est soit qu'elles ne sont pas dans le dump soit que le script d'import plante sur des données problématiques.

Pour débugguer j'aurai tendance à faire ça :

Export en ligne de commande de votre ancienne base
Export en ligne de commande de votre base mise à jour

faire un diff des deux bases pour voir ce qui a changé et surtout si des données sont absentes.

Questions subsidiaires : vous aviez modifié des éléments à la main dans votre db ?

herren · 2008-06-19 15:05:27

En effet les informations financières comme <Date d'achat>, <Durée Garantie>, <Valeur> sont saisies manuellement sur le serveur en production.
Il en est de même pour l'assistance saisie via le menu <Assistance / HELPDESK>.
Ces informations disparaissent lors de la sauvegarde (en 0.68.3) / restauration (en 0.70.2).
A noter que les champs de l'onglet Principal comme <Statut>, <Réseau>, <Commentaires> sont aussi saisis manuellement et restent disponibles lors d'une sauvegarde (en 0.68.3) /restauration (en 0.70.2.

JMD · 2008-06-19 22:50:23

Je parlais pas de saisie manuelles dans GLPI, je parlais d'écriture dans la DB hors utilisation de l'interface GLPI comme via phpmyadmin par exemple.

Est -ce que vous avez fait les diff comme je vous le proposais ? Ce que vous indiquez comme manquant ne correspond pas à des champs ou des enregistremements de la DB

herren · 2008-06-20 11:36:57

Je n'ai pas modifié d'éléments à la main dans la base, comme par exemple via PHPMYADMIN.
Vous dites : "Pour débuguer j'aurai tendance à faire ça :
Export en ligne de commande de votre ancienne base
Export en ligne de commande de votre base mise à jour"

Je ne peux pas faire d'export en ligne de commande de la base mise à jour, puisque la mise à jour échoue.

J'ai réalisé d'autres essais de sauvegarde/restauration.
Essai 1
Serveur de test en version 0.68.3
a) Sauvegarde de la base avec interface GLPI
b) Suppression d'un ordinateur avec le bouton PURGER et confirmation avec CORBEILLE
c) Restauration de la base avec interface GLPI
Conséquences :
Avant la sauvegarde les informations financières, de l'ordinateur supprimé, étaient renseignées, les statistiques de l'assistance étaient disponibles.
Après restauration via l'interface GLPI la fiche de l'ordinateur supprimé est disponible, mais ses informations financières sont vides. Par contre les statistiques de l'assistance sont toujours disponibles.

Essai2
Serveur de test en version 0.68.3
a) Sauvegarde de la base avec commande
"mysqldump -u LOGIN -p"MOT_PASSE" glpi >glpi_dump.sql"
b) Suppression d'un ordinateur avec le bouton PURGER et confirmation avec CORBEILLE
c) Restauration de la base avec commande
" mysql -u LOGIN -p"MOT_PASSE" glpi < glpi_dump.sql"
Conséquences :
Avant la sauvegarde les informations financières, de l'ordinateur supprimé, étaient renseignées, les statistiques de l'assistance étaient disponibles.
Après restauration via l'interface GLPI la fiche de l'ordinateur supprimé est disponible, ses informations financières sont renseignées. Les statistiques de l'assistance sont toujours disponibles.

Essai3
Sur le serveur de test en version 0.68.3.
a) Sauvegarde de la base avec commande
"mysqldump -u LOGIN -p"MOT_PASSE" glpi >glpi_dump.sql"
b) Installation de la version 0.70.2
c) Restauration de la base avec commande
" mysql -u LOGIN -p"MOT_PASSE" glpi < glpi_dump.sql"
Conséquences :
Le message suivante s'affiche :"Votre version de la base de données n'est pas compatible avec la version du code installé. Une mise à jour est nécessaire"
J'ai beau actionner le bouton <Mise à jour> à chaque accès à http://votreserveur/glpi/ le même message s'affiche.

Sur notre configuration la sauvegarde/restauration via l'interface GLPI ne restaure pas toutes les données. La sauvegarde restauration avec les commandes MYSQL restaure toutes les données.
Dans votre configuration avec l'interface GLPI ou via les commandes MYSQL la sauvegarde/restauration réagit normalement.

Je ne vois pas comment passer de la version 0.68.3 en 0.70.2 sans perdre de données. Pensez-vous que j'aurais plus de succès en installant au préalable les mises à jour intermédiaires (0.68.3-2, 0.70, 0.70.1a)?

JMD · 2008-06-20 20:01:36

Si vous le souhaitez vous pouvez nous envoyer votre DB afin que nous regardions d'où vient le problème.

herren · 2008-06-23 15:55:29

Pour des questions de confidentialités, mon supérieur hiérarchique n'est pas d'accord pour que je transmette une copie de la base de données.
Je tenterai des essais de mises à jour successives : 0.68.3-2, 0.70, 0.70.1a et vous tiendrai informé.
Merci pour votre aide.

JMD · 2008-06-23 23:51:37

Ok comme vous le souhaitez.

C'est amusant tout de même si j'étais un prestataire de service et que je facturais cette prestation le problème de confidentialité n'en serait pas un...

herren · 2008-06-24 15:24:39

Pour information
Lors de la migration de la version 0.68.3-20.en 68.3-2, il n'y a pas de pertes de données.
Mais lors de la migration de la version 68.3-2 en 0.70 je me retrouve dans le cas ci-dessus décrit le 20/06/2008 <Essai3>.
Pour le moment je ne vois pas ce que je peux faire de plus.
Je vais laisser passer quelques jours en attendant d'être inspiré par un autre type de manipulation.
Ce sujet peut être clôturé
Merci pour votre patience.

JMD · 2008-06-24 23:46:53

C'est la conversion en full utf8 qui doit poser problème. Un contenu doit bloquer la conversion.

Je ne peux vous en dire plus dans l'état actuel...

herren · 2008-07-03 15:56:44

Lors de la migration de 0.68.3 en 0.70.2 je signalais des pertes de données. Une manipulation a permis de récupérer ces données.

Les données perdues étaient les suivantes :
Les informations financières : date d'achat, durée de garantie, valeur, etc.
Le HELP DESK : statistiques, demandes d'intervention.
J'ai constaté plus tard qu'il manquait aussi la base de connaissance.

Rappel de la procédure de sauvegarde/restauration employée :
1) Sauvegarder la base sur le serveur de production en version 0.68.3 avec le menu <Administration/ Données/ Sauvegarde SQL>.
2) Copier le fichier résultant sur le serveur de test en version 0.70.2 dans le répertoire </var/www/html/glpi/files/_dumps>
3) Sur le serveur de test en 0.70.2 restaurer avec le menu <Administration/ Données/ Restaurer>

Les informations financières ont été récupérées en réalisant les opérations suivantes.
1) Sur le serveur en production (0.68.3 ) via phpMyAdmin, sélection de la table glpi_infocoms, bouton <Exporter/ Exécuter>
2) Copier coller dans un éditeur le résultat de l'action sur bouton <Exécuter>. A noter que ce résultat contient la commande de création de la table glpi_infocoms, et les instructions d'insertion des données.
3) Sur le serveur de test (0.70.2) via phpMyAdmin, suppression de la table glpi_infocoms.
4) Bouton <Importer>, sélection du fichier réalisé dans l'étape 2) puis bouton <Exécuter>

La même opération a été réalisée avec les tables suivantes :
table_glpi_tracking (help desk)
table_glpi_kbitems (base de connaissance)

Lors de l'exportation j'ai tenté au préalable de n'exporter que les instructions d'insertion des données. Mais dans ce cas l'importation échoue. Cet échec est lié au fait que la colonne TYPE et la colonne NULL des champs diffère entre les tables version 0.68.3 et celles en version 0.70.2.

Forum GLPI-Project

Announcement

#1 2008-06-16 15:40:11

version de la base de données n'est pas compatible

#2 2008-06-16 22:16:18

Re: version de la base de données n'est pas compatible

#3 2008-06-17 17:13:59

Re: version de la base de données n'est pas compatible

#4 2008-06-17 19:46:58

Re: version de la base de données n'est pas compatible

#5 2008-06-18 09:11:52

Re: version de la base de données n'est pas compatible

#6 2008-06-18 10:59:01

Re: version de la base de données n'est pas compatible

#7 2008-06-18 20:10:04

Re: version de la base de données n'est pas compatible

#8 2008-06-19 15:05:27

Re: version de la base de données n'est pas compatible

#9 2008-06-19 22:50:23

Re: version de la base de données n'est pas compatible

#10 2008-06-20 11:36:57

Re: version de la base de données n'est pas compatible

#11 2008-06-20 20:01:36

Re: version de la base de données n'est pas compatible

#12 2008-06-23 15:55:29

Re: version de la base de données n'est pas compatible

#13 2008-06-23 23:51:37

Re: version de la base de données n'est pas compatible

#14 2008-06-24 15:24:39

Re: version de la base de données n'est pas compatible

#15 2008-06-24 23:46:53

Re: version de la base de données n'est pas compatible

#16 2008-07-03 15:56:44

Re: version de la base de données n'est pas compatible

Board footer