☰

复制 /var/lib/mysql 文件导致 InnoDB 损坏

tag-icon • tag-icon mysql innodb corruption
复制 /var/lib/mysql 文件导致 InnoDB 损坏

我的服务器昨天必须重新安装，所以他们更换了硬盘并通过 USB 连接了旧硬盘。我获取了数据库文件 (/var/lib/mysql) 并下载了它们，然后删除了本地测试服务器的所有数据库文件并将其替换为实时服务器中的数据库文件。

一开始一切都运行正常，然后我注意到几个表显示为“正在使用”。我发现 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

我确实需要这些文件才能工作，因此非常感谢您的任何建议。

答案1

哇，你真的对数据库造成了很大影响。你可以通过复制 MySQL 数据文件来恢复，但听起来你用力过猛了。正确的做法是：

  • 确保 MySQL没有运行在您要恢复的机器上。四次检查以ps确保没有类似 MySQL 的东西潜伏。如果需要，请启动到单用户模式。如果 MySQL 正在运行，您将会遇到各种各样的问题。
  • 复制两者的内容/var/lib/mysql（或 MySQL 数据所在的位置），也您的服务器正在使用的配置my.cnf。在运行 InnoDB 时，确保配置相同非常重要，因为（正如您所指出的）否则 InnoDB 将无法工作。（关键参数是您的 InnoDB 日志大小/计数/等，以及每个表的文件 - 如果它们不同，您真的无处可去）。

当您启动服务器时，特别是当您要恢复一台突然意外报废的机器时，服务器需要一段时间才能启动并运行，因为它需要进行各种内部一致性检查（相当于fsck），然后才能投入使用。

答案2

正如@womble 所说，但有一点补充：

innobackupex使用创建备份并将其移动到新服务器非常有用：

第一次运行：

innobackupex /path/to/backupfiles

成功后：

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

这会创建一个可用的基于文件的备份（仅需要复制的内容），即使是从正在运行的服务器中创建。

相关内容