Итак, случился «Ой». БД не запускается. Что делать?
- Смотрим размер ib_logfile0 файла:
|
root@pavel-All-Series:/var/lib/mysql# ls -l drwxrwxrwx 2 root root 4096 авг. 31 14:22 bugify -rwxrwxrwx 1 root root 79691776 авг. 31 13:56 ibdata1 -rwxrwxrwx 1 root root 67108864 авг. 31 13:56 ib_logfile0 -rwxrwxrwx 1 root root 67108864 июля 3 04:38 ib_logfile1 drwxrwxrwx 2 mysql mysql 4096 авг. 31 14:21 mysql -rwxrwxrwx 1 root root 6 авг. 31 14:21 mysql_upgrade_info drwxrwxrwx 2 mysql mysql 4096 авг. 31 14:21 performance_schema drwxrwxrwx 2 mysql mysql 4096 авг. 11 2014 phpmyadmin |
2. Запускаем mysql:
|
mysqld --innodb_log_file_size=<размер ib_logfile0> --innodb_force_recovery=6 |
Если все хорошо Вы должны увидеть следующее:
InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on
InnoDB: Skipping log redo
070625 11:59:36 InnoDB: Started; log sequence number 0 0
InnoDB: !!! innodb_force_recovery is set to 6 !!!
070625 11:59:36 [Note] /usr/sbin/mysqld: ready for connections.
Version: ‘5.0.18’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 SUSE MySQL
Далее дампим поднявшуюся базу данных:
mysqldump -u root -p database > database.sql
Если Вы получите следующее сообщение, это значит, что файлы системного журнала Innodb повреждены:
Got error: 1146: Table ‘database.table’ doesn’t exist when using LOCK TABLES
Чтобы решить проблему с хранением ib_logfile0 файла нужна актуальная резервная копия, поэтому восстановите все файлы от старшей резервной копии. Это не безотказное решение, но ценная попытка.
Восстановите Ваши данные:
mysql -u root -p database < database.sql