私はこのMySQLを持っています
DELETE FROM sys_log
WHERE sys_log.tstamp < UNIX_TIMESTAMP(ADDDATE(NOW(), INTERVAL -2 MONTH))
ORDER BY sys_log.tstamp ASC
LIMIT 10000
cronjob を実行すると、sys_log を小さく保つのに適していますか?
私はこのMySQLを持っています
DELETE FROM sys_log
WHERE sys_log.tstamp < UNIX_TIMESTAMP(ADDDATE(NOW(), INTERVAL -2 MONTH))
ORDER BY sys_log.tstamp ASC
LIMIT 10000
cronjob を実行すると、sys_log を小さく保つのに適していますか?
はいといいえ
あなたがあなたの記録の歴史を気にするなら、それはそうではありません。sys_history テーブルを使用して、レコード (コンテンツ、ページなど) への変更を元に戻すことができます。sys_history テーブルと sys_log テーブルは関連しています。sys_log を切り捨てると、システムへの変更をロールバックする機能も失われます。あなたのクライアントはそれを好まないかもしれません。
sys_logのサイズだけを気にする場合は、ISです。cron を介してテーブルを切り捨てることは問題ありません。
TYPO3 4.6 以降では、テーブル ガベージ コレクション スケジューラ タスク als pgampe を使用できます。TYPO3 のバージョンが 4.5 未満の場合は、tablecleaner拡張機能を使用できます。[N] 日より古いすべてのレコードを sys_log から削除すると、レコード履歴も [N] 日間保持されます。それが私にとって最善の解決策のようです。
そして、最初にsys_logを埋めているものを修正してみてください;-)
はい、そうです。
TYPO3のインストールをクリーンで小さく保つことについてのJochen Weilandによる他の提案も参照してください。
このためのスケジューラ タスクがあります。
といいTable garbage collection (scheduler)
ます。
sys_log
TYPO3 4.7 では、テーブルをきれいにすることしかできません。TYPO3 6.0から、sys_history
テーブルをきれいにすることもできます。日数とクリーンアップするテーブルを構成できます。
拡張機能は、クリーニングする追加のテーブルを登録する場合があります。
大きなsys_log
テーブルのもう 1 つの一般的な原因は、TYPO3 インストールで使用される拡張機能の 1 つの問題/エラーです。
の古いバージョンを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
この一連のレコードは、1 分ごとにポップアップ表示されsys_log
、短期間で数百万のレコードにつながります。
幸いなことに、これらの種類のレコードは、のレコード履歴および関連するロールバック機能に影響を与えないsys_history
ため、安全に削除できます。
サイズが大きい場合は、タイムアウトのsys_log
問題が発生する可能性が高いLOCK
ため、削除クエリを制限する必要があります。
delete from sys_log where details LIKE 'Core:%' LIMIT 200000;