Mysqlディザスタリカバリ
大きな災害が発生しました。誰かが本番データベースで制御されていない更新を行いましたが、明らかに、バックアッププロセスが長い間機能していないため、大きなデータ損失が発生しました。 4,000万行のテーブルがゴミでいっぱいになりました。
誰かがデータを復元するアイデアを持っていますか？たとえば、ファイルシステムリカバリを使用するツール？
事実：
- ext3 fs（Debian上）
- InnoDBエンジン（Mysql 5.0上）
正直なところ、これは当社にとって最初の大災害ではありませんが、これは簡単に最後の災害になる可能性があります。私たちは通常、その日を救うためのアイデアを思いつきますが、今回は本当にアイデアがありません。 Clusterf * ck .. ..
編集：問題は、whereのない更新ステートメントの後に発生しました。問題は、問題は月曜日の午後と火曜日の朝（フランス時間）の間に発生し、さまざまな理由で今日のみ発見されたということです（アプリケーションは同期ツールを提供しているため、新しいデータは現在欠落しているデータとともに挿入されますが、外部キーは別のテーブルが完全に壊れています）。したがって、実際には、テーブル内のほぼすべての行（新しく挿入されたものを除く）に同じデータが含まれています（id列を除く）。
Ibdata *とib_logfile *については、レプリケートされたサーバーを停止したため、現在のままです。メインサーバー上のデータベースを停止してファイルをコピーできません。
2時間で答えがない？それは、誰もあなたにニュースを伝えようとしないからかもしれないと思います。
データの適切なコピーがありますかどこにでも（1か月か2か月前のものでも）？いいえの場合は、SOL恐れ入ります。データベースの同期されたコピーをほのめかしているので、不正なUPDATEステートメントが実行される前に同期が停止された場合、そのテーブルのソースBのデータでソースAを更新するステートメントを作成する必要があります。
（私はこれをMSSQLとログ配布で一度持っていましたが、サイトBで不良データが復元される前にログ配布を停止でき、サーバー間でUPDATEステートメントを実行して間違いを元に戻しました）。
Marc Bが述べたように、バイナリロギングが有効になっている（そしてログが切り捨てられていない）場合、そのログを再生することでデータの一部を回復できる可能性があります（データベースの本当に古いコピーがある場合でも） 、ログが無傷であれば問題ありません）が、それは少し失敗する可能性があります。