Лучший способ сохранить журнал TYPO3 sys красивым и чистым?

У меня есть этот MySQL

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

это хорошо для сохранения sys_log маленьким, если я cronjob его?

9
typo3

5 ответов

да и нет

Это НЕ если вы заботитесь о своем история. Вы можете вернуть изменения в записи (контент, страницы и т. д.) с помощью sys_history стол. В sys_history и таблицы sys_log связаны. Когда вы усекаете sys_log, вы также теряете возможность отката любых изменений в системе. Вашим клиентам это может не понравиться.

Это IS если вы заботитесь только о размере sys_log. Усек таблица via cron в порядке.

в TYPO3 4.6 и выше вы можете использовать задачу планировщика сбора мусора таблицы als pgampe говорит. Для версий TYPO3 ниже 4.5 вы можете использовать tablecleaner

8

Да, это так.

см. также другие предложения Йохена Вейланда о сохранении установки TYPO3 чистой и небольшой

7

для этого есть задача планировщика.

Это называется Table garbage collection (scheduler).

В TYPO3 4.7 он может очищать только sys_log таблица. Начиная с TYPO3 6.0, он также может очистить sys_history таблица. Вы можете настроить количество дней и то, какие таблицы для очистки.

расширения могут регистрировать дополнительные таблицы для очистки.

6

короткий ответ:

нет, это определенно не хорошая идея. Если вы действительно хотите удалить материал из sys_log, имейте в виду, что sys_history все еще ссылается на него. Вы также должны сделать то же самое для sys_history.

или, просто сделайте следующее:

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

не стесняйтесь, чтобы оптимизировать это для ваших требований.

что вы также можете сделать безопасно (не затрагивая sys_history), это удаление записей с помощью sys_log.ошибка != 0.

очевидный ответ:

  • Сделайте ваше испытание в развитии, не продукции. Устраните свои ошибки в разработке. Тренируйте и тренируйте своих разработчиков, чтобы внимательно следить за этим.
  • установите уровень отладки на подробный (предупреждения) о разработке, но ошибки-только в производстве
  • внимательно следите за sys_log, скриптом или вручную

некоторые более рекомендации:

  • регулярно просматривайте журнал sys и устраняйте проблемы. Вы можете удалить конкретную ошибку из sys_log, как только вы позаботились о проблеме (см. sys_log.ошибка != 0, sys_log.подробная информация.) Вы можете сделать это с помощью команды базы данных или в более новых версиях TYPO3 использовать "SYSTEM: log" в бэкэнде и использовать кнопку" Удалить подобные ошибки":

enter image description here

  • на каждом главном обновлении, мы сделай truncate sys_log и truncate sys_history, вместе с использованием низкоуровневого очистителя (который удаляет записи с deleted=1, например). Обязательно поговорите с кем-нибудь в сначала близко к редакторам, хотя это и удалит всю историю. Мы прекрасно справляемся с сохранением более старой версии экземпляра TYPO3 онлайн только с внутренним доступом. Мы любим держать вещи в чистоте:)

в более новых версиях TYPO3 больше не будет этой проблемы отношения между sys_log и sys_history, хотя. Посмотрите на Breaking Change #55298 in TYPO3 9.

2

еще одна распространенная причина для больших sys_log таблицы проблемы/ошибки в одном из расширений, используемых в установке TYPO3.

типичный пример, когда старая версия 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

этот набор записей появится в sys_log каждую минуту или около того, что приводит к миллионам записей за короткий промежуток времени.

к счастью, такие записи не оказывают никакого влияния на историю записей в sys_history и связанный откат функциональность, поэтому безопасно удалить их.

если у вас большая sys_log Это, вероятно, вызовет проблемы с LOCK таймауты, поэтому вам придется ограничить запрос на удаление:

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

1