Что значит ERROR 1033 (HY000): для InnoDB?
MySQL — унылое говно не самая плохая СУБД. Простая (в простых вещах) и быстрая (в простых вещах). И куча типов таблиц, с которыми можно работать практически одинаково — это действительно здорово. Только кому это нахрен может быть нужно в простой и быстрой СУБД? Впрочем, мне было нужно. Помогло сэкономить клиенту сотню-другую баксов на лишнюю память. И обошлось этому клиенту в тысячи за несколько месяцев моей с ним возьни.
Впрочем, этот пост не о том, как я крут (тем более, что не так уж и), а о том, что стремление к универсальности неизбежно ведёт к какой-то херне различным ограничения. В случае с MySQL и его зоопарком storage engines, большинство из этих ограничений я представляю довольно смутно, потому пока не приходилось с ними сталкиваться, по крайней мере напрямую. Но вот сообщения об ошибках... Натерпелся я от них. Они видимо для единообразия сводятся к более общему набору, мало что говорящему о сути проблемы. Многим, думаю, знакомо шокирующее лаконичностью Got error XXX from storage engine. Или там ERROR 1033 (HY000)...
О! Точно. ERROR 1033 (HY000). Поговорим о ней, пожалуй.
mysql> select count(*) from child;
ERROR 1033 (HY000): Incorrect information in file: './test/child.frm'
Вот что это может значить? Винт посыпался? Просто файлик испортился? Гугление даёт довольно противоречивые результаты, в том числе и советы воспользоваться myisamchk.
Всё-таки удалось нагуглить, в чём именно проблема, если это InnoDB-таблица. Данные в InnoDB хранятся не отдельно для каждой таблицы, а в одном или нескольких файлах ibdata1, ibdata2, и т.д. (по умолчанию). Размеры этих файлов задаются в /etc/my.cnf вот в таком примерно виде:
innodb_data_file_path=ibdata1:512M;ibdata2:100M:autoextend
Так вот. Может оказаться, что /etc/my.cnf был изменён. Изменили эти значения. Или закомментировали строку, и MySQL принял значения по умолчанию. В моём случае оказалось именно так. В конфиге об InnoDB ни слова, а работать сервер отказывается, ссылаясь на ERROR 1033 (HY000).
Решилось это следующим образом.
Смотрим, какие файлы ibdata у нас есть:
-rw-rw---- 1 mysql mysql 1168113664 Aug 9 00:31 ibdata1 -rw-rw-- -- 1 mysql mysql 5242880 Aug 9 00:45 ib_logfile0 -rw-rw-- -- 1 mysql mysql 5242880 Aug 8 18:50 ib_logfile1 drwx--x--x 2 mysql mysql 4096 Mar 28 15:29 mysql srwxrwxrwx 1 mysql mysql 0 Aug 9 00:52 mysql.sock -rw-rw-- -- 1 mysql mysql 5 Jul 1 00:21 server10.pid
1168113664 – это 1114М. Так и запишем:
innodb_data_file_path=ibdata1:1114M;ibdata2:512M:autoextend
И перезапустимся:
# service mysql restart
И выставим клиенту счётик. Главное, чтобы рука не дрогнула, и ноликов в сумме не оказалось меньше, чем нам нужно.
Категория: работа Слова:
mysql,
ERROR 1033,
HY000,
ошибки
@lj
![[rss]](images/rss.gif)
I3k
В mysql есть достаточно полезная пременная:
innodb_file_per_table
которая позволяет хранить информацию о структуре и данные InnoDB таблиц в отдельных файлах.(в каталоге самой БД)
Если возникнут проблемы с InnoDB с какой то конкретной таблицей то поломается один файл а не все что в ibdata.
Плюс innodb_force_recovery попытать сделать дамп таблицы и заного её перезалить.
10.09.9642 // 12:19 [ ссылка ]
Ответ от Автора
Да, знаю, но никогда не пользовался, потому что и проблем с InnoDB особых никогда не было. И не знаю, как оно на производительности может сказаться. И лень было разбираться, как быть с уже имеющейся здоровенной базой, а экспериментировать – страшно. Вернусь домой – попробуй, пожалуй.
13.08.2008 // 10:53 [ ссылка ]
Ответ от Автора
В смысле, попробую.
13.08.2008 // 10:54 [ ссылка ]
I3k
innodb_file_per_table
имеет сысл ставить перед тем как начать создавать InnoDB таблицы.
Так же можно сделать дамп базы, и заного перезалить его.
14.08.2008 // 12:41 [ ссылка ]