Помогите, братья сисадмины и программисты.
Поставил на сервер (SuSe ES9) сначала mySQL4.0, потом mySQL5.0, в обоих случаях одна и та же проблема:после перезагурзки сервера падают таблицы, не все, скорее те, в которые недавно добавлялись записи. При проверке выдаёт, например такое:
myisamchk: error: Record at: 1892 Can't find key for index: 1
MyISAM-table '/usr/local/mysql/data/digmedia/schedule.MYI' is corruptedили вот, после mysqlcheck:
digmedia.schedule
error : Record at pos: 1956 is not remove-marked
error : record delete-link-chain corrupted
error : Corruptdigmediatest.logs
warning : Size of datafile is: 3864 Should be: 3808
error : Found 73 keys of 72
error : Corrupt
если восстановить, то в таблице не будет последних записей, сделанных перед перезагрузкой. Таблица простейшая, MyISAM.Не могу найти причину такого поведения. На соседнем сервере стоит ASPLinux + mySQL 3.18, всё отлично.
При перезагрузке mysqld вроде бы корректно завершает работу.
Менять версию с mysql 4.0 на 4.1 и более старшую через бинарные файлы базы данных является недопустимым. Сперва следует сделать mysqldump баз данных и залить на вновь поднимаемый сервер. Версии 5.0.x и далее имеет еще более значительные различия в структуре хранения MyISAM таблиц, чем 4.1.x от 4.0.x. Версия 4.0.x почти не отличияется от 3.x.x форматом хранения MyISAM таблиц, тогда как отличия версии 5.x и версий 4.1.x связаны:
- с тем, что хранение текстовых данных ведется в utf формате;
- cтало возможным хранение varchar полей превышающих размер 255 байт;
- претерпела значительные изменения структура самого индекса.
>Менять версию с mysql 4.0 на 4.1 и более старшую через бинарные
>файлы базы данных является недопустимым. Сперва следует сделать mysqldump баз данных
>и залить на вновь поднимаемый сервер. Версии 5.0.x и далее имеет
>еще более значительные различия в структуре хранения MyISAM таблиц, чем 4.1.x
>от 4.0.x. Версия 4.0.x почти не отличияется от 3.x.x форматом хранения
>MyISAM таблиц, тогда как отличия версии 5.x и версий 4.1.x связаны:
>
>- с тем, что хранение текстовых данных ведется в utf формате;
>- cтало возможным хранение varchar полей превышающих размер 255 байт;
>- претерпела значительные изменения структура самого индекса.
Дело в том, что на база данных создавалась на этом же сервере с уже установленным из дистрибутива SLES9 mysql 4.0, т.е. с нуля. И сразу же появились эти проблемы. При установке 5.0 согрешил :) скопировав бинарники базы, но потом нужную базу пересоздал путём дампа. Глюк остался неизменным.Такие заметки ещё. База (да и система) лежит в массиве с железным зеркалированием. Если сервер не перегружать неделю например, то после перезагрузки исчезнут только последние записи. Т.е. в базу всё же пишется информация, но вот когда - не понятно. SELECT @@AUTOCOMMIT показывает "1".
А теперь самая фишка: загоняю в базу данные, делаю
rcmysql stop
rcmysql startвсе данные на месте, все таблицы целы.
Делаю reboot, пару талиц в crash, данные которые загонял - исчезли.Делаю
rcmysql stop
rebootОпять, таблицы в краше, данных нет.
Т.е. либо SLES при перезагрузке портит файлы, либо на железном уровне? :(
Сделал проверку диска - повреждённых файлов нет...
>>Менять версию с mysql 4.0 на 4.1 и более старшую
>Такие заметки ещё. База (да и система) лежит в массиве с
>железным зеркалированием. Если сервер не перегружать неделю например, то после перезагрузки
>исчезнут только последние записи. Т.е. в базу всё же пишется информация,
>но вот когда - не понятно. SELECT @@AUTOCOMMIT показывает "1".на уровне продположения: железный рейд не успевать сбросить кеш. В качестве решения можно предложить создать rc.d скрипт, который по команде stop должен вызывать плавное опускание БД, сброс буферов (sync), отключение файловой системы, и задержка (sleep) на некоторое время, в течении которого кеш рейда должен успеть сброситься на диск(и). Пока выполняется rc.d, система не завершает перезагрузку ресетом системы. Если есть утилиты по управлению райдом, доступными через API Linux системы, то лучше воспользоваться именно ими. А конкретно - нужна команда сброса кеша на диск.