mysqldump とバイナリ ログ log-bin に基づく MySQL での論理バックアップとポイントインタイム リストア

この記事の出典:

この記事は、簡単なテストのために mysqldump と log-bin バイナリ ログの使用をシミュレートするだけであり、実際のアプリケーションとはかけ離れている可能性があります。は参考用です。

MySQL の bin-log バイナリ ログを有効にする

シミュレートされた復元には、mysqldump からのファイルと log-bin が必要なので、log-bin バイナリ ログを開始する必要があります。
mysql5.7.18 でバイナリ ログを開く場合、log-bin の場所の設定に加えて、server-id も設定する必要があります。以前のバージョンの MySQL ではこの設定は必要ありません。

オープンソースソフトウェアについて文句を言いましょう。基本的に、各バージョンには以前のバージョンとの違いがあり、バージョンが異なると多くの点が異なることに注意する必要があります。

再起動後、log_bin関連の変数をクエリする

mysqldumpバックアップ（エクスポート）データの基本的な使い方

mysqldumpコマンドには、よく使われるパラメータがかなり多くあります。コマンドを使用し、データベース復元操作には mysqldump バックアップ (厳密にはデータのエクスポート) とバイナリ ログ log-bin を使用します。

-- testdb データベース全体をバックアップします。-l は、すべてのテーブルに読み取りロックを追加することを意味します。-F (F は大文字である必要があり、小文字はエラーを報告しません。単一ページは無効です) は、新しいログを生成するためにローリングすることを意味します。 file
mysqldump -u root - p -l -F -h localhost testdb > usr/local/mysqlbak/test20170607_data.sql

バックアップされたファイルはテーブルの作成とテーブルへの挿入のスクリプトです

-- testdb データベースをバックアップします。test_table1 と test_table2 の 2 つのテーブルがあります。 --no-create-info を追加すると、バックアップされたファイルにはテーブル作成スクリプトが含まれず、テーブル
mysqldump -uroot への挿入の情報のみが含まれることになります。 -p -h localhost testdb test_table1 test_table2 --no-create-info> usr/local/mysqlbak/test20170606_1.sql

-- testdb データベース内の test2 テーブルのデータの一部をバックアップします。 idmysqldump -uroot - p -h localhost testdb test_table1 --where "id > usr/local/mysqlbak/test20170606_2.sql

詳細mysqldump パラメータについては、以下を参照してください:

さらに、mysql ログビン置換戦略:

インデックスを使用してファイルをループすると、次の条件下で次のインデックス
1 にループします。サーバー再起動
2.サーバーが更新されました
3.ログが最大ログ長 max_binlog_size
4 に達しました。ログはフラッシュされます mysql>flush logs;

mysqldump でバックアップしたファイルと log-bin バイナリログを使用して復元します

まず、テーブルにデータがあるときにバックアップします

mysqldump を実行します-u root -p -l -F -h localhost testdb --master-data=2 > usr/local/mysqlbak/test20170607_data.sql

ここにオプション --master-data=2 が追加されます目的は、バックアップ ファイル内の現在の log_bin ファイルを記録することです
このコマンドが追加される理由については、多くのブログで、mysqldump を使用してファイルをバックアップし、データを変更し、その後、誤った削除やダウンタイムの復元をシミュレートしていることが記録されています。データベースのファイルを使用し、mysqldump のファイルを使用して復元した後、log-bin を使用して復元します
これらはすべてテスト シミュレーションですが、mysqldump の後にログがスクロールされたかどうかをどのように確認するかという明らかな問題があります。何回もスクロールしましたか？
ログがスクロールしない場合は、時点または位置に応じてログビン ファイルを復元します。スクロールする場合は、スクロールされたログ ファイルの数をどのように確認しますか?
ログ ファイルを更新した後、新しく生成されたログ ファイルを記録する必要があります。 mysqldump の実行時にログを作成する必要があります。ログの復元を使用する場合にのみ、復元に使用するログを決定できます。

--master-data=2 オプションを使用すると、mysqldump バックアップ中に log_file の場所を知ることができます

その後、テーブルに 10 個のデータを挿入し続けます

次に、次の場所でデータの誤った削除をシミュレートします

ある時点 この場合、テスト テーブルを切り詰めます。この時点ではテスト テーブルは空です

まず、mysqldump のファイルを使用してデータベースを復元します。mysqldump からのファイル バックアップは、そのときのデータです。は100行です

バックアップOK時のバックアップファイルのデータは100なので、復元後も100行ありますが問題ありません。

その後、log-binを使用して時点に従って復元します

ログが更新された後、mysqldumpによって生成されたファイルにlog-binのファイル名が記録されます。ロールされていない場合は、以下の図の最新のログビンに応じて時点に従ってスクロールして復元します。


mysqldumpバックアップと復元を実行します mysql -u root -p testdb < usr/local/mysqlbak/test20170607_data.sql 続行し、bin-logに基づいてポイントインタイム復元を実行します
mysqlbinlog

--stop- datetime="2017-6-7 21:45:00"

/var/lib/mysql/mysql-bin.000022

| mysql -u root -p testdb

するとデータが戻ってきます。

もちろん、これは単なるシミュレーション操作であり、ログローリングが発生した場合は、時点に基づいて復元する必要があるため、まだ詳細が不明です。どのログ ファイルがその時点に基づいているかを調べる必要があります。

概要:

この記事では、データベースの復元操作をモデル化するための簡単な例のみを使用します。

mysqldump バックアップ モードは、データを挿入スクリプトとしてエクスポートするだけで、パフォーマンスが向上します。より大きなデータの復元に問題があり、mysqldump は適していない可能性があり、バックアップと復元にはより効率的な xtrabackup が必要です。

🎜🎜 🎜🎜🎜

以上がmysqldump とバイナリ ログ log-bin に基づく MySQL での論理バックアップとポイントインタイム リストアの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。