MySQL 増分バックアップとブレークポイントリカバリスクリプトの例

導入

増分バックアップとは、完全バックアップまたは最後の増分バックアップの後、後続の各バックアップでは、前回のバックアップと比較して追加または変更されたファイルのみをバックアップする必要があることを意味します。つまり、最初の増分バックアップの対象は、完全バックアップ後に生成された追加および変更されたファイルであり、2 番目の増分バックアップの対象は、最初の増分バックアップ後に生成された追加および変更されたファイル、というようになります。

目的

フルバックアップでは回復に時間がかかり、回復が遅いという問題を解決するために、増分バックアップが採用されています。

特徴

利点: 重複データなし、バックアップボリュームが小さい、時間が短い: フルバックアップ後の最後のフルバックアップと増分バックアップから復元する必要があり、増分バックアップを1つずつ繰り返し復元する必要があり、操作が面倒

実装

mysql バイナリログを介した間接増分バックアップ:
バイナリログには、更新されたデータや更新される可能性のあるデータがすべて保存されます。バイナリログは、MySQL の起動時に記録を開始し、新しいログファイルが作成されます。ログを再作成してバイナリファイルシーケンスを生成するには、定期的にフラッシュログメソッドを実行する必要があります。

実験環境:

MySQL5.7データベースがインストールされたCentos7仮想マシン

操作プロセス:

1. 増分バックアップ

1. 設定ファイルにバイナリログを追加する

vim /etc/my.cnf
[mysqld] #このモジュールの下に追加
log-bin=mysql-bin #バイナリログ

2. サービスを再起動してバイナリログを表示します

systemctl で mysqld.service を再起動します。
cd /usr/local/mysql/data/
mysqlbinlog --no-defaults mysql-bin.000001

3. 実験テンプレートとしてデータベース内にデータベースとテーブルを自由に作成する

4. 学校のデータベースの完全なバックアップを作成する

mysqldump -uroot -pabc123 学校 > /opt/school.sql

5. ログを更新し、新しいログを生成します。注: 以前のデータベース操作は番号 000001 のログに書き込まれ、番号 000002 の新しく生成されたログは空です。

mysqladmin -uroot -pabc123 flush-logs #ログをフラッシュする
mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000001 #000001 ログを表示
mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000002 #000002 ログを表示
#--base64-output=decode-rows -v: ファイル内の文字化けを避けるために、前の表示コマンドも使用できます。

6. 新しいMySQLデータベース操作を追加し、ログを更新して増分バックアップを実行します。

学校を利用する;
mysql> 情報（ID、名前、スコア）の値（3、 'aaa'、78）に変換します。
mysql>info から name='tom' を削除します。#エラー
mysql> info (id,name,score) に値 (4,'bbb',64) を挿入します。
mysqladmin -uroot -pabc123 flush-logs #ログをフラッシュし、000003 を生成
#この増分バックアップはログファイル000002に記録されています

7. 情報テーブルを削除する

mysql -uroot -pabc123 -e 'use school;drop table info;'

8. 完全バックアップを復元し、増分バックアップを復元する

mysql -uroot -pabc123 school < /opt/school.sql #フルバックアップと復元

mysqlbinlog --no-defaults mysql-bin.000002 | mysql -uroot -p

さて、ここで問題があります。エラーが発生すると、バックアップの復元時にエラーが発生し、本来の目的を達成するための理想的なバックアップを実現できなくなります。このとき、壊れたチェーンのリカバリ（増分バックアップを復元する特別な方法）が必要になります。つまり、復元中に正しいデータベース操作のみが復元されます。

2. 壊れたリンクの回復

壊れたリンクの回復を実行する前に、図に示すように、増分バックアップと復元のない状態に復元する必要があります。

時点に基づく

2018-09-04 16:43:52 エラー操作時間（この時点で読み込みの開始が終了します）
2018-09-04 16:44:32 正しい操作時間（この時点から再度読み込みを開始します）この時点から再度読み込みを開始します

mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000002 #000002 ログを表示

mysqlbinlog --no-defaults --stop-datetime='2018-09-04 16:43:52' /usr/local/mysql/data/mysql-bin.000002 | mysql -uroot -p
mysqlbinlog --no-defaults --start-datetime='2018-09-04 16:44:32' /usr/local/mysql/data/mysql-bin.000002 | mysql -uroot -p

位置ポイントに基づく

565 最後の正しい実行位置 --stop-position
667 次の正しい実行位置 --start-position

mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000002 #000002 ログを表示

mysqlbinlog --no-defaults --stop-position='565' /usr/local/mysql/data/mysql-bin.000002 | mysql -uroot -p
mysqlbinlog --no-defaults --start-position='667' /usr/local/mysql/data/mysql-bin.000002 | mysql -uroot -p