происходит ли сбой InnoDB при аварийном завершении работы

#php #mysql #database #innodb #myisam

#php #mysql #База данных #innodb #myisam

Вопрос:

Я создал небольшое приложение с MySQL. Тип базы данных — InnoDB. И он размещен на каком-то сервере. Я сталкиваюсь с сбоем базы данных так много раз. Когда я спросил причину у хостинг-провайдера, они сказали мне:

Проблема была вызвана повреждением базы данных InnoDB, что потребовало перестройки всех таблиц InnoDB. Некоторые базы данных не были перестроены должным образом, например, ваша, и это требовало исправления вручную. Это то, что я сделал. Никаких изменений с вашей стороны не требуется. Мы не ожидаем, что проблема повторится в ближайшее время. Приносим извинения за причиненные неудобства.

Я сказал им, что мне нужно использовать InnoDB, потому что мне нужны отношения с первичным и внешним ключами, которые связаны с InnoDB. Теперь они говорят:

Ну, это правильно, MyISAM не поддерживает внешние ключи. На самом деле таблицы на основе InnoDB подвержены повреждению, если MySQL отключается ненормально, например, в случае жесткой перезагрузки или около того. Вместо этого MyISAM более надежен, и восстановление его таблиц легко.

Мой ВОПРОС: таблицы на основе InnoDB подвержены повреждению, если MySQL отключается ненормально, это правильно?

Комментарии:

1. MyISAM также подвержен этому. Если MySQL не завершит запись ни в InnoDB, ни в MyISAM — таблицы будут повреждены. То же самое с едой — забудьте готовить ее достаточно долго — это отстой. Смена блюда с A на B не менее подвержена плохому приготовлению. Вас должно беспокоить то, почему происходит ненормальное завершение работы. Ваш хост, прямо скажем, отстой — найдите лучшего хостинг-провайдера (пахнет для меня как неизбежный сбой жесткого диска в конце).

Ответ №1:

Предполагая настройки MySQL по умолчанию, они явно неверны.

Но если вы:

  • отключить двойной буфер записи
  • отключить контрольные суммы страниц
  • innodb_flush_log_at_trx_commit <> 1
  • включить политику кэша обратной записи без батареи
  • список можно продолжить

вы получите InnoDB, который действительно подвержен повреждению.