Что вызвало бы потерю данных во время ТАБЛИЦЫ ВОССТАНОВЛЕНИЯ в использовании MySQL MyISAM?
Документация MySQL для ТАБЛИЦЫ ВОССТАНОВЛЕНИЯ указывает это
Лучше делать резервное копирование таблицы прежде, чем выполнить восстановление таблицы; при некоторых обстоятельствах операция могла бы вызвать потерю данных. Возможные причины включают, но не ограничены ошибками файловой системы.
Я хотел бы знать, существуют ли какие-либо другие причины потери данных помимо ошибок файловой системы. Кто-либо видел, что это происходит в дикой природе? Как, вероятно, это, что восстановление потеряет данные, если не будет никаких ошибок файловой системы?
Моя определенная ситуация следующие. У меня есть сервер Sun T5120 под управлением Солярис 10 (SPARC), и использую MySQL 5.1.30. У меня есть таблица, которая использует механизм MyISAM, который иногда становится поврежденным. Некоторые времена, что таблица была повреждена, произошли из-за неожиданных перебоев в питании в нашей системе разработки, которая не имела UPS. Я не уверен, что все повреждение происходило из-за перебоев в питании, таким образом, могут быть некоторые дополнительные причины, что это происходит. Такой как причины, перечисленные здесь.
Я хотел бы установить автоматическое решение для восстановления в случае, если эти подозреваемые "дополнительные причины" происходят в производственной системе или производстве сбои UPS. Я мог установить задание крона для выполнения mysqlcheck --auto-recover как предлагается в этом ответе, или я мог изменить свой процесс, который вставляет в ту таблицу для мгновенного выполнения REPAIR TABLE EXTENDED управляйте, когда это обнаружит повреждение. Однако оба из тех подходов использование REPAIR TABLE и, таким образом, восприимчивы к потере данных.
Я мог скопировать таблицу прежде, чем делать попытку восстановления, как документация предполагает, но таблица является довольно большой, и я не уверен, что буду иметь пространство в наличии для резервного копирования. Я сделал некоторый поиск, но не нашел объяснения почему REPAIR TABLE вызвал бы потерю данных помимо того, что упоминается в документации. Так это, вероятно, что восстановление потеряет данные, когда у Вас будет система звукового файла, или документация просто осторожна?
3 ответа
Одна из перечисленных возможных причин в руководстве по MySQL является ошибкой в программном обеспечении. Вам следует прочитать примечания к выпуску / историю изменений от вашей версии вперед, чтобы узнать, были ли исправлены ошибки в коде таблицы восстановления, а также прочитать примечания к выпуску новых версий по мере их выхода.
Из интереса, как ваш процесс, вставляющий данные, обнаруживает повреждения?
Дополнительная мера, которую вы можете предпринять для защиты от потери данных, - это создание резервных копий и включение журнала репликации. В случае сбоя вы можете восстановить базу данных из резервной копии, а затем использовать журнал репликации, чтобы вернуть базу данных в состояние, в котором она находилась в момент сбоя.
В конечном итоге, если это производственная система, вам действительно нужно позаботиться о хорошем источнике питания, а также иметь вторую машину, действующую как репликатор.
Это не вероятно , что ТАБЛИЦА РЕМОНТА повредит данные, но они, конечно, не могут этого гарантировать. Возможно, мне просто не повезло, но я знаю, что MySQL очень плохо обрабатывает почти полную файловую систему. Недостаток места на диске - одна из тех ситуаций, в которых я ожидал, что REPAIR TABLE будет делать странные вещи.
Я провел достаточно обширный поиск в списках исправленных ошибок MySQL и известных проблем из версии 5.1 и выше и немного из предыдущих версий. Я нашел несколько причин, по которым при восстановлении таблицы могут быть потеряны данные.Кажется, что ни один из них не применим к моей конкретной ситуации, поэтому мне, вероятно, не нужно слишком сильно беспокоиться. Надеюсь, это будет полезная информация для кого-то еще.
Ошибка № 338
Таблица REPAIR USE_FRM приводит к потере данных в случае ее уничтожения
Влияет на версию: Все
Это никогда не исправлялось, потому что на самом деле это не ошибка. (и вполне понятное) ограничение системы.
Ошибка №10437
После большого удаления таблицы восстановление приводит к потере данных !!!
Затрагивает версию: 4.1.11
Это запись восстановления, усекающая таблицу до нуля после того, как в таблице было много удалений. Последнее действие на эта ошибка возникла в мае 2005 г., и проблема не могла быть воспроизведена в 4.1.14, так что она, возможно, уже была решена.
Ошибка № 29980
Влияет на версию: 5.1.20
Кажется, происходит только в MySQL 5.1.20 и предыдущих версиях, и только когда вы указываете {{1} } Опция USE_FRM. Кроме того, причиной повреждения в этом случае было обновление MySQL до версии 5.1.20, поэтому я не думаю, что это может случиться со мной.
Ошибка № 41385
Сбой при попытке восстановить обновленную таблицу # mysql50 # с помощью триггеров
Влияет на версию: 5.1.30
Это может произойти, если имя таблицы содержит «расширенные символы» и имя базы данных имеет префикс # mysql50 #, как это бывает при обновлении MySQL 5.0 до 5.1. Исправление было перенесено в выпуск 5.1.31, поэтому для меня это не должно быть проблемой.
Отправляйте сообщения на форумы MySQL, которых я не нашел в системе отслеживания ошибок.
Восстановление таблицы слияния приводит к потере данных.
Влияет на версию: 5.0.37
Очевидно, таблица слияния с несколькими подтаблицами может привести к потере данных, если вы выберете из таблицы слияния во время восстановления подтаблицы.
Связанные лакомые кусочки:
Различные обсуждения и инструкции , которые я прочитал, все, кажется, указывают на то, что проблемы с оборудованием являются основной проблемой для повреждения таблиц. Кроме того, как Мартин упомянул в комментарии к его ответу , вы можете получить повреждение из-за большого количества одновременных подключений.
Еще одна вещь, на которую следует обратить внимание, - это свободное место. Я видел некоторый комментарий о том, что вам нужно достаточно свободного места для размера стола, который вы ремонтируете, чтобы ремонт работал. Я предполагал, что он выполнит ремонт на месте, и, возможно, текущие версии MySQL делают это, но я, возможно, не смогу избежать необходимости в дополнительном пространстве для резервных копий.