mysqldump とバイナリログ log-bin に基づく MySQL での論理バックアップとポイントインタイムリストア-mysql チュートリアル-php.cn

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

巴扎黑

リリース： 2017-06-26 09:12:38

オリジナル

1547 人が閲覧しました

この記事の出典:

この記事は、簡単なテストのために 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