我的服务器不得不在昨天重新安装，所以他们更换了硬盘，并通过USB连接了旧的。 我抓住数据库文件（/ var / lib / mysql）并下载它们，然后删除本地testing服务器的所有数据库文件，并将其replace为来自我的活动服务器的数据库文件。
一开始一切正常，然后我注意到有几个表显示为“正在使用”。 我发现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数据文件来恢复，但是听起来就像是用了一点点的木槌。 正确的做法是：
ps进行四重检查，以确保没有像MySQL一样潜藏的东西。 如果必须启动进入单用户模式。 如果MySQL正在运行，你将会pipe理各种各样的东西。 /var/lib/mysql （或者你的MySQL数据所在的位置）的内容， 以及你的服务器正在使用的my.cnf 。 在运行InnoDB时确保configuration是一样的，因为（正如你所指出的）否则InnoDB不起作用。 （关键的参数是你的InnoDB日志大小/计数/等，每个文件表 – 如果它们不同，你真的不会去哪里）。 当你开始时，特别是如果你正在恢复一台死于暴力和不合时宜的死亡机器，那么服务器需要一段时间才能启动并运行，因为它需要进行各种内部一致性检查（相当于的fsck ）之前，它已经准备好了服务。
正如@ womble所说的，但是有一点补遗：
用innobackupex创build备份非常有用，并将其移至新服务器：
第一次运行：
innobackupex /path/to/backupfiles
并成功后：
innobackupex --apply-log /path/to/backupfiles
这将创build一个可用的基于文件的备份（只需要复制）即使从运行的服务器。