强制 innodb 恢复损坏的数据库

Question

一个设计不佳的脚本从两个现有表中选择记录，并将记录添加到新创建的表中，持续了 24 小时，直到我通过终止 MySQL 5.6 命令行客户端并重新启动服务器来杀死它。我估计该脚本向新表中插入了超过 7000 万行。结果是service.msc不会启动MySQL服务。我采取了各种步骤来解决这个问题，包括删除日志文件和文件myservername.err，然后重新启动服务器。新myservername.err文件包含一长串重复警告，指出我需要强制进行 innodb 恢复，因为数据库已损坏。我怎样才能做到这一点？

我想要：

1.) start the corrupted database, and then 
2.) do a rollback to the status of the database before the script was run.   

我可以选择一个时间点，也可以简单地删除新创建的表，因为自从一切正常以来数据库中的唯一活动就是运行设计不良的脚本。我需要采取哪些步骤来重新启动损坏的数据库，然后将数据库回滚到损坏前的状态？

我将错误日志上传到文件共享网站。您可以点击此链接来阅读。

我想我需要将以下行添加到 my.ini 中，紧接在 [mysqld] 行之后：

[mysqld]
innodb_force_recovery=?  

但我该用什么数字来代替呢?？那么我应该使用什么代码来进行回滚呢？我只是简单地写吗drop table new_table_name？或者我是否执行回滚命令到特定日期？（我将日志文件移至不同的文件夹，因此我需要重新导入日志文件吗？）这在代码中会是什么样子？

---

编辑：

---

我完成了 mysqldump，然后将目录的内容移动/data到备份位置。然后，我将/data/MySQL子目录内容移回到/mysql空/data目录的子目录中。但是当我尝试启动 MySQL Windows 服务器时，我得到了error 1067. 我将新创建的文件的内容上传myservername.err到文件共享网站。 这是查看错误日志的链接。

Answer 1

InnoDB 抱怨 LSN 错误，因为 ib_logfile-s 被删除。你不应该删除那些。但在那之后 MySQL 仍然可以生存。下次 InnoDB 更新页面时，它将覆盖标头中的 LSN，并且错误消息将消失。等待启动即可（错误日志显示启动既不成功也不成功）。

要获得 100% 干净的表空间，您需要使用 innodb_force_recovery=4 启动 MySQL，获取 mysqldump 并将其恢复到一个新的 InnoDB 实例上（我所说的“新鲜”是指您必须删除 ibdata1 和所有数据库目录）。

更新：

此时MySQL启动为innodb_force_recovery=x (x != 0)

• 转储所有数据库：

   # mysqldump --skip-lock-tables -A > alldb.sql
  

• 检查 MySQL 保存文件的位置（在我的例子中是/var/lib/mysql/）：

   # mysql -NBe "SELECT @@datadir"
   /var/lib/mysql/
  

• 停止MySQL

   # mysqladmin shut
  

• 将旧的 MySQL 文件移至安全位置

   # mv /var/lib/mysql /var/lib/mysql.old
  

• 创建新的系统目录

   # mkdir /var/lib/mysql
   # chown mysql: /var/lib/mysql
  

• 初始化新的系统目录

   # mysql_install_db
  

  注意：如果mysql_install_db显示一些错误，请运行以下命令：

   # mysqld --initialize
  

• 启动MySQL

   # /etc/init.d/mysql start
  

• 恢复转储

   # mysql < alldb.sql
  

如果数据库很大，恢复可能需要很长时间。在这种情况下，另一个技巧可能会起作用。在每个 InnoDB 表上运行 ALTER TABLE ... ENGINE INNODB。它将重建所有 InnoDB 索引，因此错误将消失。