MySQL はエンタープライズレベルのログ管理、バックアップ、リカバリの実践的なチュートリアルを実装します

背景

事業が発展するにつれ、会社の事業内容や規模は拡大し続け、ウェブサイトには大量のユーザー情報やデータが蓄積されてきました。インターネット企業にとって、ユーザーデータとビジネスデータは基盤となります。企業のデータが乱れたり失われたりすれば、インターネット企業にとって大惨事となります。システム操作ミスやシステム障害によるデータ損失を防ぐために、企業にはユーザーデータの信頼性を強化し、データレベルのバックアップを全面的に強化し、障害発生時にできるだけ早く復旧できることが求められます。

データバックアップフォーム

ファイルのバックアップ:

Linux のバックアップ コマンドを使用してファイルをパッケージ化し、ローカルまたはリモート サーバーに保存します。復元する必要がある場合は、これらのファイルを使用して指定した場所に復元できます。

データベースデータのバックアップ:

銀行、証券、通信など、データの信頼性に対する要件が高い業界では、予期しないダウンタイムやデータ損失が発生すると、損失は非常に大きくなります。このため、データベース管理者は、特定のビジネス要件に基づいて詳細なデータベースバックアップと災害復旧戦略を策定し、それぞれの障害をシミュレートする必要があります。

あらゆる可能性のある状況を厳密にテストすることが、高いデータ可用性を確保する唯一の方法です。データベースのバックアップは長いプロセスですが、リカバリは事故が発生した後にのみ実行されます。リカバリはバックアップの逆のプロセスと見なすことができます。リカバリの程度は、バックアップの状況に大きく依存します。また、

リカバリ中にデータベース管理者が実行した手順が正しいかどうかも、最終的なリカバリ結果に直接影響します。

データバックアップタイプ

業務別：フルバックアップ、増分バックアップ、差分バックアップに分類可能

1. フルバックアップ: データベース全体のデータとデータ構造をバックアップします

利点: 直感的で理解しやすい

デメリット: 1. 大量のバックアップ データが複製されるため、多くのスペースが占有され、コストが増加します。

2. バックアップするデータの量が多く、時間がかかる

(フルバックアップ) いわゆるフルバックアップは、データベース全体のデータとデータ構造をバックアップすることです。このバックアップ方法の利点は、非常に直感的で理解しやすいことです。また、データ損失災害が発生した場合、災害前のバックアップ ファイルを使用して失われたデータを復元できます。

しかし、欠点もあります。まず、システムは毎日完全にバックアップされるため、大量のバックアップ データが繰り返されます。これらの重複データは多くのスペースを占有するため、ユーザーのコストが増加します。また、バックアップするデータの量が非常に多いため、バックアップに時間がかかります。業務が忙しく、バックアップ時間に制限がある部門にとって、このバックアップ戦略を選択するのは間違いなく賢明ではありません。

2. 増分バックアップ: 毎回バックアップされるデータは、前回のバックアップ後に追加および変更されたデータのみになります。

利点: バックアップデータが重複しないため、スペースを節約できます

デメリット: データの復旧が面倒で、バックアップデータに問題があるとデータが失われる

つまり、毎回バックアップされるデータは、前回のバックアップ後に追加および変更されたデータと同等になります。このタイプのバックアップの利点は明らかです。バックアップ データが重複しないため、スペースが節約され、バックアップ時間が短縮されます。しかし、災害が発生したときにデータを復旧するのが面倒なのが欠点です。例えば、

木曜日の朝にシステムに障害が発生し、大量のデータが失われた場合、システムを水曜日の夜の状態に復元する必要があります。

この時点で、管理者はシステムを復元するためにまず月曜日の完全バックアップ データを探し、次に火曜日のデータを復元するために火曜日のデータを探し、最後に水曜日のデータを復元するために水曜日のデータを探す必要があります。 明らかに、これは最初の戦略よりもはるかに面倒です。さらに、このバックアップは信頼性が高い

セックスも下手です。このタイプのバックアップでは、各バックアップ データ間の関係は、リンクが次々に続くチェーンのようになります。バックアップ データのいずれかに問題が発生すると、チェーン全体が切断されます。

3. 差分バックアップ: 各バックアップには、前回の完全バックアップ以降に新しく追加または変更されたデータが含まれます。

つまり、毎回バックアップされるデータは、最後の完全バックアップ後に新しく追加および変更されたデータです。管理者はまず月曜日に完全なシステム バックアップを実行し、その後数日間で月曜日とは異なるすべてのデータ (新規または変更されたデータ) をテープにバックアップします。たとえば、月曜日にネットワーク管理者が通常どおりにシステム全体のバックアップを実行します。火曜日には、システム内に資産リストがもう1つしかないため、管理者はこの資産リストのみをバックアップする必要があります。水曜日には、システム内に別の製品カタログがあるため、管理者は

このカタログだけでなく、火曜日の資産リストもバックアップする必要があります。

木曜日にシステムに追加の給与がある場合、木曜日にバックアップする必要があるコンテンツは、給与 + 製品カタログ + 資産リストです。 このことから、フルバックアップは最も時間がかかりますが、リカバリ時間は最短で、操作は最も便利であることがわかります。システム内のデータ量が大きくない場合は、フルバックアップが最も信頼性があります。差分バックアップは、他の 2 つの戦略の欠陥を回避できますが、特定の組み合わせでは異なるバックアップ タイプが存在する可能性があります。特定の組み合わせでは、異なるバックアップ タイプが存在する可能性があります。

異なるバックアップタイプを組み合わせる例

完全バックアップと差分バックアップ

完全バックアップは月曜日に実行され、差分バックアップは火曜日から金曜日に実行されます。金曜日にデータが破損した場合は、月曜日の完全バックアップと木曜日の差分バックアップのみを復元する必要があります。この戦略では、データのバックアップには時間がかかりますが、データの復元には時間がかかりません。

完全バックアップと増分バックアップ

完全バックアップは月曜日に実行され、増分バックアップは火曜日から金曜日に実行されます。金曜日にデータが破損した場合は、月曜日の通常のバックアップと火曜日から金曜日までのすべての増分バックアップを復元する必要があります。この戦略では、データのバックアップにかかる時間は短くなりますが、データの復元にかか​​る時間は長くなります。

モードによる分類：ホットスタンバイ、ウォームスタンバイ、コールドスタンバイに分類可能

ホット バックアップとは、実行中のデータベースに影響を与えることなく、実行中のデータベースを直接バックアップすることを指します。

コールド バックアップとは、データベースが停止しているときに実行されるバックアップを指します。このタイプのバックアップは最も単純で、通常は関連するデータベースの物理ファイルのコピーのみが必要です。

ウォーム バックアップはデータベースの実行中にも実行されますが、バックアップ データの一貫性を確保するためにグローバル読み取りロックを追加するなど、現在のデータベース操作に影響します。 (データベース内のテーブルをバックアップするときは、まずテーブルをロックして、他のユーザーがテーブル内のデータを追加、確認、削除、または変更できないようにします。こうすることで、バックアップ時にテーブル内のデータは変更されず、バックアップ データの一貫性が確保されます。)

物理バックアップ: データファイルを直接コピーしてバックアップします (直接コピーしてバックアップしたデータファイルはバイナリ形式です)

利点: 追加のツールは必要なく、コピーするだけで、バックアップファイルを直接コピーして復元できます。

デメリット: ストレージエンジンに関連、クロスプラットフォーム機能が弱い

論理バックアップ: データベースからデータを「エクスポート」し、それを別々に保存することによって実行されるバックアップ (SQL ステートメントをバイナリ ファイルよりも大きいテキスト ファイルにエクスポート)

利点: エディタを使用して処理でき、復元が簡単、ネットワーク経由で復元でき、データの破損を回避できます

デメリット: バックアップ ファイルが大きく、バックアップが遅く、浮動小数点数の精度が保証されず、論理バックアップ データを復元した後、インデックスを手動で再構築する必要があり、CPU リソースを大量に消費します。

バックアップフローチャート

MySQLログの紹介

MySQL ログ:

主に、エラー ログ、クエリ ログ、スロー クエリ ログ、トランザクション ログ、バイナリ ログなどが含まれます。

ログは MySQL データベースの重要な部分です。ログファイルはMySQLデータベースの操作中に発生した変更を記録します。つまり、

MySQL データベースのクライアント接続ステータス、SQL ステートメントの実行ステータス、およびエラー メッセージを記録します。データベースが誤って破損した場合、

ログ ファイルを通じてファイル エラーの原因を表示し、ログ ファイルを通じてデータを復元できます。

MySQL エラー ログ

MySQL データベースでは、エラー ログ機能がデフォルトで有効になっています。また、エラー ログを無効にすることはできません。デフォルトでは、エラー ログは mysql データベースのデータ ファイルに保存されます。エラー ログ ファイルは通常、hostname.err という名前になります。ここで、hostname はサーバーのホスト名を示します。

エラーログ情報は、自分で設定することができます。エラーログに記録する情報は、logerror と log-warnings で定義できます。log-err はエラーログ機能を有効にするかどうかとエラーログの保存場所を定義し、log-warnings はエラーログに警告情報を定義するかどうかを定義します。デフォルトでは、エラー ログには、サーバーの起動およびシャットダウン時の情報 (MySQL が InnoDB テーブル スペース ファイルを起動する方法、独自のストレージ エンジンを初期化する方法など、必ずしもエラー情報とは限りません)、サーバー操作時のエラー情報、イベント スケジューラがイベントを実行したときに生成される情報、サーバーからサーバー プロセスが開始されたときに生成される情報が記録されます。

mysql -uroot -p

'%log%' のようなグローバル変数を選択します。

設定ファイルを通じてlog_errorを変更できます

vim /etc/my.cnf //以下のように、エラーログのパスを/var/log/mariadb/mariadb.errに変更しました

ログエラー=/var/log/mariadb/mariadb.err

次に、データベース サービスを再起動してデータベースに接続し、グローバル ログを表示します。変更は成功しました。

エラーログの内容を表示する

一時的な変更:

MySQL エラー ログでは、log_error をファイル パスとして直接定義することも、ON|OFF として定義することもできます。

log_warings は 1|0 を使用した場合にのみ有効にできます。

永久的な変更:

エラー ログの場所を変更するには、log_error を使用して次のように形式を設定します。

[root@stu18 データ]# vim /etc/my.cnf

[mysqld]

Log_error=DIR/[ファイル名]

分析: DIR パラメータはエラー ログのパスを指定します。ファイル名パラメータはエラー ログの名前です。このパラメータが指定されていない場合は、デフォルトでホスト名が使用されます。設定ファイルを変更し、MySQL サーバーを再起動して有効にします。

注: MySQL 5.5.7 より前: データベース管理者は、MySQL サーバーのハード ディスク領域を確保するために、かなり昔のエラー ログを削除できます。 mysql データベースでは、mysqladmin コマンドを使用して新しいエラー ログを開くことができます。

mysqladmin コマンドの構文は次のとおりです。

mysqladmin –u root –pflush-logs また、mysql データベースにログインし、FLUSHLOGS ステートメントを使用して新しいエラー ログを開くこともできます。

MySQLクエリログ

デフォルトでは、クエリ ログはオフになっています。クエリ ログには、追加、削除、クエリ、変更など、すべてのユーザー操作が記録されるため、大規模な同時操作が行われる環境では大量の情報が生成され、不要なディスク IO が発生し、MySQL のパフォーマンスに影響します。データベースのデバッグを目的としていない場合は、クエリ ログを有効にしないことをお勧めします。

マイスク

'%log%' のようなグローバル変数を表示します。

MySQL スロークエリログ

スロー クエリ ログは、実行に指定された時間よりも長い時間がかかるクエリ ステートメントを記録するために使用されます。スロー クエリ ログを使用すると、実行効率が低いクエリ ステートメント (一部のクエリ ステートメントは実行に長い時間がかかるため、サーバーのパフォーマンスを最適化するには、これらのクエリ ステートメントを見つけてクリアする必要があります) を見つけて、最適化を行うことができます。有効にすることを強くお勧めします。サーバーのパフォーマンスにはほとんど影響しませんが、MySQL サーバー上で長時間実行されたクエリ ステートメントを記録することができます。パフォーマンスの問題を特定するのに役立ちます。

スロー クエリ ログを起動して設定します。

1. スロー クエリ ログは、構成ファイル my.cnf の log-slow-queries オプションを通じて有効にできます。

形式は次のとおりです。

vim /etc/my.cnf

[mysqld]

スロークエリログ = ON

スロークエリログファイル = /var/log/mariadb/slow.log

長いクエリ時間 = 0.01

DIR パラメータはスロー クエリ ログの保存パスを指定します。filename パラメータはログのファイル名を指定します。生成されるログ ファイルの完全な名前は、filename-slow.log です。保存パスが指定されていない場合、スロークエリログはデフォルトでMySQLデータベースのデータファイルに保存されます。ファイル名が指定されていない場合、デフォルトのファイル名はhostname-slow.logです。

2. MySQLサーバーにログインして直接定義する

方法は次のとおりです。

まず、グローバル権限が必要です。次に、mysql>set global slow_query_log=1;を実行します (一時的な効果で、実行に 1 秒以上かかる SQL ステートメントはスロー クエリ ログと呼ばれます)

デフォルトでは、遅いクエリ ログの時間制限はどれくらいですか?

この時間値は通常、long_query_time オプションを通じて設定されます。時間は秒単位で、マイクロ秒単位の精度になります。クエリ時間がこの時間値 (デフォルトは 10 秒) を超えると、クエリ ステートメントがスロー クエリ ログに記録されます。デフォルトのサーバー時間値を表示するには、次の手順を実行します。

注: 遅いクエリ時間は、ステートメントの実行自体が 10 秒を超えることを意味するだけではありません。他のリソースの要求やその他の理由によりブロックされたクエリ実行時間も含まれます。これらはすべて遅いクエリに記録されます。したがって、この低速クエリの継続時間は、考えられるすべての理由を含め、クエリの開始から終了までのすべての時間を表します。

スロークエリログの内容を表示する

MySQL トランザクション ログ

トランザクション: トランザクションは、コミットする必要がある一連の操作の集合です。送信された後にのみ、この一連の操作をトランザクションと呼ぶことができます。 （すべての操作が実行される、またはいずれも実行されない）

トランザクション ログ (InnoDB 固有のログ) は、トランザクションの効率を向上させるのに役立ちます。トランザクション ログを使用すると、ストレージ エンジンはテーブル内のデータを変更するときにメモリ コピーを変更するだけで済み、変更されたデータ自体を毎回ディスクに保存する必要なく、ハード ディスクに保存されているトランザクション ログに変更動作を記録することができます。トランザクション ログは追加されるため、ログを書き込む操作は、ディスク上の小さな領域でのシーケンシャル I/O になります。ディスク上の複数の場所でヘッドを移動する必要があるランダム I/O とは異なり、トランザクション ログは比較的高速です。トランザクション ログが永続化された後、メモリ内の変更されたデータはバックグラウンドでゆっくりとディスクにフラッシュバックされます。現在、ほとんどのストレージ エンジンはこれを実装しており、通常は先行書き込みログと呼ばれます。データを変更するには、ディスクに 2 回書き込む必要があります。

MySQL のトランザクションベースの操作は、対応するメモリ内のデータを直接変更します。変更後、変更が有効になっていることを確認できますが、ディスクには書き込まれません。最初にトランザクション ログに書き込まれ、その後定期的にディスクにフラッシュされます (トランザクション ログはディスクに順番に追加形式で書き込まれるため、トランザクションの効率が大幅に向上します)

データの変更がトランザクション ログに記録され、永続化されているが、データ自体がディスクに書き戻されておらず、システムがクラッシュした場合、ストレージ エンジンは再起動時に変更されたデータを自動的に復元できます。利用可能なリカバリ方法はストレージ エンジンによって異なります。

InnoDBエンジンはトランザクションをサポートするエンジンです

トランザクションログの定義を表示する

'%log%' のようなグローバル変数を表示します。

MySQL バイナリログ

バイナリ ログは変更ログとも呼ばれます。主に、データを変更したり、データの変更を引き起こす可能性のある MySQL ステートメントを記録するために使用されます。また、ステートメントの発生時刻、実行時間、操作データなども記録されます。したがって、バイナリ ログを使用して、MySQL データベースにどのような変更が加えられたかを照会できます。最大サイズは通常1G です。

'%log%' のようなグローバル変数を表示します。

sql_log_bin ={ON|OFF} #セッションレベルを制御するために使用されます (mysql に接続して操作ステートメントを実行するのはセッションレベルです。たとえば、mysql にファイルを直接インポートすることはセッションレベルとは見なされません) バイナリログ機能がオンまたはオフになります。デフォルトは ON で、ログ機能が有効になっていることを意味します。ユーザーはセッション レベルでこの変数の値を変更できますが、SUPER 権限を持っている必要があります。

binlog_cache_size =32768 #デフォルト値 32768 Binlog Cache は、バイナリログ (binlog) 記録機能がオンになっている環境で使用されます。これは、MySQL が binlog の記録効率を向上させるために設計したメモリ領域であり、binlog データを短期間一時的にキャッシュするために使用されます。一般的に、データベースに大きなトランザクションがなく、書き込みが特に頻繁でない場合は、2MB ～ 4MB が適切な選択です。ただし、データベースに多数の大規模なトランザクションと大量の書き込みがある場合は、binlog_cache_size を適切に増やすことができます。同時に、binlog_cache_use と binlog_cache_disk_use を使用して、設定された binlog_cache_size が十分かどうか、メモリ サイズが不足しているためにキャッシュに一時ファイル (binlog_cache_disk_use) を使用している binlog_cache が大量にあるかどうかを分析できます。

log_bin = mysql-bin # デフォルトではデータディレクトリにある binlog の場所を指定します。

binlog-format= {ROW|STATEMENT|MIXED} #バイナリ ログの種類を指定します。MIXED が推奨されます。バイナリ ログ形式が設定されているが、バイナリ ログが有効になっていない場合、MySQL の起動時に警告ログ情報が生成され、エラー ログに記録されます。

行: 各SQL文のコンテキストは記録せず、各データが変更されたことのみを記録します。

ステートメント: データを変更するすべてのSQLステートメントが記録されます

混合: 最初の2つの混合を示します

同期バイナリログ = 10 #バイナリ ログをディスク ファイルに同期する頻度を設定します。0 は同期しないことを意味し、正の値はバイナリへの書き込み操作が一定回数行われるたびに同期することを意味します。 autocommit の値が 1 の場合、各ステートメントの実行によってバイナリ ログ同期が行われます。それ以外の場合は、各トランザクションの送信によってバイナリ ログ同期が行われます。

バイナリ ログは、my.cnf の log-bin オプションを編集することで有効にできます。形式は次のとおりです。

DIR パラメータはバイナリ ファイルの保存パスを指定します。ファイル名パラメータは、ファイル名.番号の形式でバイナリ ファイルのファイル名を指定します。番号は 000001、000002 などの形式になります。 MySQL サービスを再起動するか、mysql> flush logs; を実行するたびに、新しいバイナリ ログ ファイルが生成され、これらのログ ファイルの数は増加し続けます。上記のファイルの生成に加えて、filename.index という名前のファイルも生成されます。このファイルには、バイナリ ファイル インデックスとも呼ばれるすべてのバイナリ ログ ファイルのリストが保存されます。

データベースサービスが再起動されるたびに、バイナリログファイルが生成されます。

バイナリログを表示します。

バイナリ ログはバイナリ形式で定義されます。この形式を使用すると、より多くの情報を保存でき、バイナリ ログへの書き込みがより効率的になります。ただし、view コマンドを直接使用してバイナリ ログを開いて表示することはできません。

小さな拡張: バイナリ ログの記録位置は通常、前回のイベント実行の終了時刻の位置です。各ログ ファイル自体には独自のメタデータがあるため、現在のバージョンの MySQL では、バイナリの開始位置は通常 107 です。

MySQLに接続し、データを変更してバイナリログを生成するいくつかのSQL文を入力します。

指定されたバイナリログ情報を表示する

コマンドラインでバイナリログを表示します。

cat などの方法を使用してバイナリ ログを直接開いて表示することはできないため、mysqlbinlog コマンドを使用する必要があります。ただし、MySQL の読み取りおよび書き込み操作の実行中に使用中のバイナリ ログ ファイルを開くためにこれを使用しないことをお勧めします。開く必要がある場合は、flushlogs を使用できます。 mysqlbinlog コマンドの使用方法:

このデータベースの情報をエクスポートします:

[root@stu18 データ]#mysqlbinlog mysql-bin.000017 > /tmp/a.sql

このデータベースにインポートする情報:

[root@stu18 データ]#mysql < a.sql

バイナリログ情報を削除します。

バイナリ ログには大量の情報 (役に立たない情報も含む) が記録されます。バイナリ ログが長期間クリーンアップされない場合、大量のディスク領域が無駄になります。ただし、削除するとデータベースがクラッシュして復旧できなくなる可能性があるため、バイナリ ログを削除する場合は、まずデータベースと一緒にバックアップする必要があります。バイナリ ログはバックアップ前にのみ削除でき、新しく生成されたログ情報は削除できません (ポイントインタイム リストアは実行できます)。 MySQL サーバーをシャットダウンした後で直接削除することはできません。データベースにエラーが発生する可能性があるためです。バイナリ ログを削除する必要がある場合は、バックアップ データベースとバイナリ ログ ファイルを圧縮アーカイブ ストレージにエクスポートする必要があります。バイナリ ファイルを削除するには:

すべてのバイナリ ログを削除するには、RESET MASTER ステートメントを使用します。ステートメントの形式は次のとおりです。

mysql> マスターをリセットします。

クエリは正常、影響を受けた行は 0 行 (0.17 秒)

mysql> バイナリログを表示します。

MySQL バックアップ ツール

mysqldump:論理バックアップツール。すべてのストレージエンジンに適用可能。ウォームバックアップに使用でき、フルバックアップ、部分バックアップを実現可能。InnoDB ストレージエンジン用。

ホットスタンバイをサポートします。

cp や tar などのファイル システム ツール:すべてのストレージ エンジンに適用可能な物理バックアップ ツール。コールド バックアップに使用され、完全バックアップと部分バックアップが可能です。

lvm2 スナップショット:ほぼホット バックアップ。物理バックアップはファイル システム ツールの助けを借りて実現されます。

mysqlhotcopy:ほぼコールド バックアップ。MyISAM ストレージ エンジンにのみ適用されます。

Mysql バックアップソリューション①mysqldump+binlog: (推奨)

フルバックアップ、バイナリログのバックアップによる増分バックアップ

②エクストラバックアップ:

InnoDBの場合: ホットスタンバイ、フルバックアップと増分バックアップのサポート

MyISAMの場合: ウォームバックアップ、フルバックアップのみがサポートされます

③lvm2スナップショット+binlog:

ほぼホットスタンバイ、物理バックアップ

mysqldump+binlogコマンドの構文フォーマット

mysqldump [オプション] データベース [テーブル]: 単一のデータベース、またはデータベースで指定された1つ以上のテーブルをバックアップします。

mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2DB3...]: 1つ以上のデータベースをバックアップします

mysqldump [オプション] --all-databases [オプション]: すべてのデータベースをバックアップします

その他のオプション

-x, --lock-all-tables: すべてのテーブルをロックする

-l, --lock-tables: バックアップテーブルをロックする

--single-transaction: バックアップを実行するために大規模な単一トランザクションを開始します

-C, --compress: 送信を圧縮する

-E, --events: 指定されたライブラリのイベントスケジューラをバックアップします

-R, --routines: ストアドプロシージャとストアド関数をバックアップします

--triggers: バックアップトリガー

--マスターデータ={0|1|2}

0: 記録しない

1: CHANGE MASTER TO ステートメントをログに記録します。このステートメントはコメント化されていません。

2: コメント文として記録する

-F, --flush-logs: テーブルをロックした後にフラッシュログコマンドを実行します

mysqldump+binlogのバックアップとリカバリ1.mysql設定ファイルを変更し、バイナリログを有効にする

vim /etc/my.cnf

ログビン = マスターログ

その後、mysqlを再起動します

systemctl で mariadb を再起動します。

バイナリログが生成されているかどうかを確認するには、mysqlと入力します。

2. バックアップディレクトリを準備する

3. データベースとテーブルのバックアップの準備

マイスク

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

magedu を使用します。

テーブル m(id int,name char(20)) を作成します。

4. 完全バックアップを作成する

mysqldump --all-databases --lock-all-tables --flush-log --master-data=2 > /backup/`date +%F_%T`-all.sql

5. テーブルにデータを挿入する

マイスク

magedu を使用します。

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

m26 (id,name) に値 (1,'fuming'),(2,'zhangmeng') を挿入します。

6. 増分バックアップとバイナリログのバックアップを実行する

mysqlbinlog --start-position=245 --stop-position=479 /var/lib/mysql/master-log.000002 > /backup/binlog/binlog-`date +%F_%T`.sql

開始位置と終了位置を決定する

マスターログを表示します。

'master-log.000002' の binlog イベントを表示します。

最後にはコミットを含める必要があります。

7. データの挿入を続け、バックアップなしでデータベースを削除し、誤操作をシミュレートする

8. データの回復。バックアップなしでデータベースを削除したので、まず最後のバイナリログを保護する必要があります。これらのバイナリログが失われると、回復できません。削除操作の前に位置の値を確認してください。mysqlbinlog /var/lib/mysql/master-log.000002

9. 最後の操作のバイナリログをバックアップする

mysqlbinlog --start-position=467 --stop-position=677 /var/lib/mysql/master-log.000002 > /backup/binlog/binlog-`date +%F_%T`.sql

ls /バックアップ/binlog/

10. 以前のバックアップをすべてインポートする

mysql < /backup/2017-12-07_20\:20\:04-all.sql フルバックアップをインポート

mysql < /backup/binlog/binlog-2017-12-07_20\:45\:17.sql 増分バックアップのインポート

mysql < /backup/binlog/binlog-2017-12-07_21\:05\:42.sql はデータベースを削除する前に増分バックアップをインポートします

11. データベースとデータを表示する

エクストラバックアップ

Xtrabackup は、Percona が提供する MySQL データベース バックアップ ツールです。公式の紹介によると、InnoDB および XtraDB データベースのホット バックアップを実行できるオープン ソース ツールです。

特徴：

（１）バックアッププロセスは高速かつ信頼性が高い

（２）バックアッププロセスは進行中のトランザクションを中断しない

（３）圧縮機能などによりディスク容量や通信量を節約できる

（4）自動バックアップ検証

（５）回復速度が速い

実験手順: (1) xtrabackupのインストール

yum インストール percona-xtrabackup -y

（２）フルバックアップ

innobackupex --user=root /backup

（３）データを追加する

mysql -uroot

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

マゲドゥを使う

テーブルm26(id int,name char(20))を作成します。

m26値に挿入（007、'fuming'）、（008、'zhangmeng'）

（4）増分バックアップ

innobackupex --incremental /backup/ --incremental-basedir=/backup/2017-11-16_16-53-4

（５）データ復旧の準備
1. 操作を実行します（完全バックアップ）。

innobackupex --apply-log --redo-only BASE-DIR (BASE-DIR は完全バックアップのディレクトリです)

例: innobackupex --apply-log --redo-only BASE-DIR --incrementaldir=/backup/2017-11-16_17-17-52/

2. 次に実行します（増分）：

innobackupex --apply-log --redo-only BASE-DIR --incrementaldir=INCREMENTAL-DIR-1 (INCREMENTAL-DIR-1 は増分バックアップディレクトリです)

例: innobackupex --apply-log --redo-only /backup/2017-11-16_16-53-43 --incrementaldir=/backup/2017-11-16_17-17-52/

（6）復旧フェーズ：データの復元

mv /var/lib/mysql /var/lib/mysql.bak はデータベースの削除をシミュレートします

mkdir /var/lib/mysql

/var/lib/mysql に移動します

innobackupex --copy-back /backup/2017-11-16_16-53-43 フルバックアップを復元

lvm2 スナップショット + バイナリログ

実験を行う前に、lvm2-snapshotの知識を復習しましょう。

簡単に言えば、LVM スナップショットは、ある時点でのスナップショット ソース パーティション内のすべてのファイルのメタデータを保存します。ソース ファイルが変更されていない場合、スナップショット ボリュームにアクセスする対応するファイルは、ソース パーティションのソース ファイルに直接ポイントします。ソース ファイルが変更された場合、スナップショット ボリューム内の対応するファイルは変更されません。スナップショット ボリュームは主にファイルのバックアップを支援するために使用されます。

実験手順:

1.ハードディスクを追加し、ディスクタイプをLVMタイプに分割する

エコー '- - -' > /sys/class/scsi_host/host2/scan

2. パーティション

t 8eはlvmです

partx -a /dev/sdb はカーネルに新しいディスクを認識させます。

3.pvcreate /dev/sdb1 を実行して物理ボリュームを追加します。

4.vgcreate myvg /dev/sdb1 を実行してボリュームグループを追加します。

5.lvcreate -n mydata -L 5G myvg で論理ボリュームを追加します

6. mkfs.ext4 /dev/mapper/myvg-mydataは論理ボリュームをフォーマットします

7. /dev/mapper/myvg-mydata /lvm_dataをマウントして使用する

8. データファイルが論理ボリュームdatadir=/lvm_data上にあるようにMysql設定を変更します。

9. service mysqld restartはMySQLサービスを起動します。

10. データベースを作成し、操作を実行する

11.mysql> FLUSH TABLES WITH READ LOCK; #テーブルをロックする

12. lvcreate -L 1G -n mydata-snap -pr -s /dev/mapper/myvgmydata

#スナップショットボリュームの作成 論理ボリューム「mydata-snap」が作成されました。

13.mysql> UNLOCK TABLES; #すべてのテーブルのロックを解除

14. mount /dev/myvg/mydata-snap /lvm_snap/ #スナップをマウントする

15. tar cvf /tmp/mysqlback.tar ./* #物理バックアップをパッケージ化

16. umount /lvm_snap/ #snapをアンインストールする

17. lvremove myvg mydata-snap #スナップを削除

18. mysqlデータを削除する rm -rf /lvm_data/*

19. 削除されたデータを解凍して復元する tar xvf /tmp/mysqlback.tar ./

20. データベースデータが正しく復元されたかどうかを確認する

要約する

さて、今日はここまでです。また次回お会いしましょう。

私が皆さんに共有したいのは、Mysql を使用してエンタープライズ レベルのログ管理、バックアップ、およびリカバリを実装する方法に関する上記の実用的なチュートリアルだけです。このチュートリアルが皆さんの参考になれば幸いです。また、123WORDPRESS.COM をサポートしていただければ幸いです。