mysql容災
我們剛剛遇到了一場大災難：有人對生產數據庫進行了不受控制的更新，很明顯，備份過程很長時間以來都無法正常工作，因此我們遭受了重大數據失去。一個 4000 萬行的表現在充滿了垃圾。
有人有恢復數據的想法嗎？例如，使用文件系統恢復的工具？
事實：
- ext3 fs（在 Debian 上）
- InnoDB 引擎（在 Mysql 5.0 上）
老實說，這不是我們公司的第一次重大災難，但這很可能是最後一次。我們通常會想出一些主意來挽救局面，但這一次，我真的沒有主意了。集群f*ck…
編輯：問題發生在沒有 where 的更新語句之後。問題是，這個問題發生在周一下午和周二早上（法國時間）之間，直到今天才被發現，由於各種原因（應用程序提供了一個同步工具，所以插入了新數據和現在失去的數據，但是外鍵在另一張桌子現在完全壞了）。所以實際上，表中幾乎所有的行（除了新插入的）都包含相同的數據（除了 id 列）。
關於 ibdata* 和 ib_logfile*，我停止了複製伺服器，所以它們保持原樣。我無法停止主伺服器上的數據庫來複製文件。
2小時沒有答案？我認為這可能只是因為沒有人願意告訴你這個消息。
您是否在任何地方都擁有良好的數據副本（即使是一兩個月前的數據）？如果不是，那麼恐怕你就是 SOL。您已經提到了數據庫的同步副本，因此如果在執行錯誤的 UPDATE 語句之前取消了同步，您將需要創建一個語句來使用源 B 的該表的數據更新源 A。
（我曾經有過這種情況，使用 MSSQL 和日誌傳送，幸運的是能夠在站點 B 上恢復壞數據之前停止日誌傳送，並且只是在伺服器之間執行了一個 UPDATE 語句來撤消我的錯誤）。
正如 Marc B 所提到的，如果您啟用了二進制日誌記錄（並且日誌尚未被截斷），您可能能夠通過重播該日誌來恢復一些數據（即使您有一個非常舊的數據庫副本，如果你的日誌是完整的，你會沒事的），但這可能有點偶然。