MySQLはデータ復旧を実装するためにbinlogログを使用する

MySQL binlog は MySQL ログの中で非常に重要なログであり、データベースのすべての DML 操作を記録します。 binlog ログを通じて、データベースの読み取り/書き込み分離、データの増分バックアップ、サーバーがダウンした場合のデータ復旧を実行できます。

定期的なバックアップは、サーバーがクラッシュしたときにデータを迅速に復元できますが、従来のフルバックアップはリアルタイムで実行できないため、クラッシュが発生すると一部のデータが破損します。このとき、binlog をオンにしておけば、バックアップが行われなかった期間に失われたデータを binlog を通じて復元できます。 Redis に詳しい人は、Redis には AOF と RDB という 2 つの永続モードがあると思っているかもしれません。 RDB は MySQL の完全レプリケーションに似ており、AOF は MySQL の binlog に似ています。

データ復旧について一言。binlog はとても優れているので、binlog が有効になっている場合は定期的なバックアップを行う必要がないということでしょうか? これはしないでください。なぜでしょうか? binlog データの量が非常に大きいため、データ復旧に binlog を使用するとパフォーマンスが非常に低くなるからです。 binlog は操作の記録なので、例えばある瞬間に、まずデータを挿入して、その後データを削除しました。データ自体は消えていますが、操作は 2 つあります。フルバックアップであれば、そのようなデータは絶対に存在しません。binlog を使用する場合は、挿入と削除の操作を実行する必要があるため、パフォーマンスとファイルサイズが比較的大きくなります。

長々と話しましたが、データ復旧についてお話ししましょう。

正式に始める前に、MySQL データベースを完全にバックアップし、データベースを復元する方法について説明します。

データベースをバックアップします。

まず、データベースmytestを作成しましょう

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

次にテーブルを作成しましょう

mytest を使用します。
テーブル t1(id int 、name varchar(20)) を作成します。

次に2つのデータを挿入します

t1値に挿入します（1、 'xiaoming'）;
t1値に挿入します（2、 'xiaohong'）;

次に、mytestデータベースを/root/bakup/にバックアップします。

mysqldump -uroot -p -B -F -R -x --master-data=2 mytest | gzip > /root/backup/bak_$(date +%F).sql.gz

パラメータの説明:

-B: データベースを指定する

-F: ログを更新

-R: バックアップ保存処理など

-x: テーブルをロック

--master-data: CHANGE MASTER ステートメントと binlog ファイルおよび場所の情報をバックアップ ステートメントに追加します。

バックアップファイルを表示する

このようにして、データの完全なバックアップが作成されました。次に、データベースを削除し、データをバックアップして復元します。

gzip -d バッチアップ_xxx.gz
mysql -uroot -p < bakup_xxx.sql

これで、データがライブラリにインポートされました。

上記の操作を続行して、xiaoli と xiaozhao という 2 つの新しいデータを追加し、xiaozhao のレコードを削除します。

削除する前に、binlog ログを更新して新しいログを生成し、後で実行するすべての操作が新しいログ ファイルに記録されるようにします。 (上記の binlog ログの詳細な説明から、サービスが更新されて再起動されるたびに binlog ログ ファイルが生成されることがわかります。)

ログをフラッシュする。
マスターステータスを表示します。

binlog ファイルは 0009 であり、位置は 154 であることがわかります。これら 2 つの情報は非常に重要です。

挿入と削除の操作をしてみましょう

この時、後でこの状態に復元できるように、binlog ログの状態を確認する必要があります。ただし、実際の環境ではこの状態はわからないため、ここではこの状態を確認しません。この状態の値は、後で binlog ログ ファイルを確認することで分析できます。では、エラーから始めましょう:

xiaozhaoを削除しましょう

このようにデータが削除されました。もう一度binlogの状態を確認してみましょう。

マスターステータスを表示します。 

この時点で、削除操作が間違った操作であることがわかり、回復する必要があります。では、どのように回復すればよいのでしょうか?この時点で、binlog の位置を通じて復元できます。
他の処理を行う前に、直ちにフラッシュログを再度実行し、このような binlog ログファイル内のエラー部分を集中させることをお勧めします。

0009のbinlogログを確認してみましょう。

delete_rows の終了点は 928 で、開始点は 755 であることがわかります。最後のバックアップまでのデータを削除し、binlog を実行して、もちろん 755 より前まで復元できます。
たとえば、前回データベース全体をバックアップした場合、データベース全体を削除し、バックアップ ファイルを使用して復元し、binlog を使用して増分リカバリを実行できます。このようにしてデータが返されます。ここではデータベースを削除せず、 binlogログを使用してデータを復元する方法を直接示します。

構文は次の通りです

mysqlbinlog mysql-bin.0000xx | mysql -u用戶名-p密碼數據庫名

たとえば、すべての操作を復元したいとします (ポイント 755 で行われたことがわかっている削除は除きます)。

mysqlbinlog mysql-bin.000009 --開始位置 154 --停止位置 755 | mysql -uroot -p mytest

もう一度表を見てみましょう

xiaozhao が再び戻ってきたことがわかりました。もちろん、バックアップ前にデータを削除しなかったため、ここには余分な xiali があります。もちろん、回復プロセス中に、xiaozhao のコンテンツのみを復元することを選択できます。

以下は、binlog ログのリカバリでよく使用されるパラメータです。

--start-datetime: ローカルコンピュータのタイムスタンプと同じかそれ以降の時刻をバイナリログから読み取ります

--stop-datetime: バイナリ ログから、タイムスタンプより小さいか、ローカル コンピューターの時刻に等しい時刻値を読み取ります。値は上記と同じです。

--start-position: バイナリ ログから指定された位置のイベント位置を開始として読み取ります。

--stop-position: バイナリログから指定された位置のイベント位置をイベント終了として読み取ります。

MySQL でデータ復旧に binlog ログを使用する方法についての記事はこれで終わりです。MySQL binlog データ復旧の詳細については、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。