mysqlデータベースのバックアップとリカバリ

 1. データバックアップの重要性

 2. データベースバックアップの分類とバックアップ戦略

2.1 データベースバックアップの分類 

1) 物理バックアップ

2) 論理バックアップ

2.2 データベースのバックアップ戦略 

2.3 一般的なバックアップ方法

 3. MySQL の完全バックアップ

3.1 完全バックアップとは

3.2 フルバックアップの長所と短所

3.3 フルバックアップの方法

1) 物理的なコールド バックアップとリカバリ

2) mysqldump のバックアップと復元

 4. 完全なバックアップと復元の操作

 4.1 物理コールドバックアップ

(1) フルバックアップ 

(2) データ復旧 

(3) データ移行 

4.2 論理フルバックアップとリカバリの一般的な方法

1) xtrabackup ツールを使用する

2)LVM

3)CP+テイク

4)mysqlホットコピー

5) mysql マスター/スレーブ レプリケーションを使用する

4.3 論理バックアップ mysqldump ツールの使用

(1) 1 つ以上の完全なライブラリの完全バックアップ

(2) MySQL サーバー内のすべてのライブラリ (ライブラリ内のすべてのテーブルを含む) を完全にバックアップします。 

(3) 指定したライブラリ内の一部のテーブルを完全にバックアップします。 

 (4) バックアップしたSQLファイルを参照する

(5) データベースのライブラリ全体を復元する

(6) データベース内のテーブルを復元します。

 5. 増分バックアップとリカバリ

 5.1 増分バックアップ

(1) 増分バックアップを行う理由 

(2) 増分バックアップのプロセス 

(3) 増分バックアップの方式

 (4) 増分バックアップの運用

(5) データ復旧作業のための増分バックアップ 

 5.2 データ回復のための増分バックアップ

(1) ロケーションポイントに基づく復元 

(2) ポイントインタイムリカバリ方式

 6. 完全リカバリと増分リカバリのためのデータベース バックアップ スクリプト

 (1) 増分バックアップスクリプトの記述

(2) フルバックアップスクリプト 

(3) 作成した 2 つのスクリプトをスケジュールされたタスクに追加します 

 1. データバックアップの重要性
     バックアップの主な目的は災害復旧です。

実稼働環境では、データのセキュリティが最も重要です。

データが失われると、重大な結果が生じる可能性があります。

データ損失の理由:

プログラムエラー、人的エラー、操作ミス、ディスク障害災害(火災、地震など)、盗難。
 

 2. データベースバックアップの分類とバックアップ戦略
2.1 データベースバックアップの分類 
1) 物理バックアップ
物理バックアップ: データベースオペレーティングシステムの物理ファイル (データファイル、ログファイルなど) のバックアップ。

物理バックアップ方法:

コールド バックアップ (オフライン バックアップ): データベースが閉じているときに実行されます。
ホット バックアップ (オンライン バックアップ): データベースのログ ファイルに応じて、データベースが実行されています。
ウォーム バックアップ: データベースのロックされたテーブルのステータス (書き込み可能ではなく読み取り可能です) )
2) 論理バックアップ
バックアップ: データベースの論理コンポーネント (テーブルなどのデータベース オブジェクトなど) のバックアップ。

つまり、ライブラリ、テーブル構造、およびテーブル データは SQL ステートメントの形式で保存されます。
2.2 データベースのバックアップ戦略 
フル バックアップ (フル バックアップ): 毎回データベースを完全にバックアップします。
差分バックアップ: 前回の完全バックアップ以降に変更されたファイルをバックアップします。
増分バックアップ: 最後の完全バックアップまたは増分バックアップ以降に変更されたファイルのみがバックアップされます。
 

2.3 一般的なバックアップ方法
物理コールド バックアップ:(フル バックアップ)

バックアップ中はデータベースが閉じられ、データベース ファイルが直接パッケージ化される
バックアップ速度が速く、リカバリも最も簡単
特別なバックアップ ツール mydump または mysqlhotcopy (フル バックアップ、論理バックアップ)

Mysqldump は一般的に使用される論理バックアップ ツールです (SQL スクリプトとしてエクスポートされます)
mysqlhotcopy にはバックアップ MyISAM テーブルと ARCHIVE テーブルのみが含まれます
増分バックアップのバイナリ ログを有効にします (増分バックアップ)

増分バックアップの場合は、バイナリ ログを更新する必要があります。
サードパーティ ツールのバックアップ

無料の MySQL ホット バックアップ ソフトウェア Percona XtraBackup
(Aliyun のツール: dts、ホット マイグレーションをサポート)

 3. MySQL の完全バックアップ
3.1 完全バックアップとは何ですか? 完全
バックアップとは、データベース全体、データベース構造、およびファイル構造のバックアップです。
バックアップが完了した時点のデータベースを保存します。
差分バックアップとバックアップの基礎となります。
3.2 完全バックアップの長所と短所利点
:

バックアップと復元の操作はシンプルで便利です
。 欠点:

データの重複が多くまたがかかる時間リカバリにバックアップと
多くのバックアップ領域を占有し、MySQL のバックアップを簡単に実現できる MySQL の組み込みバックアップ ツールを復元し、指​​定したファイルをエクスポートできますライブラリとテーブルを SQL スクリプトとして作成し、コマンド mysq| を使用してバックアップ データをインポートします  4. 完全なバックアップとリカバリ操作  4.1 物理コールド バックアップ(1) フル バックアップ   systemctl stop mysqld #最初にサービスをオフにしてください  mkdir /backup/ #Createバックアップ ディレクトリ  rpm  -q xz #xz ツールを使用して圧縮し、xz ツールがインストールされているかどうかを確認します  yum install xz -y #インストールされていない場合は、まず yum install   cd /usr/local/mysql/  tar Jcf /backup /mysql_all_$(date +%F).tar.xz data #データベース ファイルをパッケージ化します。/usr/local/mysql/data はデータベース ファイルの保存ディレクトリです。




















tar tf mysql_all_2022-10-25.tar.xz 


(2) データ復旧 
とデータベース削除: 

 完全回復のための操作:

cd /backup/
tar Jxf mysql_all_2022-10-25.tar.xz -C /opt/
mv /opt/data/ /usr/local/mysql/


データベース サービスを開いてログインします。

(3) データ移行 
 #ホスト A、scp コマンドを使用して tar パッケージを別のホスト B に転送
 scp /backup/mysql_all_2022-10-25.tar.xz [email protected]:/opt
 ##
 ホスト B の操作##
 systemctl stop mysqld #mysql を閉じる
 cd /opt/
 mkdir /opt/bak/ #バックアップ ディレクトリを作成する                  
 tar Jxf mysql_all_2022-10-25.tar.xz -C /opt/bak/ #tar パッケージをバックアップ ディレクトリに解凍します
 cd / opt/bak/ #tar パッケージの解凍ディレクトリに切り替えます
 \cp -af usr/local/mysql/data/ /usr/local/mysql #データ ディレクトリを /usr/local/mysql/ ディレクトリにコピーし、元のファイルを上書きします。
 systemctl
 start mysqld #mysql を開始します
 mysql -u root -p #show データベースを表示するにはデータベースにログインします
 。
 

      

  

4.2 論理完全バックアップおよびリカバリの一般的な方法
mysqldump は、一般的に使用される論理バックアップ ツールです。

mysqldump は、指定したライブラリとテーブルを SQL スクリプトとしてエクスポートできます。

1) xtrabackup ツールを使用します。
これは、MySQL データベースをバックアップするためのオープン ソース ツールです。

主な特徴:

オンラインホットバックアップ。Innodb と myisam はバックアップできます。Innodb は主に回復原則を適用します。myisam はファイルを直接コピーします。
ストリーミングバックアップがサポートされています。ディスク、テープ、reomot ホストにバックアップできます。--stream=tar ./ | ssh user@remotehost cat ">" /backup/dir/ は増分バックアップをサポートします。増分バックアップは、lsn とベース バックアップ ディレクトリを使用して実行できます。
スレーブ上のマスターログとマスター位置情報の記録をサポートします。
 複数プロセスの同時ホットバックアップをサポートしており、xtrabackup の安定性は非常に優れています。
2) LVM の
機能: ホット スタンバイ、すべてのローカル ディスク ベースのストレージ エンジンのサポート、高速バックアップ、低オーバーヘッド、整合性の維持が容易、高速リカバリなど。

3) cp + tar は、
データベース ファイルを直接コピーしてパッケージ バックアップする方法を使用しており、実行手順は、テーブルのロック、バックアップ、テーブルの結合を解除するという点に注意してください。

復元も非常に簡単で、以前のデータベース ファイルの保存ディレクトリに直接コピーするだけです。

注: Innodb エンジン テーブルの場合は、ログ ファイル、つまり ib_logfile* ファイルもバックアップする必要があります。Innodb テーブルが破損した場合、これらのログ ファイルを頼りに回復できるためです。

4) mysqlhotcopy
mysqlhotcopy は、ロック テーブル、フラッシュ テーブル、cp または scp を使用してデータベースを迅速にバックアップする Perl プログラムです。

これはデータベースまたは単一のテーブルをバックアップする最も速い方法ですが、データベース ファイル (データ テーブル ファイル、データ ファイル、インデックス ファイルを含む) が配置されているマシン上でのみ実行できます。

mysqlhotcopy は、MyISAM のバックアップにのみ使用できます。

5) mysql マスター/スレーブ レプリケーションの使用
Mysql レプリケーションとは、バイナリ ファイル (bin-log) を介してマスター データベースの DDL および DML 操作をスレーブ サーバーに転送し、これらのログをスレーブ サーバーで再実行することを指します。スレーブ サーバーとマスター サーバーの間で同期が維持されます。
 

4.3 論理バックアップ mysqldump ツールの使用
(1) 1 つ以上の完全なデータベースを完全にバックアップします
mysqldump -uroot -p[パスワード] --databases データベース名 1 [データベース名 2].. >/バックアップ パス/バックアップ ファイル名.sql #エクスポートはデータベーススクリプトファイルです


(2) MySQL サーバー内のすべてのライブラリ (ライブラリ内のすべてのテーブルを含む) を完全にバックアップします。 
 mysqldump -u root -p[password] --all-databases > / バックアップ パス/バックアップ ファイル名.sql
 

(3) 指定したライブラリ内の一部のテーブルを完全バックアップ 
 mysqldump -u root -p [パスワード] [-d] ライブラリ名 テーブル名 1 [テーブル名 2] ... > /バックアップパス/バックアップファイル名.sql #use 「
-d 」オプションは、データベースのテーブル構造のみが保存されることを示します
 。 #「-d」オプションは、テーブル データもバックアップされることを示しますので使用しないでください。


 (4) バックアップ SQL ファイルを表示します
 cd /opt/sql_bak
 cat ファイル名 | grep -v "^--" | grep -v "^/" |grep -v "^$"
 または
  cat ファイル名 | egrep -v " ^--|^/|^$」


(5) データベースのライブラリ全体を復元します。
ライブラリを削除します。 

 mysql -u root -p < /opt/sql_bak/test.sql #入力ライブラリ ファイルをリダイレクト
 mysql
 -u root -p -e 'SHOW DATABASES;' #現在利用可能なデータベースを確認する
 

(6) データベース内のテーブルを復元します。
テーブルを削除します。 

 #バックアップ ファイルをインポートするにはリダイレクトします。ライブラリ名を指定する必要があり、ターゲット ライブラリが存在する必要があります。ライブラリがない場合は、ライブラリをビルドする必要があります。 mysql -u root -p test
 < /opt/sql_bak/info_info2.sql   
 

 5. 増分バックアップとリカバリ
 5.1 増分バックアップ
 

(1) 増分バックアップの理由は、 
完全バックアップに mysqldump を使用することの問題です。

バックアップデータに重複データがある
バックアップ時間とリカバリ時間が長すぎる
増分バックアップとは:

前回のバックアップ以降に追加/変更されたファイルまたはコンテンツです
増分バックアップの特徴

重複データがなく、バックアップ量も多くなく、時間が短いため、
復元には最後の完全バックアップと、完全バックアップ以降のすべての増分バックアップが必要であり、すべての増分バックアップを 1 つずつ元に戻す必要があります。
 

(2) 増分バックアップのプロセス 
MySQL は直接的な増分バックアップ方法を提供しません。

増分バックアップは、MySQL が提供するバイナリ ログを通じて間接的に実現できます。

バックアップ用の MySQL バイナリ ログの重要性

バイナリ ログには、データベースを更新する、または更新される可能性のあるすべての操作が保存されます。
バイナリ ログは、MySQL サーバーの起動後に記録を開始し、ファイルが max_binlog_size で設定されたサイズに達するか、フラッシュ ログ コマンドを受信した後に新しいログ ファイルを再作成します。定期的にログのフラッシュを実行する
この方法では、新しいログを再作成し、一連のバイナリ ファイルを生成し、これらのログを安全な場所に保存して、一定期間の増分バックアップを完了します (3) 増分バックアップ方法 一般的

リカバリ

バックアップされたすべてのバイナリ ログ コンテンツを
場所に基づいて復元する

データベースには、特定の時点で誤った操作と正しい操作の両方が存在する可能性があります。
誤った操作は正確な位置に基づいてスキップし
、時点に基づいて復元できます。

エラーが発生したときに特定の時点をスキップしてデータを回復します
 (4) 増分バックアップの操作では
 、増分バックアップの前にメイン構成ファイルを変更する必要があります。

 vim /etc/my.cnf
 [mysqld]
 log-bin=mysql-bin #バイナリログを有効にします。相対パスを使用する場合は、/usr/local/mysql/data/ ディレクトリに保存します。
 binlog_format = MIXED #オプションで、バイナリ ログ (binlog) のレコード形式を MIXED として指定します。
 server-id = 1
 systemctl
 restart mysqld
 ls -l / usr/local/mysql/data/mysql-bin.*
 
 

バイナリ ログ (binlog) には 3 つの異なるレコード形式があります。

 STATEMENT (SQL ステートメントに基づく)、ROW (行に基づく)、MIXED (混合モード)、デフォルト形式 STATEMENT
 STATEMENT (SQL ステートメントに基づく): 変更された SQL ステートメントを記録します。同時実行性が高い場合、操作を記録するための SQL ステートメントの順序にエラーが発生する可能性があり、その結果、データの復元時にデータの損失やエラーが発生する可能性があります。効率は高いですが、データに誤差が生じる可能性があります。
 ROW (行ベース): データの各行を正確に記録しますが、復元時には非効率的です。
 MIXED (混合モード): 通常の状況では STATEMENT を使用し、同時実行性が高い場合はインテリジェントに ROW に切り替えます。insert
into infovalues(8,'小蘭','女性',22,'武漢','「チキン、あなたは美しすぎる」を聴くのが好きです'); insert into infovalues(9,'小公',
'女性', 22,'四川省','「ヘイ ヘイ ヘイ」を聞くのが好きです');
 
 mysqladmin -u root -p flash-logs #新しいバイナリ ファイルを更新します
 

 mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000001
 #
 --base64-output=decode-rows: 64 ビット エンコード メカニズムを使用して、行
 #-v をデコードして読み取ります。詳細を表示
 
 

#バイナリ バックアップ ファイルを保存するディレクトリとして新しいフォルダを作成します。
 
mkdir -p /opt/sql_bak
 
#新しく生成されたバイナリ バックアップ ファイルを新しいディレクトリに移動し (より安全な方法: コピー)、その名前に
 mv という名前を付けて変更します。 /usr/local/mysql/data/mysql-bin.000001 /opt/sql_bak/info_sql_`日付 +%Y%m%d`
 

(5) データ復旧作業のための増分バックアップ 
 

id=8 の情報から削除します。
id=9 の情報から削除します。


 

増分復元を実行します。 

mysqlbinlog --no-defaults /opt/sql_bak/info_sql_20221027 | mysql -u root -p


 

 5.2 データ回復のための増分バックアップ
 

(1) ロケーションポイントに基づく復元 
 

 #特定の時点からログの終わりまでリカバリを開始
mysqlbinlog --no-defaults --start-position='位置ポイント' ファイル名 | mysql -u root -p #  ログの先頭から特定の時点まで
 
 リカバリ  --no-defaults --stop-position='position point' ファイル名 | mysql -u root -p #  指定されたポイントから開始して指定されたポイントの終わりまで  mysqlbinlog --no-defaults --start-position='xxx'--stop-position='位置点' ファイル名 | mysql -u root -p  


 
 


 
 

 1) 開始点から終了点まで再開

mysqlbinlog --no-defaults --start-position=4 mysql-bin.000002 |mysql -u root -p 


 

2) 指定された地点から指定された終点まで 

mysqlbinlog --no-defaults --start-position=1513 --stop-position=1800 mysql-bin.000003 |mysql -u root -p 
 

(2) ポイントインタイムリカバリ方式
 

 #特定の時点からログの終わりまでリカバリします
 mysqlbinlog --no-defaults --start-datetime='point in time' ファイル名 | mysql -u root -p #ログの先頭からログの終わりまで
 
 リカバリします  --no-defaults --stop-datetime='時点' ファイル名 | mysql -u root -p #特定の時点から   回復し特定の時点より前に mysqlbinlogを終了しますtime --no -defaults --start-datetime='開始時点' --stop-datetime'終了時点' ファイル名 | mysql -u root -p


 



 
 

 6. 完全リカバリと増分リカバリを組み合わせたデータベース バックアップ スクリプトの利点
: 完全バックアップと不完全バックアップにはそれぞれ利点があり、ほとんどの企業はデータベース バックアップに完全バックアップ + 増分バックアップを使用します。 フル バックアップ: ディスクを大量に消費します。しかし、操作は簡単でエラーはありません。増分バックアップ: ディスクの占有量は少ないため、短期間のバックアップに使用できますが、すべての増分バックアップが完了すると、操作の難易度が大幅に高まり、エラーが発生しやすくなります。

要件設計: 会社がビジネスを立ち上げました。情報テーブルはコア データ テーブルです。このため、テーブルはビジネスのオンライン時にバックアップされます。完全バックアップは毎週火曜日の午前 2 時 30 分 (メンテナンス時間) に必要で、増分バックアップは毎日午前 1 時に実行されます。

 (1) 増分バックアップスクリプトの記述
 

#!/bin/bash
logs_path="/opt/sql_bak"
[ -d $logs_path ] || mkdir -p $logs_path
/usr/local/mysql/bin/mysqladmin -u root -pabc123 flash-logs
lastlogs=`sed -n '$p' /usr/local/mysql/data/mysql-bin.index | awk -F '/' '{print $2}'`
mv /usr/local/mysql/data/$lastlogs /opt/sql_bak/binlog_`date +%Y%m%d`
 

(2) フルバックアップスクリプト 
 

#!/bin/bash
home_path="/opt/sql_bak/backup_sql"
[ -d $home_path ] || mkdir -p /opt/sql_bak/backup_sql
/usr/local/mysql/bin/mysqldump -u root -pabc123 テスト情報 > /$home_path/infos_$(date +%Y%m%d).sql /usr/local
/ mysql/bin/mysqldump -u root -pabc123 --databases test > /$home_path/tests_$(date +%Y%m%d).sql
 

(3) 記述した 2 つのスクリプトをスケジュールされたタスクに追加します 
crontab -e
00 1 * * * /opt/addbak.sh
30 2 * * 2 /opt/backup.sh

おすすめ

転載: blog.csdn.net/zl965230/article/details/130625514