MySQL で誤って削除したテーブルデータを回復する方法 (必読)

バックアップがあれば、非常に簡単です。最新のバックアップデータを生成し、mysqlbinlog を使用してバックアップ時点以降のデータを取得し、現在のネットワークに復元するだけです。

バックアップがない場合、面倒なことになり、データの取得コストも非常に高くなります。

バックアップ時点以降のデータを取得するために mysqlbinlog を使用する方法は次のとおりです。

簡単な実験として、mysql テーブルデータを削除し、mysqlbinlog を使用して削除したテーブルのデータを取得します。

アプリテーブルの作成時間とデータの挿入時間: 2013-02-04 10:00:00

原則: mysqlbinlog

前提条件: mysql で bin ログが有効になっている

削除をテストする前に:

mysql> テーブルを表示します。
+-----------------------+
| レポート内のテーブル |
+-----------------------+
| アプリ |
| テスト |
+-----------------------+

mysql> now() を選択します。
+---------------------+
| 今() |
+---------------------+
| 2013-02-04 11:45:44 |
+---------------------+
セット内の1行（0.01秒）


mysql> アプリから count(1) を選択します。
+----------+
| カウント(1) |
+----------+
| 10 |
+----------+
セット内の1行（0.01秒）

データの削除を開始します:

mysql> id =1 のアプリから削除します。
クエリは正常、1 行が影響を受けました (0.00 秒)

マイSQL> 
mysql> ID < 6 のアプリから削除します。
クエリは正常、4 行が影響を受けました (0.01 秒)


mysql> アプリから count(1) を選択します。
+----------+
| カウント(1) |
+----------+
| 5 |
+----------+
セット内の 1 行 (0.00 秒)

 

mysql> now() を選択します。
+---------------------+
| 今() |
+---------------------+
| 2013-02-04 12:08:45 |
+---------------------+

データの取得を開始します:

1. bin ログの場所を見つけます。

/app/mysql/ログ

-rw-rw---- 1 mysql mysql 17K 2月4日 11:43 alert.log
-rw-rw---- 1 mysql mysql 1.0K 11月1日 14:52 master-bin.000001
-rw-rw---- 1 mysql mysql 126 12月25日 14:00 master-bin.000002
-rw-rw---- 1 mysql mysql 126 12月25日 14:02 master-bin.000003
-rw-rw---- 1 mysql mysql 126 12月25日 14:02 master-bin.000004
-rw-rw---- 1 mysql mysql 107 12月25日 14:02 master-bin.000005
-rw-rw---- 1 mysql mysql 13K 2月4日 12:02 master-bin.000006

最近変更されたbinログはmaster-bin.000006だけであることがわかります。

(誤って削除したデータが複数の bin ログにまたがる場合は、bin ログを取得するときにデータを 1 つずつ取得する必要があります。)

この期間中に実行されたすべての SQL ステートメントを、復元する SQL ファイルに保存します。

mysqlbinlog --start-date='2013-02-04 10:00:00' --stop-date='2013-02-04 12:08:45' /app/mysql/log/master-bin.000006 >/app/mysql/mysql_restore_20130204.sql

もちろん、現在のネットワーク環境では、この時間はそれほど正確ではない可能性があり、他のトランザクション SQL ステートメントからの干渉がある可能性があります。

一時データベースの作成

データベース for_bak を作成します。

現在のデータベースアプリで誤って削除されたテーブルをエクスポートします

mysqldump -uroot -ppwd my_db アプリ > /app/mysql/app.sql

現在のデータを一時テーブルにインポートします。

mysql -root -ppwd for_bak < /app/mysql/app.sql

/app/mysql/mysql_restore_20130204.sql の内容の一部を見てみましょう: (悪意のある削除ステートメントが確認できます)

タイムスタンプを 1359949544/*!*/ に設定します。
始める
//*!*/;
# 12878 で
#130204 11:45:44 サーバー ID 1 end_log_pos 12975 クエリ thread_id=5 exec_time=974 error_code=0
タイムスタンプを 1359949544/*!*/ に設定します。
ID = 1 のアプリから削除
//*!*/;
# 12975 で
#130204 11:45:44 サーバー ID 1 end_log_pos 13002 Xid = 106
専念 /*！*/;
# 13002 で
#130204 11:45:44 サーバー ID 1 end_log_pos 13077 クエリ thread_id=5 exec_time=1013 error_code=0
タイムスタンプを 1359949544/*!*/ に設定します。
始める
//*!*/;
# 13077 で
#130204 11:45:44 サーバー ID 1 end_log_pos 13175 クエリ thread_id=5 exec_time=1013 error_code=0
タイムスタンプを 1359949544/*!*/ に設定します。
ID < 6 のアプリから削除
//*!*/;
# 13175 で
#130204 11:45:44 サーバー ID 1 end_log_pos 13202 Xid = 107
専念 /*！*/;
区切り文字 ;
# ログファイルの終了

データがいつ削除されたかを確認できます。特定の時刻は、select from_unixtime(1359949544); を使用して照会することもできます。

幸いなことに、create table app ステートメントと insert ステートメントもこのファイルに含まれています。削除ステートメントを手動で削除した後、一時データベースのmysqlbinlogから取得したSQLファイルをソースします。

これにより、アプリは削除される前の状態に復元されます。次に、一時ライブラリ内のデータを既存のネットワークデータにインポートします (これはこの記事の焦点ではありません)。

バックアップがない場合、特に binlog ファイルが多く、それぞれが比較的大きい場合は、アプリテーブルに関連するすべてのデータを取得するのが非常に面倒になる可能性があります。

その場合、アプリの作成から現在までのアプリテーブルに関連する DML 操作の SQL レコードを、mysqlbinlog を使用して 1 つずつ取得し、データを統合して復元するしかありません。

一般的にこのような状況はまれだと思います。面倒ではありますが、復旧不可能ではありません。

MySQL で誤って削除されたテーブルデータを回復する方法 (必読) に関する上記の記事は、私が皆さんと共有したいことのすべてです。この記事が皆さんの参考になれば幸いです。また、123WORDPRESS.COM をサポートしていただければ幸いです。

以下もご興味があるかもしれません: