Проблема с многими таблицами с префиксом *cache*

[pavel_t]

Доброй ночи всем).

Может быть кто-то уже сталкивался с подобной проблемой?
Проблема в следующем:
В лог-файле MySQL (mysqld.log) начали довольно активно появляться записи такого содержания:
"
...
61104 16:04:49 [ERROR] /usr/libexec/mysqld: Incorrect information in file: './database/cache_hash.frm'
61104 16:04:49 [ERROR] /usr/libexec/mysqld: Incorrect information in file: './database/cache_pagesection.frm'
...
"
Файл вырос до объема около 200Мб за пару суток.

И так примерно с упоминанием десятка таблиц:

• cache_hash.frm
• cache_imagesizes.frm
• cache_pages.frm
• cache_pagesection.frm
• cache_treelist.frm
• fe_session_data.frm
• fe_sessions.frm
• tx_realurl_chashcache.frm
• tx_realurl_pathcache.frm
• tx_realurl_urldecodecache.frm

Запустил проверку базы данных средствами Install Tools Typo3.
Результат - необходимо создать(пересоздать) (даже не десяток) - 29 таблиц. Практически все с префиксом *cache*.
При чем не только таблиц ядра CMS, но и не типичных расширений (типа 'tx_cal').

• Полный список:
• cache_hash
• cache_imagesizes
• cache_md5params
• cache_pages
• cache_pagesection
• cache_treelist
• cache_typo3temp_log
• cachingframework_cache_hash
• cachingframework_cache_hash_tags
• cachingframework_cache_pages
• cachingframework_cache_pages_tags
• cachingframework_cache_pagesection
• cachingframework_cache_pagesection_tags
• fe_session_data
• fe_sessions
• sys_history
• sys_log
• sys_workspace_cache
• sys_workspace_cache_tags
• tx_cal_cach
• tx_cal_cache_tags
• tx_extbase_cache_object
• tx_extbase_cache_object_tags
• tx_extbase_cache_reflection
• tx_extbase_cache_reflection_tags
• tx_realurl_chashcache
• tx_realurl_pathcache
• tx_realurl_urldecodecache
• tx_realurl_urlencodecache

Когда увидели проблему, восстановили средствами Install Tools Typo3 указанные таблицы.
Через какое-то время (около суток) проблема возникла вновь.
Вновь восстановил таблицы тем же инструментом.
Прошло всего около часа. Пока "полет нормальный". Но как-то не спокойно.

Может быть кто-то уже сталкивался с подобной проблемой?

Вкратце о системе:

• VPS на CentOS 5.6 (Final).
• MySQL Server version: 5.0.90
• Apache: httpd-2.2.3
• php: 5.2.17
• CMS Typo3 4.5.40

Заранее благодарю за отклики.

[Николай Сипко]

"Ries van Twisk
Tue, 19 June 2007 14:15

Hey,

check your uptime... And see if somebody restarted your server.
also check your HD space left on your devices, you have may run out
of it.
Check if MySQL has been crashed (I never sen that, but you never know).

If something happens, MySQL always have a hard time recovering and
you will get these 'in use' tables. The good thing is that you don't
notice
much when using typo3.

On a occasion this simply happens with MySQL, most of the times with
a reason,
sometimes without a reason.

What I did the last time is stop MySQL, delete the tables start MySQL
and re-create them.
The only contain cache information and can be re-build by TYPO3.

Ries"

https://forum.typo3.org/index.php?t=msg&goto=347609&

P.S. К теме вопроса это не относится, но в новых версиях TYPO3 в Install:

Clear tables
=======
Use with care! Clearing tables here can have a negative impact on your site functionality. You could log out all users, delete all their basket data, and lose logging information!

Some database tables in TYPO3 CMS hold semi-temporary data that is not deleted when clicking "Clear all cache" in the backend. Those can be cleared here, effectively removing all rows from it. This can be useful in rare cases.
be_sessions Rows: 2

Description: Backend user sessions
cache_md5params Rows: 0

Description: Frontend redirects
fe_sessions Rows: 0

Description: Frontend user sessions
fe_session_data Rows: 0

Description: Frontend user session data
sys_history Rows: 42

Description: Tracking of database record changes through TYPO3 backend forms
sys_lockedrecords Rows: 1

Description: Record locking of backend user editing
sys_log Rows: 93

Description: General log table
tx_extensionmanager_domain_model_extension Rows: 0

Description: List of TER extensions
tx_rsaauth_keys Rows: 0

Description: Login process key storage
=======

Благодаря очистке этих таблиц размер базы данных не разрастается со временем до чудовищных размеров.
В старых версиях их можно и нужно очищать вручную.

[pavel_t]

Благодарю за ответ.
У нас, скорее всего, проблема была с исчерпанием дискового пространства.
Пока, после восстановления битых таблиц базы и устранения серверных ошибок, приводивших к забиванию hd, все в порядке.
За комментарии по поводу очистки кэш-таблиц Тайпо также спасибо.