mysql灾难恢复

Question

我们刚刚遭遇了一场大灾难：有人对生产数据库进行了不受控制的更新，很明显，备份过程很长时间没有工作，所以我们丢失了重大数据。一个 4000 万行的表现在充满了垃圾。

有人有恢复数据的想法吗？例如，使用文件系统恢复的工具？

事实：

• ext3 fs（在 Debian 上）
• InnoDB 引擎（在 Mysql 5.0 上）

老实说，这不是我们公司的第一次重大灾难，但这很容易成为最后一次。我们通常会想出一些主意来挽救这一天，但这一次，我真的没有主意了。Clusterf*ck...

编辑：问题发生在没有 where 的更新语句之后。问题是，这个问题发生在星期一下午和星期二早上（法国时间）之间，今天才发现，因为各种原因（应用程序提供了一个同步工具，所以新数据插入了现在丢失的数据，但在另一张桌子现在完全坏了）。所以实际上，表中几乎所有行（新插入的除外）都包含相同的数据（id 列除外）。

关于 ibdata* 和 ib_logfile*，我停止了复制的服务器，所以它们保持现在的状态。我无法停止主服务器上的数据库来复制文件。

Answer 1

2个小时了还没有答案？我认为这可能只是因为没有人愿意向你透露这个消息。

您是否在任何地方都有一份完整的数据副本（即使是一两个月前的数据）？如果不是，那么恐怕你就是 SOL。您已经提到了数据库的同步副本，因此如果在执行错误的 UPDATE 语句之前取消同步，您将需要创建一个语句来使用该表的源 B 的数据更新源 A。

（我曾经遇到过这种情况，使用 MSSQL 和日志传送，幸运的是能够在站点 B 上恢复错误数据之前停止日志传送，并且只需在服务器之间执行 UPDATE 语句即可消除我的错误）。

正如 Marc B 提到的，如果您启用了二进制日志记录（并且日志尚未被截断），您可能可以通过重播该日志来恢复一些数据（即使您有数据库的非常旧的副本） ，如果你的日志完好无损，那就没问题了），但这可能有点偶然。