Экстренный ремонт MySQL таблиц

Проблема такая. Точнее проблеммлять много.

1. Очень часто выдается сообщение об ошибке MySQL: MySQL server has gone away. Причем делается это на элементарных запросах и, к счастью, не часто. Не понятно как это ремонтировать. Подсказка в мануале MySQL не помогла.

2. Вообще звиздец, а не ошибка. Table './base/table' is marked as crashed and should be repaired. Обычно, такое получается через некоторое время после первого пункта. Туеву хучу форумов перелазил, а ответ везде один и тот же. Используйте REPAIR TABLE. Спасибо, так гораздо лучше :) Известно, как чинить, но не известно, как сделать, чтобы не ломалось. Если кто-то подскажет, то будет супер!

3. Еще ошибка Incorrect key file for './base/table' try to repair it. Спасибо. Спасибо...

В это время сайт, в общем-то, считается лежачим. И здесь задача победить все эти невзгоды. Запускал в кроне на интервал 5-10 минут проверку таблиц и их ремонт (рекорд: 4 дня без сбоев). Вроде как все нормально, но сайт все равно по несколько минут лежит. И мне это не нравится :)

Тогда возникла идея, модернизировать класс для работы с БД. Благо он очень примитивный. В нем имеется некий метод query(). Просто переписываем его.

Алгоритм такой:
1. Добавляем еще 1 параметр в метод для счета запросов, по умолчанию он равен 1.
2. Проверяем наличие ошибки в запросе при помощи mysql_error().
3. Если ошибка синтаксиса (бывает при разработке), то просто записываем ее.
4. Если сервер has gone away, то "спим" 5 секунд, опять коннектимся к базе и снова вызываем сами себя (рекуррентно). При этом увеличиваем счетчик запросов на 1. Чтобы смотреть сколько мы уже боремся с проблемой.
5. Если нужно ремонтировать таблицы, то делаем это, "спим" 1 секунду и снова вызываем сами себя.
6. Учитываем, что не нужно вечно стараться победить проблему, несколько раз не вышло - идем пинать себя или хостера и разбираться сами.


Итак, заготовка класса лежит здесь. Она лишь служит пояснением для алгоритма, в любом случае ее немного придется переделывать. Также вам понадобится функция для определения IP адреса. Я ее вкрутил в лог ошибок, на всякий случай. Функция определяет реальный IP адрес, если не используется анонимный прокси (тогда не определить). Ее явтор не я и, к сожалению не знаю кто.

Что в итоге получили? Ремонтируем сразу после поломки. Ремонтом занимается 1 посетитель, которому больше всех не повезло :). В качестве Д/З нужно(!) сделать самостоятельно проверку, чтобы запуск ремонта не осуществлялся несколько раз подряд, если это не необходимо. Например, сломалась таблица и 2 юзера зашли на сайт практически одновременно. Я сознательно убрал защиту с примера.