Является ли механизм MyIsam более безопасным, чем InnoDB, в отношении потери данных из-за ошибки FileSystem?
Кажется, что InnoDB не поддается ремонту с помощью инструмента MySQL.
Мне пришлось выбрать свой движок, и я выбрал InnoDB из-за внешних ключей, но я рассмотрю миграцию движка, если это будет более безопасным.
InnoDB имеет очень сложную архитектуру в фоновом режиме
В случае сбоя InnoDB имеет буфер двойной записи и файлы журнала для поддержки механизмов восстановления после сбоя.MyISAM не имеет такой защиты. Я написал сообщения в DBA StackExchange об этом:
Oct 08, 2012 : MYSQL Внедрение восстановления данных MyISAMMar 19, 2012 : очень маленькая таблица MySQL продолжает падатьMar 15, 2012 : Почему происходит сбой таблиц MySQL?Как мне это предотвратить?Feb 16, 2012 : таблица MyISAM продолжает падать.Какие у меня варианты?MyISAM может аварийно завершить работу, поскольку данные никогда не кэшируются в памяти. Все операции чтения и записи требуют прямого ввода-вывода из таблиц MyISAM .MYD файл. Это означает, что дескрипторы открытых файлов находятся во власти ОС.
Если вы хотите, чтобы InnoDB был ремонтопригодным, вам нужно настроить my.cnf, чтобы сделать InnoDB менее зависимым от ОС и более зависимым от внутренней архитектуры. См. Мой недавний пост Высокая средняя загрузка из-за высокой загрузки процессора MySQL. Таким образом, InnoDB Crash Recovery может быть более самовосстанавливающимся.
Я бы использовал InnoDB из-за блокировок на запись против блокировок MyIsam на таблицу отверстий. Также InnoDB не требует ремонта инструмента, как уже было сказано ранее. Кроме того, движок InnoDB может сохранять таблицы в отдельных файлах, поэтому он выглядит более безопасным с точки зрения сбоя файловой системы.
Ошибки файловой системы или даже ошибки на уровне блоков не относятся к тем элементам, которые были тщательно протестированы или учтены при реализации MyISAM или Innodb. Хотя при их записи может произойти некоторое обнаружение, существует большое предположение, что то, что когда-то было записано без ошибок, верно. Контрольные суммы существуют и проверяются при чтении, но путь восстановления после ошибок на страницах / строках, которые не соответствуют контрольной сумме, я не думаю, что был полностью продуман.
Я подозреваю, что правильная стратегия снижения риска для этого (и некоторых других форм сбоя сервера) заключается в том, чтобы запустить ведомое устройство репликации в другой файловой системе и в качестве DR сохранить двоичные журналы и логический дамп снимка SQL. Таким образом, вам не нужно полагаться на инструменты, которые могут обойти некоторые формы сбоев с потерями данных.