|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Доброго времени суток. Произошла не большая проблема, требуется восстановить удаленные данные из ibdata1. Прописываю в конфиге innodb_force_recovery = 1...6 , или в консоли, в итоге одна и та же ошибка, понять не могу в чем дело.
151214 14:46:24 InnoDB: Page checksum 1580297401, prior-to-4.0.14-form checksum 4268898232
InnoDB: stored checksum 2886167173, prior-to-4.0.14-form stored checksum 2886167173
InnoDB: Page lsn 21 1010950563, low 4 bytes of lsn at page end 1010950563
InnoDB: Page number (if stored to page already) 12,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 4
InnoDB: (index "CLUST_IND" of table "SYS_FIELDS")
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 12.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.5/...-recovery.html
InnoDB: about forcing recovery.
InnoDB: wrong number of columns in SYS_INDEXES record
151214 14:46:24 InnoDB: Waiting for the background threads to start
151214 14:46:25 InnoDB: 1.1.8 started; log sequence number 0
151214 14:46:25 InnoDB: !!! innodb_force_recovery is set to 6 !!!
151214 14:46:25 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
151214 14:46:25 [Note] - '127.0.0.1' resolves to '127.0.0.1';
151214 14:46:25 [Note] Server socket created on IP: '127.0.0.1'.
151214 14:46:25 [Note] Event Scheduler: Loaded 0 events
151214 14:46:25 [Note] \usr\local\mysql-5.5\bin\mysqld.exe: ready for connections.
Version: '5.5.25' socket: '' port: 3306 MySQL Community Server (GPL)
Отредактированно riko5 (15.12.2015 09:49:41)
Неактивен
Ошибка есть, но служба при этом запустилась. SELECT из табличек работает? Если да — сделайте резервную копию (mysqldump), пересоздайте хранилище innodb (удалить ibdata* iblogfile*), перезапустите службу и перезалейте резервную копию (под виндоус не уверен, но полагаю, что mysql < dumpfile должен сработать).
Неактивен
paulus написал:
Ошибка есть, но служба при этом запустилась. SELECT из табличек работает? Если да — сделайте резервную копию (mysqldump), пересоздайте хранилище innodb (удалить ibdata* iblogfile*), перезапустите службу и перезалейте резервную копию (под виндоус не уверен, но полагаю, что mysql < dumpfile должен сработать).
К сожалению SELECT не работает, пишет что то вроде этого 1033 Incorrect information in file: './site/spravka_stat.frm, в графе пишет "используется"
Неактивен
Про графу не понял — в какой графе?
Если ему не нравится frm, то его, возможно, надо восстановить или пересоздать. У Вас есть резервные копии?
Неактивен
Как я поглядел по таблице, ее размер 6,7гб, но там не все данные, данных там на 1гб только... Я так понимаю удаленные данные просто весят в этой таблице.
Неактивен
paulus написал:
Про графу не понял — в какой графе?
Если ему не нравится frm, то его, возможно, надо восстановить или пересоздать. У Вас есть резервные копии?
Графа таблици, где вместо веса базы пишет "используеться". Бекап таблицы самой есть, но подмена не помогает.
Неактивен
Подмена файлика frm? Должна помогать, если версия MySQL не менялась. Не менялась ведь?
Если файлик ibdata побился, то достать все данные, скорее всего, не получится. Кажется, лучшим решением будет восстановить резервную копию, а потом долить сверху те данные, которые удается достать из восстановленной базы.
Неактивен
paulus написал:
Подмена файлика frm? Должна помогать, если версия MySQL не менялась. Не менялась ведь?
Если файлик ibdata побился, то достать все данные, скорее всего, не получится. Кажется, лучшим решением будет восстановить резервную копию, а потом долить сверху те данные, которые удается достать из восстановленной базы.
Хм, как раз на винде стоит 5.5, а на centos стоит 5.7, сейчас буду собирать конфиг тогда под 5.7 версию. подменяю файлик frm, и таблица тут же пуста говорит.
Неактивен
Хм, все настроил, проверил в таблице 25 мил. записей, как и должно быть, начал сливать дамп в итоге только 13 мил. слилось.
Почему то не видит этих данных.
Ошибки при сливе данных не было.
Отредактированно riko5 (16.12.2015 11:42:43)
Неактивен
мб, я не так описал что произошло, или не так сделал.
Дело было так, решил Удалить данные, "Delete from name_table", когда поглядел что не ту таблицу указал, было уже поздно) вместо 25 мил. стало 13мил, как я понимаю данные есть в базе но они весят в воздухе... т.к. размер базы не уменьшился.
Подумал что можно из одно таблицы перенести в другую данные, но увы, не получилось.
mysql> INSERT INTO `site`.`spravka_stat_2` SELECT * FROM `site`.`spravka_stat`;
Query OK, 25295408 rows affected, 65535 warnings (8 min 47.47 sec)
Records: 25295408 Duplicates: 0 Warnings: 12641128
Отредактированно riko5 (16.12.2015 12:14:18)
Неактивен
Все, я понял. База не билась, просто Вы удалили лишние данные. Тогда хорошего прогноза нету. Файлики innodb не уменьшаются, но при этом могли перестроиться деревья, на которых висят строки, и тогда до данных добраться будет сложно. Из файликов добыть данные — достаточно трудоемкий процесс, и у него нет никаких гарантий.
Отправная точка — видимо, innodb recovery tool. Основная идея — найти странички, которые содержат данные, но помечены удаленными, и достать из них данные.
Неактивен
paulus написал:
Все, я понял. База не билась, просто Вы удалили лишние данные. Тогда хорошего прогноза нету. Файлики innodb не уменьшаются, но при этом могли перестроиться деревья, на которых висят строки, и тогда до данных добраться будет сложно. Из файликов добыть данные — достаточно трудоемкий процесс, и у него нет никаких гарантий.
Отправная точка — видимо, innodb recovery tool. Основная идея — найти странички, которые содержат данные, но помечены удаленными, и достать из них данные.
Я так понимаю программы под windows нет, только под линукс
Неактивен
Вроде как получилось достать данные без innodb tool, но не пойму как теперь решить проблему с датой, даты все сбиты... и они в формате таком. '1899-00-É5 É5:É5:É5'
Неактивен
не подскажете как обновить данные, а то что-то не получается, перенести часть дат,
Неактивен
Неактивен
Как достал удаленные данные, создал таблицу MYSAM, при этом автоинкремен убрал, и через INSERT INTO данные перенес из оригинальной таблицы в другу, при этом почему то даты уже шли в формате. тип у дат выставлен timestamp
Неактивен
rgbeast написал:
update spravka_stat_3 JOIN spravka_stat USING (id) SET spravka_stat_3.crdate = spravka_stat.crdate;
Благдарю, сейчас попробую
Неактивен
Никто не подскажет ?
Неактивен
А не подошел запрос, который писал rgbeast? Или какая сейчас стоит проблема?
Неактивен
paulus написал:
А не подошел запрос, который писал rgbeast? Или какая сейчас стоит проблема?
Да проблема сейчас в другом, даты в не правильном формате перенеслись.
Таблица создана правильно, только сменен тип таблицы и тип поля у даты с timestamp на varchar, почему то и в бд они не в том формате лежат, почему то вместо даты вообще не те стоят.
По умолчанию у типа данных выставлено CURRENT_TIMESTAMP
Сейчас поглядел в оригинальной таблице через консоль, даты и там не правильные стоят...
Возможна ли данная ошибки из-за time zone ?
Отредактированно riko5 (22.12.2015 14:19:07)
Неактивен
Сделал не много по другому, прямо на сервере создал новую таблицу и перенес данные, как бы теперь перенести из одной таблицы данные, в другую, при чтоб не было задвоения... а то думаю что может идти задвоение данных, хоть и с разными id
Неактивен
Выберите те поля, по которым хотите избавиться от «задвоения» и сгруппируйте по ним?
Неактивен
