История изменений
Исправление firkax, (текущая версия) :
Перейдя на MyISAM будешь постоянно видеть сообщения о том что таблица заблокирована
Ни разу не видел. Это у innodb такие бывают наоборот - когда между двумя транзакциями deadlock получается и одну из них приходится откатывать и делать заново. Нет транзакций - нет и этих проблем. Просто подождать, и в большинстве случаев - совсем немного (например 100мс, если там конечно какой-то тяжёлый запрос неграмотно не всунули куда не следует). Для уже упомянутых сайтов уровня яндекса, понятное дело, ситуация другая, но их это обсуждение не касается.
придется отказаться от транзакциий, любимых тобой foreign keys, ACID’а
И чем это грозит для стандартного пхп-веба (посмотри его другие темы) типа форумов и гостевух?
нормального кэширования и буфферизации
Это ещё с чего?
невозможно будет сделать консиситентный бэкап без остановки mysql
Ну да.
ну и при порче данных таблицу сложнее будет восстанавливать без транзакционного лога
А в данном случае mysql абсолютно правильно себя повел не запустившись с базой в которой есть ошибки - этим он ее защитил от возможной порчи пока еще целых данных.
А давай у автора спросим, что он предпочтёт в случае таких ситуаций:
1) база отказывается запускаться и заставляет хозяев устраивать муторную ручную возню по «правильному» восстановлению данных, при этом возможно что-то таки потеряется, но скорее всего очень мало (последние транзакции, которые не успели записаться никуда перед крашем)
2) база принудительно запускается, как может фиксит сама все несостыковки, а там где сложно - тупо выкидывает мешающие данные, зато ручной возни не требуется и его онлайн-сервис снова онлайн; при этом вероятность и количество потерь в среднем больше чем в первом варианте, но всё ещё в среднем маленькое и тоже затрагивающее только те места, где что-то менялось в последние минуты перед сбоем.
Исправление firkax, :
Перейдя на MyISAM будешь постоянно видеть сообщения о том что таблица заблокирована
Ни разу не видел. Это у innodb такие бывают наоборот - когда между двумя транзакциями deadlock получается и одну из них приходится откатывать и делать заново. Нет транзакций - нет и этих проблем. Просто подождать, и в большинстве случаев - совсем немного (например 100мс). Для уже упомянутых сайтов уровня яндекса, понятное дело, ситуация другая, но их это обсуждение не касается.
придется отказаться от транзакциий, любимых тобой foreign keys, ACID’а
И чем это грозит для стандартного пхп-веба (посмотри его другие темы) типа форумов и гостевух?
нормального кэширования и буфферизации
Это ещё с чего?
невозможно будет сделать консиситентный бэкап без остановки mysql
Ну да.
ну и при порче данных таблицу сложнее будет восстанавливать без транзакционного лога
А в данном случае mysql абсолютно правильно себя повел не запустившись с базой в которой есть ошибки - этим он ее защитил от возможной порчи пока еще целых данных.
А давай у автора спросим, что он предпочтёт в случае таких ситуаций:
1) база отказывается запускаться и заставляет хозяев устраивать муторную ручную возню по «правильному» восстановлению данных, при этом возможно что-то таки потеряется, но скорее всего очень мало (последние транзакции, которые не успели записаться никуда перед крашем)
2) база принудительно запускается, как может фиксит сама все несостыковки, а там где сложно - тупо выкидывает мешающие данные, зато ручной возни не требуется и его онлайн-сервис снова онлайн; при этом вероятность и количество потерь в среднем больше чем в первом варианте, но всё ещё в среднем маленькое и тоже затрагивающее только те места, где что-то менялось в последние минуты перед сбоем.
Исходная версия firkax, :
Перейдя на MyISAM будешь постоянно видеть сообщения о том что таблица заблокирована
Ни разу не видел. Это у innodb такие бывают наоборот - когда между двумя транзакциями deadlock получается и одну из них приходится откатывать и делать заново. Нет транзакций - нет и этих проблем. Просто подождать, и в большинстве случаев - совсем немного. Для уже упомянутых сайтов уровня яндекса, понятное дело, ситуация другая, но их это обсуждение не касается.
придется отказаться от транзакциий, любимых тобой foreign keys, ACID’а
И чем это грозит для стандартного пхп-веба (посмотри его другие темы) типа форумов и гостевух?
нормального кэширования и буфферизации
Это ещё с чего?
невозможно будет сделать консиситентный бэкап без остановки mysql
Ну да.
ну и при порче данных таблицу сложнее будет восстанавливать без транзакционного лога
А в данном случае mysql абсолютно правильно себя повел не запустившись с базой в которой есть ошибки - этим он ее защитил от возможной порчи пока еще целых данных.
А давай у автора спросим, что он предпочтёт в случае таких ситуаций:
1) база отказывается запускаться и заставляет хозяев устраивать муторную ручную возню по «правильному» восстановлению данных, при этом возможно что-то таки потеряется, но скорее всего очень мало (последние транзакции, которые не успели записаться никуда перед крашем)
2) база принудительно запускается, как может фиксит сама все несостыковки, а там где сложно - тупо выкидывает мешающие данные, зато ручной возни не требуется и его онлайн-сервис снова онлайн; при этом вероятность и количество потерь в среднем больше чем в первом варианте, но всё ещё в среднем маленькое и тоже затрагивающее только те места, где что-то менялось в последние минуты перед сбоем.