netwindGallemarnetwind,меня просто бросили на сервер с формулировкой "Сделай так чтобы проблем не было". А опыта работы с мускулем нету,админил только Firebird и MS SQL
передай им, что прогрессивное сообщество программистов сайта SQL.RU отказывается расхлебывать кадровые ошибки.

надо таки понять в чем причина сбоев


Мужики, предлагаю не нападать на спрашивающего.
ну не знает человек, но пытается узнать...
ну невозможно все всем знать... насчет кадров,
что -- никого никогда не брасали на незнаконые участки?

По теме (в основном повторю что сказано выше):

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

Быстрое восстановление:

1. поднять на тойже машине или на соседней машине
репликационный сервер. Переключение будет состоять в
том что поменять адресс/порт в аппликации
(у нас так сделано)

2. Заранее создать дубликат рабочей директории и
подменить, переназвать директории при сбое.
Ну или скопировать когда надо
(сам такое никогда не делал)

3. использовать готовые программы
(не обязательно быстрее но надежнее)

Разбирательство по сбою:

1. разборка логов мыскл-а, лог медленых запросов
2. логи системы
3. лог аппликации
4. монитор компютера: ЦПУ, память, нетвок, И/О....
5. Монитор аппликации

Успехов.

vkle,

ок, интересная информация. спасибо

Gallemarnetwind,сервер лежит на VmWare, диагностировать сбои по железу сложно.

Где искать логи на виндовсе:
http://dev.mysql.com/doc/refman/5.5/en/windows-troubleshooting.html

с VMWare -- вообше просто -- скопировать весь фаил и поднять его когда основной сломался.
Локально диск сам на себя будет писать со скоростью 50-100М/с,
(САТА-3 может даже быстрее), Гигабайт в 12 секунд, 5г-1мин, 250г в час

netwind, и другив намекают вам что просто так ничего не падает и
всегда можно и НАДО выяснить в чем проблема.
Иначе вы непрерывно будете поднимать падающий сервер.