échec Sauvegarde SQL : pas optimisé ? table logs trop grosse ?

iubito · 2013-04-11 10:17:31

Bonjour,
je souhaite mettre à jour GLPI et commence à suivre la procédure décrite à la page http://www.glpi-project.org/spip.php?article171

Je rencontre un problème sur la sauvegarde SQL.
Soit elle se fait en quelques secondes et me donne un fichier de 20Mo
Soit elle bloque à 37% et génère un fichier de 60 ou 90Mo, suivant mes 2 essais.

A l'étape 37%, sur l'activité de mon serveur MySQL, je constate des requêtes
select * from glpi_logs limit x, 5
avec une incrémentation de 5 en 5 de la valeur de x, donc par exemple
select * from glpi_logs limit 280905, 5
à ce stade, ça veut déjà dire qu'il y a eu plus de 56000 requêtes sur la table glpi_logs
Puis au bout d'un long moment, ça fini par mourir et le fichier SQL généré montre que ça s'est arrêté quelque part dans

ce fonctionnement n'est-il pas un peu mal optimisé?

Pour info, j'ai 1.400.000 lignes dans glpi_logs!

Un mysqldump --tab (*) de ma base donne environ 160Mo de SQL+data, en SQL pur cela devrait être plus volumineux.

* : séparation structure en sql / data en fichier plat

Comment puis-je procéder ?
- j'ai ma sauvegarde ailleurs et je restaure par mes propres moyens
- il faut obligatoirement une sauvegarde "façon GLPI"
- si je ne peux la générer via GLPI, quels paramètres de mysqldump pour obtenir un fichier compatible ?

remi · 2013-04-11 10:31:03

La sauvegarde externe (mysqldump) est la meilleure solution.

iubito · 2013-04-11 11:02:46

Merci !

Forum GLPI-Project

Announcement

#1 2013-04-11 10:17:31

échec Sauvegarde SQL : pas optimisé ? table logs trop grosse ?

#2 2013-04-11 10:31:03

Re: échec Sauvegarde SQL : pas optimisé ? table logs trop grosse ?

#3 2013-04-11 11:02:46

Re: échec Sauvegarde SQL : pas optimisé ? table logs trop grosse ?

Board footer