vBulletin 4.x.x и ошибка taggregate_temp_xxxxxxxxxx

С недавнего времени, на почту стали приходить письма с уведомлением об ошибке на форуме, в админке которого на мое «несчастье» стоял мой почтовый ящик. Письма были примерно такого содержания.

Database error in vBulletin 4.x.xx:

Invalid SQL:

INSERT INTO taggregate_temp_1338177360
SELECT threadid, COUNT(*) AS views
FROM threadviews
GROUP BY threadid;

MySQL Error : Incorrect file format ‘threadviews’
Error Number : 130
Request Date : Monday, May 28th 2012 @ 04:29:17 AM
Error Date : Monday, May 28th 2012 @ 04:29:17 AM
Script : http://forum.xxxxxxx.ru/cron.php?rand=1338179327
Referrer :
IP Address : xxx.xxx.xxx.xxx
Username : Незарегистрированный
Classname : vB_Database
MySQL Version :

или еще вариант:

Database error in vBulletin 4.2.0:

Invalid SQL:

INSERT INTO aaggregate_temp_1345493400
SELECT attachmentid, COUNT(*) AS views
FROM attachmentviews
GROUP BY attachmentid;

MySQL Error : Incorrect file format ‘attachmentviews’
Error Number : 130
Request Date : Tuesday, August 21st 2012 @ 04:48:17 AM
Error Date : Tuesday, August 21st 2012 @ 04:48:17 AM
Script : http://forum.xxxxxxx.ru/cron.php?rand=1338179327
Referrer : http://forum.xxxxxxx.ru/activity.php
IP Address : xxx.xxx.xxx.xxx
Username : Незарегистрированный
Classname : vB_Database
MySQL Version :

Зайдя phpmyadmin я ужаснулся кол-ву созданных таблиц с названиями типа taggregate_temp_1338177360, которых было не просто много, а очень и очень много и каждая создавалась каждый раз, когда на форум кто-то заходил и пытался смотреть тему. И в момент пересчета счетчика просмотров и вываливалась эта ошибка, одновременно с этим в базе появлялась новая пустая таблица.

Из найденных советов было и проверить есть ли переменная $cronimage в файле шаблона, не потерт ли запрос к картинке активирующий крон. Все было в полном порядке, ошибка как и следовало из логов, заключалась конкретно в поврежденной таблице threadviews и только в ней!

Попытка просто сделать оптимизацию и восстановление таблиц базы данных, особого успеха не принесла, причем ни как средствами самого форума, так ни средствами phpmyadmin. Так же провальной оказалась и попытка воспользоваться исправлением уникальных индексов, используя файл mysql-schema.php который так настоятельно предлагает применить сам форум.

Решение оказалось простым. Скачав с личного кабинета дистрибутив форума и взяв из него папку INSTALL со всем ее содержимым, мне понадобился лишь один файл mysql-schema.php, чуть ранее оказавшийся бесполезным, где и был взят запрос создающий поврежденную таблицу.

Предварительно удалив поврежденную таблицу threadviews через phpmyadmin, далее в нем же, переключившись на вкладку выполнения SQL запросов, ввел команду на создание нужной мне таблицы.

CREATE TABLE prefixname_threadviews (
threadid INT UNSIGNED NOT NULL DEFAULT '0',
KEY threadid (threadid)
)

В моем случае префикс был не нужен, поэтому все лишнее из запроса было убрано.

CREATE TABLE threadviews (
threadid INT UNSIGNED NOT NULL DEFAULT '0',
KEY threadid (threadid)
)

а для attachmentviews запрос такой:

CREATE TABLE attachmentviews (
attachmentid INT UNSIGNED NOT NULL DEFAULT '0',
KEY postid (attachmentid)
);

Вставляем в поле Выполнить SQL-запрос(ы) к базе данных: и жмем ок. Дождавшись сообщения об успешном выполнении запроса, можно переключаться на вкладку структуры базы и выделив все таблицы, для профилактики сделать оптимизацию и восстановление таблиц.

Вуаля, и все работает как надо. Теперь каждый посетитель форума не вызывает кучу ошибок и не происходит захламление сервера логами ошибок, а в базе не плодятся ошибочные таблицы taggregate_temp_1338177360 и прочие. Все на все занимает ну минут 5 не больше.

З.Ы
Как я рад, что в свое время так и не воспользовался vBulletin 4.x.x, а остался на vBulletin 3.x.x =)

Be First to Comment

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *