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

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

Авг. 09, 2008 // 02:31 | Комментарии (4)