(специфическое, mysql'ное)
читать дальшеКак у нас устроена жопа?
1. Вот есть у нас SQL-интерфейс к grep, mysql именуемый. Вот он летит, бухтит, шебуршит. И - БУМС!!! - ловит assertion failure.
Почему он его ловит? Много причин может быть. Например, в процессе работы он попытался получить больше памяти, чем система может выделить на процесс. Почему не отследить такую ситуацию при загрузке и проверке параметров - не знаю. Еще он обожает портить базы при переполнении диска. А хуле, что писать некуда? Ты же коммунист! И mysqld застрочил с новой силой.
2. Поймал он assertion failure, и, вестимо, упал по 11 сигналу. Не закрыв таблицы, остввив из в inconsistent state, то бишь, враскоряку.
3. Упал - отжался. mysqld_safe поднимает mysqld, чтобы тот дальше героически трудился. В принципе, нефигово бы перед этим проверить, а трудиться-то нам есть, над чем? Но - у швецких собственная борзость. Проверка делается только при начальном старте, и по умолчанию закомментирована. Итак, полетели мы с кривыми таблицами. Пока можем работать - работаем.
4. Очнулся - гипс. Эта иддилия может продолжаться довольно долго. Пока, например, нам не приспичит делать репликацию. Репликация в некоторый момент встанет колом. Нужно делать REPAIR TABLE.
А восстановление таблицы может занять и 10 часов, и 20. На моей памяти некая таблица не прочекалась за двое суток и была снесенах.
В сочетании с другими приколами от MySQL (лично мне встречались - обработка некорректных запросов и молчаливое обрезание слишком длинных данных) у меня возникает только один вопрос - какие же титаны духа умудряются делать на этой загогулине большие системы с 24x7?