我们刚刚遭遇了一场大灾难：有人对生产数据库进行了不受控制的更新，显然，备份过程很久以来一直无法正常工作，因此我们遭受了重大数据丢失。 4000 万行的表现在充满了垃圾。
有人知道如何恢复数据吗？例如，使用文件系统恢复的工具？
事实：
- ext3 fs（在 Debian 上）
- InnoDB 引擎（在 Mysql 5.0 上）
老实说，这不是我们公司第一次发生重大灾难，但这次很可能是最后一次。我们通常会想出一些办法来挽救局面，但这次，我真的想不出主意了。真是一团糟……
编辑：问题发生在没有 where 的更新语句之后。问题是，问题发生在周一下午到周二早上（法国时间）之间，今天才发现，原因多种多样（应用程序提供了同步工具，因此新数据会插入到现在丢失的数据中，但另一个表中的外键现在已完全损坏）。因此实际上，表中的几乎所有行（新插入的行除外）都包含相同的数据（id 列除外）。
关于 ibdata* 和 ib_logfile*，我停止了复制服务器，所以它们保持原样。我无法停止主服务器上的数据库来复制文件。
答案1
2 个小时了还没答复？我想可能是因为没人愿意告诉你这个消息。
你有一份完整的数据副本吗任何地方（即使是一个月或两个月前的数据）？如果没有，那恐怕你就完蛋了。你提到了数据库的同步副本，因此如果在执行错误的 UPDATE 语句之前取消了同步，你将需要创建一个语句来使用源 B 的该表数据更新源 A。
（我曾经遇到过这种情况，使用 MSSQL 和日志传送，幸运的是能够在站点 B 上恢复错误数据之前停止日志传送，并且只需在服务器之间执行 UPDATE 语句即可撤消我的错误）。
正如 Marc B 提到的，如果您启用了二进制日志记录（并且日志没有被截断），您可能能够通过重播该日志来恢复部分数据（即使您拥有数据库的真正旧副本，如果您的日志是完整的，那就没问题），但这可能有点碰运气。