You are not logged in.

Announcement

 Téléchargez la dernière version stable de GLPI      -     Et vous, que pouvez vous faire pour le projet GLPI ? :  Contribuer
 Download last stable version of GLPI                      -     What can you do for GLPI ? :  Contribute

#1 2014-05-23 09:12:23

jd_b
Member
Registered: 2009-06-15
Posts: 2

Plantage migration du à la table glpi_logs enorme

Bonjour
Je tente une migration GLPI de la v0.83.4 vers la 0.84.5. (RHEL 6)
Tout semble se derouler sans pb, jusqu'a la 0.84.4 ou la tâche "Optimisation des tables" démarre
Le processus s'arrête sur la table glpi_logs (je suppose car elle se situe juste après la table glpi_locations pour laquelle le temps d'optimisation est affiché) qui contient un peu plus de 9 millions d'entrées et au bout d'un certain délai la migration s'arrête brutalement.
Puis-je vider cette table glpi_logs et de quelle manière (SQL, script, procédure spécifique, etc ...) ?
Ne sachant pas si d'autres tables sont également énorme (mon par fait un peu moins de 500 machines), risque-je d'avoir le même cas sur d'autres tables et si oui puis-je vider ces tables de la même manière

merci d'avance pour vos réponses

Offline

#2 2014-05-23 09:19:00

ddurieux
Plugins Dev
From: Propières, France
Registered: 2005-06-17
Posts: 7,521

Re: Plantage migration du à la table glpi_logs enorme

Tu peux faire un optimize manuellement ou dans un script cron du système, j'ai des tables de 61 millions de lignes et je le lance en commandes

Offline

#3 2014-05-26 07:14:59

jd_b
Member
Registered: 2009-06-15
Posts: 2

Re: Plantage migration du à la table glpi_logs enorme

OK, effectivement, j'ai vu qu'avec phpMyAdmin, cela n'avait mis qu'un quart de seconde à se réaliser
Je me pose la question qu'est-ce qui peut bloquer la migration à cet endroit?
Est-ce que le process engagé par la migration GLPI est plus long que le process engagé par phpMyAdmin (j'ai vu sur un post par exemple que pour les saves de la BDD il était préférable de le faire via un cron plutôt que d'utiliser la tâche existante dans GLPI -onglet Administration/Maintenance-).
Concernant cette table glpi_logs, n'ai-je pas interêt à l'apurer de temps en temps et si oui comment faire (suppression directe par phpMyAdmin par exemple) ? Y a t'il une relation entre cette table et d'autres ?
Enfin dernière question concernant la migration, est-ce que le processus d'optimisation est le dernier entamé par la migration ? Dans ce cas mon upgrade est terminé. Dans le cas contraire, je suis un peu dans le flou pour le terminer.

Offline

#4 2014-09-17 09:37:20

durand.jm
Member
Registered: 2009-11-25
Posts: 110

Re: Plantage migration du à la table glpi_logs enorme

je relance ce sujet

moi aussi je cherche a purger cette table glpi_logs pour ne garder que 1-2 ans maxi d'historique ...là j'en ai 4 ans et donc 800mo

peut on supprimer sans conséquence ??

je n'ai pas trouver la réponse ailleurs et pourtant c'est souvent demandé.

Offline

#5 2014-09-17 12:06:26

ddurieux
Plugins Dev
From: Propières, France
Registered: 2005-06-17
Posts: 7,521

Re: Plantage migration du à la table glpi_logs enorme

tu pourrais nettoyer les logs qui ont plus de 2 ans par exemple.... A voir si ca peut convenir

Offline

#6 2014-09-17 13:37:47

durand.jm
Member
Registered: 2009-11-25
Posts: 110

Re: Plantage migration du à la table glpi_logs enorme

ok donc j'en déduis qu'on peut supprimer sans conséquence
merci

Offline

#7 2014-09-17 13:54:54

ddurieux
Plugins Dev
From: Propières, France
Registered: 2005-06-17
Posts: 7,521

Re: Plantage migration du à la table glpi_logs enorme

Disons que tu perds tout l'historique qui a plus de 2 ans (ordinateurs, tickets...)

Offline

#8 2014-09-17 20:50:55

yllen
GLPI-DEV
From: Sillery (51)
Registered: 2008-01-14
Posts: 15,278

Re: Plantage migration du à la table glpi_logs enorme

Dans le dossier tools de GLPI, il y a un script qui permet de nettoyer l'historique en précisant ce que l'on veut supprimer (type d'objet et meme le type de l'historique).

Par exemple je peux demander pour un ordinateur de supprimer uniquement ce qui concerne les mise à jour des composants.


CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6  - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)

Offline

#9 2014-09-18 08:11:57

durand.jm
Member
Registered: 2009-11-25
Posts: 110

Re: Plantage migration du à la table glpi_logs enorme

merci
j'ai fait du manuel
tout ce qui était écrit par 'Plugin_FusionInventory' et inférieur au 01-01-2013
je suis retombé à 200mo au lieu de 800

DELETE FROM `glpi_logs`
WHERE `user_name` LIKE 'Plugin_FusionInventory'
AND `date_mod` <= '2013-01-01 00:00:00'


merci

Offline

#10 2014-09-18 10:50:44

Oggy One
Member
From: Tours - France
Registered: 2011-06-22
Posts: 68

Re: Plantage migration du à la table glpi_logs enorme

Bonjour,

De mon côté j'utilise le plugin purgelogs https://forge.indepnet.net/projects/purgelogs

La cause principale pour moi était liée aux synchro avec l'AD et au fait que je garde dans GLPI les users suprrimés dans l'AD

Philippe


PROD : GLPI 9.2.1 - Debian 9 - Apache 2.4.10 - PHP 5.6.38-0+deb8u1 - MySQL 5.5.60-0+deb8u1
Plugins principaux : FormCreator, Behaviors, Accounts, FusionInventory, PurgeLogs, DataInjection, GenericObjects
TEST : GLPI 9.4.5 Windows 10 xampp Apache 2.4.41 PHP 7.3.12 MariaDB 10.4.10
DEV : GLPI 9.4.5 Debian 10 Apache 2.4.38 PHP 7.3.14 MariaDB 10.3.22 + Plugins Prod

Offline

Board footer

Powered by FluxBB