Назад | Перейти на главную страницу

Копирование файлов / var / lib / mysql привело к повреждению InnoDB

Вчера мой сервер пришлось переустановить, поэтому они заменили жесткий диск и подключили старый через USB. Я взял файлы базы данных (/ var / lib / mysql) и загрузил их, а затем стер все файлы db для моего локального тестового сервера и заменил их на файлы с моего живого сервера.

Сначала все работало нормально, а затем я заметил, что несколько таблиц отображаются как «используемые». Я обнаружил, что InnoDB не работает должным образом, и в конце концов обнаружил, что исправление заключалось в удалении файлов ib_logfile0 и ib_logfile2. Теперь мой сервер MySQL не запускается, и я получаю следующие ошибки:

110716 10:19:04  mysqld started
110716 10:19:04 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
110716 10:19:04 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
110716 10:19:04  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
110716 10:19:04  InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 0000000000000000cd12deee693d9fd84ee8bdf2000000070000000000000000000000006935b4760000000000000000000000000000000000000000180000000000000013ee000000000000034f000000000000000d0a00000008000000090000000d0a0000000b0000000c0000$
110716 10:19:05  InnoDB: Page checksum 3392292161, prior-to-4.0.14-form checksum 3716350408
InnoDB: stored checksum 0, prior-to-4.0.14-form stored checksum 0
InnoDB: Page lsn 1323875826 7, low 4 bytes of lsn at page end 0
InnoDB: Page number (if stored to page already) 0,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 26933
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
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 InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
110716 10:19:05  mysqld ended

Мне действительно нужны эти файлы для работы, поэтому я очень ценю любые советы.

Вау, вы действительно сделали номер в своей базе данных. Вы можете восстановить, скопировав файлы данных MySQL, но похоже, что вы использовали слишком много молотка. Как это сделать:

  • Убедитесь, что MySQL НЕ РАБОТАЕТ на машине, которую вы пытаетесь восстановить. Четырехместный чек с ps чтобы убедиться, что ничего подобного MySQL не скрывается. При необходимости загрузитесь в однопользовательском режиме. Если MySQL запущен, вы получите много чего.
  • Скопируйте оба содержимого /var/lib/mysql (или где бы то ни было ваши данные MySQL), так же как то my.cnf что ваш сервер использовал. Важно убедиться, что конфигурация такая же при запуске InnoDB, потому что (как вы заметили) иначе InnoDB не будет работать. (Ключевыми параметрами являются размер вашего журнала InnoDB / количество / и т. Д. И количество файлов для каждой таблицы - если они разные, вы действительно никуда не денетесь).

Когда вы запускаете что-то, особенно если вы восстанавливаете машину, которая умерла насильственной и преждевременной смертью, ожидайте, что серверу потребуется некоторое время, чтобы начать работу, поскольку он должен выполнять всевозможные проверки внутренней согласованности (эквивалент из fsck) до того, как он будет готов к эксплуатации.

Как сказал @womble, но с небольшим дополнением:

Действительно полезно создать резервную копию с помощью innobackupex, и переместите это на новый сервер:

первый забег:

innobackupex /path/to/backupfiles

и после этого:

innobackupex --apply-log /path/to/backupfiles

Это создаст пригодную для использования резервную копию на основе файлов (которую нужно только скопировать) даже с работающего сервера.