URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID8
Нить номер: 7194
[ Назад ]

Исходное сообщение
"Потерял innodb таблицы после некорретной перезагрузки"

Отправлено VArtem , 11-Апр-11 14:34 
Все работало, до того, как ночью вырубали свет. На утро, когда свет вернулся - обнаружил, что при попытке доступа к innodb таблицам - выходит сообщение, подобное этому:

ERROR 1146 (42S02): Table 'db1.UserSettings' doesn't exist


При попытке REPAIR TABLE

mysql> REPAIR TABLE bp_UserSettings;
+-------------------------+--------+----------+-----------------------------------------------+
| Table                   | Op     | Msg_type | Msg_text                                      |
+-------------------------+--------+----------+-----------------------------------------------+
| db1.UserSettings        | repair | Error    | Table 'db1.UserSettings' doesn't exist    |
| db1.UserSettings        | repair | status   | Operation failed                              |
+-------------------------+--------+----------+-----------------------------------------------+
2 rows in set (0.00 sec)


В логе ошибок пишется:
110411 13:23:38 [ERROR] Cannot find or open table db1/UserSettings from
the internal data dictionary of InnoDB though the .frm file for the
table exists. Maybe you have deleted and recreated InnoDB data
files but have forgotten to delete the corresponding .frm files
of InnoDB tables, or you have moved .frm files to another database?
or, the table contains indexes that this version of the engine
doesn't support.
See http://dev.mysql.com/doc/refman/5.1/en/innodb-troubleshootin...
how you can resolve the problem.

Немогу понять, как простая перезагрузка выбила из строя все таблицы innodb, и каким образом можно восстановить таблицы.  Есть бэкап папки с базой данных, т.е. Db1, но замена ничего не дала.


Содержание

Сообщения в этом обсуждении
"Потерял innodb таблицы после некорретной перезагрузки"
Отправлено Michael , 11-Апр-11 14:41 
>[оверквотинг удален]
> table exists. Maybe you have deleted and recreated InnoDB data
> files but have forgotten to delete the corresponding .frm files
> of InnoDB tables, or you have moved .frm files to another database?
> or, the table contains indexes that this version of the engine
> doesn't support.
> See http://dev.mysql.com/doc/refman/5.1/en/innodb-troubleshootin...
> how you can resolve the problem.
> Немогу понять, как простая перезагрузка выбила из строя все таблицы innodb, и
> каким образом можно восстановить таблицы.  Есть бэкап папки с базой
> данных, т.е. Db1, но замена ничего не дала.

show engines покажите


"Потерял innodb таблицы после некорретной перезагрузки"
Отправлено VArtem , 11-Апр-11 15:01 
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine     | Support | Comment                                                        | Transactions | XA   | Savepoints |
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
| InnoDB     | YES     | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| MRG_MYISAM | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| BLACKHOLE  | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| CSV        | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| MEMORY     | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| FEDERATED  | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
| ARCHIVE    | YES     | Archive storage engine                                         | NO           | NO   | NO         |
| MyISAM     | DEFAULT | Default engine as of MySQL 3.23 with great performance         | NO           | NO   | NO         |
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
8 rows in set (0.01 sec)

"Потерял innodb таблицы после некорретной перезагрузки"
Отправлено VArtem , 11-Апр-11 16:01 
Судя по-всему каким-то образом похерились данные в ibdata1. Причем неизвестно как, т.к. до перезагрузки было все норм.

Вот что пишет лог, сразу после появления света:


110411 10:44:38 mysqld_safe Starting mysqld daemon with databases from /var/db/mysql
110411 10:44:39 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
110411 10:44:39  InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
110411 10:44:41  InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
110411 10:44:43  InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
110411 10:44:44  InnoDB: Started; log sequence number 0 0
110411 10:44:44 [Note] Event Scheduler: Loaded 0 events
110411 10:44:44 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '5.1.48'  socket: '/tmp/mysql.sock'  port: 3306  FreeBSD port: mysql-server-5.1.48


Хотел уточнить у знающих людей, если есть еще хоть какая-то мало-мальская надежда вернуть данные, или можно начинать кропотливую работу по заполнению их по-новой?


"Потерял innodb таблицы после некорретной перезагрузки"
Отправлено Michael , 12-Апр-11 00:38 

> Хотел уточнить у знающих людей, если есть еще хоть какая-то мало-мальская надежда
> вернуть данные, или можно начинать кропотливую работу по заполнению их по-новой?

если только посекторно анализировать диск, задачка не из легких.