|
|
|
| Здравствуйте.
Вчера, после произвольной перезагрузки машины перестал запускаться демон mysqld со следующим сообщением в /var/log/mysqld.log:
080719 9:57:38 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 21 1939551941.
InnoDB: Doing recovery: scanned up to log sequence number 21 1939585024
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 2 row operations to undo
InnoDB: Trx id counter is 0 1878061568
080719 9:57:38 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 [...] 98 99 080719 9:57:39 - mysqld got signal 11;
|
Тип и размер базы: InnoDB, 36Gb
Версия MySQL -- 5.0.45 (x86_64)
Ядро -- Linux 2.6.25.10-47.fc8 #1 SMP Mon Jul 7 18:31:41 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
Дистрибьютив -- Fedora Core 8 с последними обновлениями
Безуспешно пробовали:
перенос базы на машину такой же конфигурации
проверку таблиц с помощью innochecksum
увеличение/уменьшение размеров буферов InnoDB в конфиге mysqld.
Посоветуйте, что ещё можно поробовать/на что поглядеть для оживления убитого монстрика? | |
|
|
|
|
|
|
|
для: Maximbo
(19.07.2008 в 11:41)
| | Переносить файлы действительно бесполезно - табличное пространство InnoDB привязано к конкретной машине. К сожалению, шансы восстановиться возрастают, только если заранее озаботиться проблемой - включить бинарный журнал, снять дамп базы данных и засечь точку создания дампа в бинарном журнале. Тогда развернув дамп, можно заставить MySQL выполнить операции из бинарного журнала до точки краха. | |
|
|
|
|
|
|
|
для: cheops
(19.07.2008 в 12:31)
| | >табличное пространство InnoDB привязано к конкретной машине
Ничего себе счастье. Можно об этом чуть подробнее? | |
|
|
|