2012-06-27 16 views
9

tengo este MySQL¿La mejor manera de mantener TYPO3 sys_log agradable y limpio?

DELETE FROM sys_log 
WHERE sys_log.tstamp < UNIX_TIMESTAMP(ADDDATE(NOW(), INTERVAL -2 MONTH)) 
ORDER BY sys_log.tstamp ASC 
LIMIT 10000 

Es esto bueno para mantener el pequeño sys_log, si cronjob que?

+1

¿Es realmente cronjob un verbo? – HerrSerker

+0

No, es un sustantivo. Este cronjob. Un cronjob. Aunque personalmente no me importa la creación creativa de palabras aquí. Si te importa, ¿te importa editar? – wirap

Respuesta

8

Sí y No

Se NO ES si se preocupan por su historial de registro. Puede revertir los cambios a los registros (contenido, páginas, etc.) utilizando la tabla sys_history. Las tablas sys_history y sys_log están relacionadas. Cuando trunca sys_log, también pierde la capacidad de deshacer cualquier cambio en el sistema. A sus clientes puede no gustarles eso.

Se ES si sólo se preocupan por el tamaño sys_log. Truncar la tabla a través de cron está bien.

En TYPO3 4.6 y versiones posteriores puede usar la tarea del planificador de recolección de basura de la tabla, como dice pgampe. Para las versiones de TYPO3 inferiores a 4.5, puede usar la extensión tablecleaner. Si elimina todos los registros de sys_log anteriores a [N] días, también conservará su historial de registros durante [N] días. Esa parece ser la mejor solución para mí.

Y por favor tratar de arreglar lo que está llenando su sys_log en el primer lugar ;-)

+0

Un comentario rápido - IIRC hay un trabajo de programador, por lo que puede mantener la limpieza de la casa "dentro" de su instalación de TYPO3, y no tiene diferentes trabajos cli externos en ejecución –

6

Hay un programador de tareas para esto.

Se llama Table garbage collection (scheduler).

En TYPO3 4.7, solo puede limpiar la tabla sys_log. A partir de TYPO3 6.0, también puede limpiar la tabla sys_history. Puede configurar el número de días y las tablas para limpiar.

Las extensiones pueden registrar más tablas para limpiar.

+0

¿Cómo se llama? – HerrSerker

+0

Agregué el nombre y algunas palabras más en la respuesta. – pgampe

+0

en typo3 4.7.8 esta tarea no se puede programar desde el backend debido a varios errores en la extensión del planificador.Ver el error http://forge.typo3.org/issues/48022, diff: http://forge.typo3.org/projects/typo3v4-core/repository/revisions/f3f892ee2d3915b1934a7ce62cc921a3555cf8be/diff/typo3/sysext/scheduler/class. tx_scheduler_module.php – knb

1

Otra causa común para grandes sys_log tablas son problemas/errores en una de las extensiones utilizadas en la instalación de TYPO3.

Un ejemplo común cuando se utiliza una versión antigua de tx_solr:

Core: Error handler (FE): PHP Warning: Invalid argument supplied for foreach() in typo3conf/ext/solr/classes/class.tx_solr_util.php 
Core: Error handler (FE): PHP Warning: array_reverse() expects parameter 1 to be array, null given in typo3conf/ext/solr/classes/class.tx_solr_util.php line 280 

Este conjunto de registros emergerá en sys_log cada minuto más o menos lo que lleva a millones de registros en un corto período de tiempo.

Afortunadamente, este tipo de registros no tienen ningún efecto en el historial de registros en sys_history y la funcionalidad de reversión asociada, por lo que es seguro eliminarlos.

Si usted tiene una gran sys_log esto probablemente causará problemas con LOCK tiempos de espera, por lo que tendrá que limitar la consulta de eliminación:

delete from sys_log where details LIKE 'Core:%' LIMIT 200000;

1

Respuesta corta:

No, Definitivamente no es una buena idea. Si realmente desea eliminar cosas de sys_log, tenga en cuenta que sys_history aún hace referencia a ellas. Deberías hacer lo mismo para sys_history también.

O, simplemente, haga lo siguiente:

DELETE FROM sys_log WHERE NOT EXISTS 
(SELECT * FROM sys_history WHERE sys_history.sys_log_uid=sys_log.uid) 
AND recuid=0 AND tstamp < $timestamp LIMIT $limit 

dude en para optimizar este para sus necesidades.

Lo que también se puede hacer de manera segura (sin afectar sys_history) es la eliminación de registros con sys_log.error = 0.

La respuesta obvia:

  • hacer sus pruebas en el desarrollo, la producción no . Elimina tus errores en el desarrollo. Entrene y analice a sus desarrolladores para vigilar de cerca esto.
  • Indica tu nivel de depuración para prolijo (Advertencias) en el desarrollo, pero los errores sólo en la producción
  • vigilar de cerca la sys_log, mediante la escritura o manualmente

Algunos más recomendaciones:

  • Mire regularmente el registro del sistema y elimine los problemas. Puede eliminar el error específico de sys_log una vez que haya solucionado el problema (consulte sys_log.error! = 0, sys_log.details). Usted puede hacer esto con un comando de base de datos o en las nuevas versiones de TYPO3 utilizar el "SISTEMA: log" botón en el backend y utilizar la opción "Eliminar errores similares":

enter image description here

  • En cada actualización importante , hacemos un truncate sys_log y truncate sys_history, junto con el uso del limpiador de bajo nivel (que elimina registros con deleted = 1, por ejemplo). Asegúrese de hablar con alguien en el cerca de los editores, aunque esto eliminará todo el historial. Hacemos bien en mantener una versión anterior de la instancia de TYPO3 en línea con acceso interno solamente. Nos gusta mantener las cosas limpias :)

En las versiones más nuevas de TYPO3, ya no existirá este problema de relación entre sys_log y sys_history. Mire Rompiendo Cambio #55298 en TYPO3 9.

Cuestiones relacionadas