InnoDB 日志序列号在未来

Question

我们的网站出现间歇性数据库错误，我要求我的网络主机检查发生了什么。经过一番检查，他们发现数据库几乎没有问题，并尝试修复它。最后我收到了他们的以下消息-

我已经尝试了对 InnoDB 数据库的每一次修复，我们仍然得到 InnoDB 日志序列号是未来的。此时，为了让 ibdata 和 iblogfile 再次匹配，我们需要从服务器上的备份中恢复 MySQL 目录（包括数据库）。这个过程应该不会花很长时间，但会有一些与这样的恢复相关的停机时间。如果这不是恢复 MySQL 目录的最佳时间，我可以将其安排在不同的时间。请告诉我您希望如何处理此问题。

有人可以告诉我解决这个问题的最佳方法是什么。我真的不想丢失任何数据并希望修复 dB。

PS：如果您需要更多信息，请告诉我，我会从我们的网络主机上获取。

非常感谢您的帮助。

Answer 1

到目前为止，向您建议的是可以采取哪些措施使数据库达到一致状态。

以下是您需要了解的有关 InnoDB 的信息。

首先这里是图示形式的 InnoDB 架构

看图。哪些组件主要用于 InnoDB 的自我修复（听起来比崩溃恢复更好）？

• 双写缓冲区具有用于恢复的已更改块的缓存。
• 插入缓冲区处理对非唯一索引的更新
• InnoDB 事务日志 (ib_logfile0,ib_logfile1) 包含同样用于恢复的重做回放信息。
• 有undo日志（1023个，最大并发事务数）

您需要三个文件进行恢复

• ibdata1
• ib_logfile0
• ib_logfile1

整个datadir文件夹 ( /var/lib/mysql) 需要从备份的同一时刻开始恢复。如果没有datadir来自同一时刻的物理副本，则永远无法正确引用未来事务的日志序列号。

如果您在这件事上不信任您的主机，也许您可​​以通过将innodb_force_recovery设置为适当的值来启动 MySQL 。

以下是MySQL 文档中的值

1 (SRV_FORCE_IGNORE_CORRUPT)

即使检测到损坏的页面，也让服务器运行。试图让 SELECT * FROM tbl_name 跳过损坏的索引记录和页面，这有助于转储表。

2 (SRV_FORCE_NO_BACKGROUND)

阻止主线程和任何清除线程运行。如果在清除操作期间发生崩溃，此恢复值会阻止它。

3 (SRV_FORCE_NO_TRX_UNDO)

崩溃恢复后不运行事务回滚。

4 (SRV_FORCE_NO_IBUF_MERGE)

防止插入缓冲区合并操作。如果它们会导致崩溃，则不执行它们。不计算表统计信息。

5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

启动数据库时不查看撤消日志：InnoDB 甚至将不完整的事务视为已提交。

6 (SRV_FORCE_NO_LOG_REDO)

不执行与恢复相关的重做日志前滚。

一旦你选择了你想要的值，用它启动 MySQL。然后，对所有数据执行 mysqldump。将该 mysqldump 保存在某处。

• 我将innodb_force_recovery设置为 6。重新启动 mysql。做 mysqldump (MyData6.sql)
• 改成5.重启mysql。做 mysqldump (MyData5.sql)
• 将其更改为 4. 重新启动 mysql。做 mysqldump (MyData4.sql)
• 将其更改为 3. 重新启动 mysql。做 mysqldump (MyData3.sql)
• 改成2。重启mysql。做 mysqldump (MyData2.sql)
• 将其更改为 1. 重新启动 mysql。做 mysqldump (MyData1.sql)

根据可以恢复的数量，您现在拥有 6 个数据快照。然后，您必须将每个 MySQLDump 加载到一个单独的 MySQL 实例中。然后，您必须仔细阅读数据并确定是否已恢复足够的数据。Percona 有一个数据恢复工具包，可以比我说的更有效地完成所有这些工作。

我的答案只是一个穷人的方法。

我希望这有帮助 ！！！