In english Хотелка Об авторе

Что значит 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

И выставим клиенту счётик. Главное, чтобы рука не дрогнула, и ноликов в сумме не оказалось меньше, чем нам нужно.

Top

Категория: работа Слова: mysql, ERROR 1033, HY000, ошибки
@lj

Комментарии Отключены

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 [ ссылка ]