誤って削除されたデータを復元するための mysqlbinlog コマンドを使用した mysql の実装

実験環境:

MYSQL 5.7.22

バイナリログを有効にする

ログ形式 MIXED

実験プロセス:

1. 実行: FLUSH LOGS;

master-bin.000014ファイルは新しく生成されたファイルです

ログを更新する目的は、実験内容をより直感的にし、実験プロセス全体の内容を観察しやすくすることです。

REST MASTER を使用する記事をオンラインで多数見てきましたが、このコマンドの重要性については説明されていません。

このコマンドは、すべてのログファイルを削除し、ファイル名とログポイントをゼロにリセットします。99% の場合、このコマンドは必要ありません。

ログを削除するには、PURGE MASTER LOGSを使用できます...これはより安全です

2. 新しいログファイルが生成されました。まずは内容を確認してみましょう。理解しておくべき点がいくつかあります。

バイナリログファイルを表示するコマンド: mysqlbinlog master-bin.000014

# 4時
#180903 16:19:12 サーバー ID 1 end_log_pos 123 CRC32 0xe03659b3 開始: binlog v 4、サーバー v 5.7.22-log 作成 180903 16:19:12

まず、上の 2 つの矢印を見てください。

# 4（イベント開始地点）
#180903 16:19:12 (時刻を表す)
サーバー ID 1 (マスタースレーブレプリケーションを実行する場合、各 MYSQL データベースに一意の SERVER ID を指定する必要があります。設定しておらず、デフォルトは 1 です)
end_log_pos 123 (イベント終了ポイント)

下の 2 つの矢印を見てください。

# 123 (イベント開始点、上記のイベント終了点に対応)
end_log_pos 154 (イベント終了ポイント)
4時から123時までのコンテンツはイベントコンテンツです

3. ビジネスシナリオをシミュレートし、テーブルを作成し、データを挿入し、最後にテーブルを削除します。現実的にするために、2 つのデータベースを作成し、異なるデータベースに同時にコンテンツを書き込み、最後にデータベースの 1 つでテーブルを削除しました。

mysql> ログをフラッシュします。
クエリは正常、影響を受けた行は 0 行 (0.01 秒)

mysql> データベース t1 を作成します。
クエリは正常、1 行が影響を受けました (0.03 秒)

mysql> データベース t2 を作成します。
クエリは正常、1 行が影響を受けました (0.00 秒)

mysql> t1 を使用します。
データベースが変更されました
mysql> テーブル t1 (id int) を作成します。
クエリは正常、影響を受けた行は 0 行 (0.03 秒)

mysql> t2 を使用します。
データベースが変更されました
mysql> テーブル t2 (id int) を作成します。
クエリは正常、影響を受けた行は 0 行 (0.03 秒)

mysql> t2値に挿入（3）;
クエリは正常、1 行が影響を受けました (0.01 秒)

mysql> t2値に挿入（4）;
クエリは正常、1 行が影響を受けました (0.01 秒)

mysql> t1 を使用します。
データベースが変更されました
mysql> t1値に挿入（1）;
クエリは正常、1 行が影響を受けました (0.01 秒)

mysql> t1値に挿入（2）;
クエリは正常、1 行が影響を受けました (0.01 秒)

mysql> t2 を使用します。
データベースが変更されました
mysql> t2 に値を挿入します(20);
クエリは正常、1 行が影響を受けました (0.01 秒)

mysql> t1 を使用します。
データベースが変更されました
mysql> t1 に値を挿入します(10);
クエリは正常、1 行が影響を受けました (0.01 秒)

mysql> テーブル t1 を削除します。
クエリは正常、影響を受けた行は 0 行 (0.02 秒)

mysql> t2 を使用します。
データベースが変更されました
mysql> t2 に値(222)を挿入します。
クエリは正常、1 行が影響を受けました (0.01 秒)

マイSQL>

T1 および T2 ライブラリを作成し、T1 および T2 テーブルを作成します。

T1にデータを挿入: 1、2、10

T2にデータを挿入: 3、4、20、222

シミュレーションシナリオでは、テーブル T1 は削除されますが、データベース T2 内のテーブル T2 のビジネスは引き続き実行されます。

ここで、ログを通じて T1 テーブルを復元します。

まず、削除コマンドのログポイントを見つけます。

mysqlbinlog master-bin.000014|grep -5a "テーブルを削除"

#AT 2439 を参照してください (この番号を書き留めてください)

このイベントポイントで実行された DROP TABLE 操作。

ログファイルには T1 データベースのログだけでなく、T2 データベースのログも含まれているため、T1 データベースのログのみを取得します。

そして、ログポイント2439より前のログのみが取得され、再適用されます。

2439 ログが取得された場合、データベースはデータベースとテーブルを再構築し、データを挿入し、再度適用されたときにテーブル削除ステートメントを実行します。

mysqlbinlog -d t1 --stop-position=2439 master-bin.000014>test.sql (このステートメントの実行時にエラーが報告されました)

警告: オプション --database が使用されています。トランザクションの一部をフィルター処理する可能性がありますが、いずれの場合も GTID が含まれます。トランザクションを除外または含める場合は、代わりにそれぞれオプション --exclude-gtids または --include-gtids を使用する必要があります。
今のところ理由はわかりませんので、Baiduで検索して次のように修正しました。

mysqlbinlog マスターbin.000014 -d t1 --skip-gtids --stop-position=2439>test.sql

-d: パラメータはデータベースログを指定します

このコマンドは、master-bin.000014ログファイル内のT1データベースログ、イベントポイント2439より前のログをtest.sqlに出力することを意味します。

# 末尾のテスト.sql

ファイルの最後の数行を見てください

データベースにログインします:

mysql> t1 を使用します。
データベースが変更されました

mysql> ソース test.sql

データベース T1 を構築するためのステートメントが含まれていたため、途中でエラーが 1 回報告されました。

表の内容をもう一度確認してください

このようにしてデータが返されます。

これで、mysqlbinlog コマンドを使用して誤って削除されたデータを回復する方法に関するこの記事は終了です。mysqlbinlog を使用して誤って削除されたデータを回復する方法の詳細については、123WORDPRESS.COM で以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

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