MySQLバックアップとリカバリの基本概念
1、紹介
データは無価で、MySQLはデータベースシステムとして、バックアップも自然に重要であり、必要である.バックアップの理由は千万、障害予防、セキュリティ要件、ロールバック、監査、削除、変更の要件など、バックアップの重要性は言うまでもありません.バックアップ自体に加えて、バックアップを使用してサービスをリカバリする方法も重要な内容であり、リカバリに使用できないバックアップは意味がありません.この文書では、バックアップとリカバリの両方について簡単に説明します.
本文は『高性能MySQL』の関連章の読書ノートをバックアップする.
2、バックアップとリカバリの簡単な定義
概要のように、バックアップ担当者はよく知られており、重視されやすい.必要に応じて定期的なスクリプトを書くか、他の方法を使うのが一般的です.しかし、回復はそれほど目立たなかった.たとえば、毎週/毎日定期的に自動バックアップを行う場合があります.しかし、バックアップのリカバリテストはどのくらい行われますか?バックアップの内容は完了しましたか?リカバリに使用できますか?障害が発生した場合、リカバリのプロセスは操作しやすいですか?バックアップはデータ・ソースにすぎず、データ・ソースをどのように使用してシステムを完全にリカバリするかというプロセスです.とても重要です.バックアップとリカバリは、MySQLの運用次元で把握する必要がある内容です.
バックアップの意味は、リカバリです.リカバリできない場合は、バックアップと呼ばない(例えば、RAIDアレイがバックアップではなく、DROP DATABASEの場合、RAIDアレイがリカバリできない)
[リストア]と[リカバリ]の違い:リストア:バックアップ・ファイルのコンテンツを抽出してロードすることのみを指します. リカバリ:MySQLの再起動、構成の変更など、サービスを正常に動作させるためのバックアップファイルのリストアを含む一連の措置です.
つまり、リカバリは、例外が出る前にリカバリするすべての操作(パラメータの変更、サービスの再起動など)です.バックアップをリストアするだけではありません.
3、回復計画に考慮すべきいくつかの要素
リカバリ計画は、設計時にいくつかの要因を考慮し、異なるニーズに応じてより良い計画を行う必要があります.RPO(RPO目標復旧時点)とRTO(目標復旧時間)の2つのニーズに基づいて、適切なリカバリポリシーの策定に協力できます. RPO(RPO目標復旧時点):どのくらいのデータの損失を許容できますか?(すべてのデータをリカバリする必要がありますか?それとも、前回のバックアップ以降のデータ損失を許容できますか?) RTO(リカバリ時間目標):データのリカバリをどのくらい待つ必要がありますか?(ユーザがどの程度納得できるか) 何を回復する必要があるのか、まだ考えなければならないかもしれません.(サーバ全体、単一ライブラリ、単一テーブル、またはトランザクション)
次に、リカバリ計画は定期的にテストを行う必要があり、データを抽出してバックアップが確かに有効で、実際に完全なバックアップリカバリを行い、リカバリプロセス全体を熟知し、本当に問題が発生した場合、秩序正しくリカバリを完了することができることを確保する.
4、バックアップ
4.1、バックアップ内容には何が含まれていますか.
最も簡単なポリシーは、データとテーブル定義のみをバックアップすることです.しかし、データベースのリカバリにはより多くのコンテンツが必要であり、バックアップが十分であればあるほど、リカバリが容易になります.(主に需要に応じて)
たとえば、1、Binlog、InnoDBトランザクション・ログのバックアップは、実際の状況に応じて考慮できます.2、マスター/スレーブプロファイル.3、データベースオペレーティングシステム構成(cron、スクリプト、カーネルパラメータ)
あるいは、必要に応じてバックアップコンテンツの拡張を行います.データベースのリカバリ、さらには再構築に必要な場合(より迅速なリカバリが必要など)、より多くのコンテンツをバックアップする必要があります.0からデータベースをリカバリする能力が必要な場合は、より多くの作業が必要です.
4.2、物理バックアップと論理バックアップ
バックアップの種類
論理バックアップ
物理バックアップ
概要
mysqldumpなどのコマンドによるバックアップ
データベース・ファイルの直接コピー
メリット
テキスト編集が可能で、リカバリが簡単で、mysqldumpを使用してバックアップが柔軟です.
直感的で、バックアップとリカバリのプロセスは、本質的にファイルの移動です.リカバリの高速化MySQLサーバでは、操作はほとんど必要ありません.
欠点
バックアップとリカバリには、MySQLサービスが必要であり、CPUリソースが必要です.遅いかもしれない
InnoDBの元のファイルは通常、論理バックアップよりもずっと大きいです.
物理バックアップと論理バックアップの選択:大きなデータベースでは、物理的なバックアップが必要です.論理バックアップが遅すぎて、スナップショットベースのバックアップを支援することも考えられます. 小さなデータベースでは、論理バックアップはほとんど可能です.
物理バックアップは簡単で効率的で、論理バックアップもできるだけしなければなりません.【両方とも、具体的な需要と資源配分を見てください】
次に、テストを行わない限り、バックアップが利用可能であるとは仮定できません.例えば
4.3、Binlogバックアップ
Binlogは、ポイント・イン・タイム・ベースのリカバリに必要なため、バックアップの重要な一環でもあります.またBinlogは一般的に小さく、頻繁なバックアップも容易に実現できます.ある時点のデータバックアップがあり、それ以降のすべてのBinlogを加えると、すべての変動をロールバックできます.
4.3.1、Binlogをバックアップするいくつかの策略推奨expire_logs_daysはできるだけ長く設定し、少なくとも2回の最近のフルバックアップを超えます. Binlogをバックアップする場合、 は、同時に失われないように、データとBinlogを別々に保存することを考慮することができる. は、Binlogを頻繁にバックアップするか、
注意が必要なのは、expire_log_デイズは
ログファイルの変更時間は、内容ではなく判断されます.(Binlogファイルが1つしかない場合は、クリーンアップされない可能性があります).だから必ず使う
4.3.2、古いBinlogの整理はexpireを使用することが望ましい.log_daysは自動的なクリーンアップを行い、一定の日数を保持します.cronでクリーンアップする必要がある場合.ではfind+rm構成のcronを使用してログをクリーンアップしないでください.
4.3.3、Binlogバックアップのいくつかの注意事項保存時間を増やすのは、Binlog自体がバックアップを必要としない構成にすぎません.Binlogは、最近のバックアップと組み合わせて使用できるように定期的にバックアップする必要があります. ライブラリからもBinlogが使用されていることに注意してください.したがって、ライブラリとバックアップのBinlog管理を区別する必要があります.
4.4、増分バックアップと差異バックアップ
≪インクリメンタル・バックアップ|Incremental Backup|emdw≫:任意のタイプのバックアップから変更されたすべてのコンテンツのバックアップ.差分バックアップ:特に、前回のフルバックアップ以降、変更されたすべてのコンテンツのバックアップを指します.
つまり、差分バックアップはフルバックアップに基づいています.インクリメンタル・バックアップは、指定した差分バックアップなど、任意のバックアップに基づいています.
次の例を挙げます.日曜日にフルバックアップを行い、月曜日に日曜日のフルバックアップに差分バックアップを行います.火曜日から2つの選択肢があります.1、日曜日のフルバックアップに基づいてバックアップを行う(違い).2、月曜日の差異に基づくバックアップ(増分)
差分バックアップオプション:変更されていないテーブルはバックアップしないでください. 変更されていない行 をバックアップしないでください.
このように差分バックアップを行うと、リカバリ速度が向上します.しかし、フルバックアップは必要です.(
フルバックアップは低頻度で実行できますが、必要です).
4.5、ライブラリからのバックアップ
ライブラリからのバックアップでは、プライマリ・ライブラリに干渉することなく、プライマリ・ライブラリへの負荷を増やすオプションがある場合があります.次に、スレーブ・ライブラリからのバックアップを計画する場合は、スレーブ・ライブラリのプライマリ・ライブラリに対する位置(オフセット)など、より多くの情報を保存します.
まず
スレーブ・ライブラリはバックアップと等しくなく、スレーブ・ライブラリとプライマリ・ライブラリのデータが一致しないのが一般的です.次に、スレーブ・バックアップからプライマリ・ライブラリのバックアップ時の負荷を確実に軽減できますが、十分ではありません.安定化のため、プライマリ・ライブラリのバックアップ、フル・バックアップを推奨します.
4.6、その他の注意事項
4.6.1、オンラインバックアップとオフラインバックアップオフラインバックアップは最も簡単で安全である.一致性が一番いいです.問題は、ほとんどのデータベースがダウンタイムバックアップを受け入れられないことです.基本的にはオンラインバックアップ、またはダウンタイムバックアップを使用します.
ビジネスのピーク時にオンラインバックアップを行うことも考えられ、負荷が増大しても大きな影響はありません.
4.6.2、データ整合性データ整合性:複数のテーブル間のデータの整合性に関する要求.(たとえば、2つの論理関係のオペレーションが2つのトランザクションに分割され、バックアップが2つのトランザクション間で実行されると、データが一致しなくなります)InnoDBは、関連するテーブルのセットをダンプするときに、1つのトランザクションを開始することで、データの一貫性を大幅に保証できます.
ただし、関連するテーブルのセットの変更が2つのトランザクションに分割されているなど、トランザクションの設定が不合理な場合、データが一致しないことにも注意してください.(
テーブルのセットに関するアクションは、トランザクション内であることを確認する必要があります.
4.6.3、定期的にバックアップ回復テストを行い、全体の回復過程に必要な資源が回復できるバックアップこそ価値があり、バックアップがあればいいのではないことを確認する.
小結
この文書では、バックアップの基本的な知識と概念について説明します.基本的な概念、リカバリの重要性、バックアップとリカバリの簡単なポリシーが含まれています.また,バックアップ内容の選択,差分/インクリメンタルバックアップ,Binlogバックアップなどについても言及した.バックアップとリカバリの具体的な操作方法と実践については、引き続き学習する必要があります.
データは無価で、MySQLはデータベースシステムとして、バックアップも自然に重要であり、必要である.バックアップの理由は千万、障害予防、セキュリティ要件、ロールバック、監査、削除、変更の要件など、バックアップの重要性は言うまでもありません.バックアップ自体に加えて、バックアップを使用してサービスをリカバリする方法も重要な内容であり、リカバリに使用できないバックアップは意味がありません.この文書では、バックアップとリカバリの両方について簡単に説明します.
本文は『高性能MySQL』の関連章の読書ノートをバックアップする.
2、バックアップとリカバリの簡単な定義
概要のように、バックアップ担当者はよく知られており、重視されやすい.必要に応じて定期的なスクリプトを書くか、他の方法を使うのが一般的です.しかし、回復はそれほど目立たなかった.たとえば、毎週/毎日定期的に自動バックアップを行う場合があります.しかし、バックアップのリカバリテストはどのくらい行われますか?バックアップの内容は完了しましたか?リカバリに使用できますか?障害が発生した場合、リカバリのプロセスは操作しやすいですか?バックアップはデータ・ソースにすぎず、データ・ソースをどのように使用してシステムを完全にリカバリするかというプロセスです.とても重要です.バックアップとリカバリは、MySQLの運用次元で把握する必要がある内容です.
バックアップの意味は、リカバリです.リカバリできない場合は、バックアップと呼ばない(例えば、RAIDアレイがバックアップではなく、DROP DATABASEの場合、RAIDアレイがリカバリできない)
[リストア]と[リカバリ]の違い:
つまり、リカバリは、例外が出る前にリカバリするすべての操作(パラメータの変更、サービスの再起動など)です.バックアップをリストアするだけではありません.
3、回復計画に考慮すべきいくつかの要素
リカバリ計画は、設計時にいくつかの要因を考慮し、異なるニーズに応じてより良い計画を行う必要があります.RPO(RPO目標復旧時点)とRTO(目標復旧時間)の2つのニーズに基づいて、適切なリカバリポリシーの策定に協力できます.
次に、リカバリ計画は定期的にテストを行う必要があり、データを抽出してバックアップが確かに有効で、実際に完全なバックアップリカバリを行い、リカバリプロセス全体を熟知し、本当に問題が発生した場合、秩序正しくリカバリを完了することができることを確保する.
4、バックアップ
4.1、バックアップ内容には何が含まれていますか.
最も簡単なポリシーは、データとテーブル定義のみをバックアップすることです.しかし、データベースのリカバリにはより多くのコンテンツが必要であり、バックアップが十分であればあるほど、リカバリが容易になります.(主に需要に応じて)
たとえば、1、Binlog、InnoDBトランザクション・ログのバックアップは、実際の状況に応じて考慮できます.2、マスター/スレーブプロファイル.3、データベースオペレーティングシステム構成(cron、スクリプト、カーネルパラメータ)
あるいは、必要に応じてバックアップコンテンツの拡張を行います.データベースのリカバリ、さらには再構築に必要な場合(より迅速なリカバリが必要など)、より多くのコンテンツをバックアップする必要があります.0からデータベースをリカバリする能力が必要な場合は、より多くの作業が必要です.
4.2、物理バックアップと論理バックアップ
バックアップの種類
論理バックアップ
物理バックアップ
概要
mysqldumpなどのコマンドによるバックアップ
データベース・ファイルの直接コピー
メリット
テキスト編集が可能で、リカバリが簡単で、mysqldumpを使用してバックアップが柔軟です.
直感的で、バックアップとリカバリのプロセスは、本質的にファイルの移動です.リカバリの高速化MySQLサーバでは、操作はほとんど必要ありません.
欠点
バックアップとリカバリには、MySQLサービスが必要であり、CPUリソースが必要です.遅いかもしれない
InnoDBの元のファイルは通常、論理バックアップよりもずっと大きいです.
物理バックアップと論理バックアップの選択:
物理バックアップは簡単で効率的で、論理バックアップもできるだけしなければなりません.【両方とも、具体的な需要と資源配分を見てください】
次に、テストを行わない限り、バックアップが利用可能であるとは仮定できません.例えば
mysqlcheck -Aデータベースをテストします.4.3、Binlogバックアップ
Binlogは、ポイント・イン・タイム・ベースのリカバリに必要なため、バックアップの重要な一環でもあります.またBinlogは一般的に小さく、頻繁なバックアップも容易に実現できます.ある時点のデータバックアップがあり、それ以降のすべてのBinlogを加えると、すべての変動をロールバックできます.
4.3.1、Binlogをバックアップするいくつかの策略
FLUSH LOGSを使用して新しいBinlogを作成できます(これにより、最新のBinlogをバックアップするだけです)--log_slave_updataの読み取り専用リポジトリを構成するかを選択できます.注意が必要なのは、expire_log_デイズは
ログファイルの変更時間は、内容ではなく判断されます.(Binlogファイルが1つしかない場合は、クリーンアップされない可能性があります).だから必ず使う
FLUSH LOGSは、Binlogを定期的に更新します.4.3.2、古いBinlogの整理はexpireを使用することが望ましい.log_daysは自動的なクリーンアップを行い、一定の日数を保持します.cronでクリーンアップする必要がある場合.ではfind+rm構成のcronを使用してログをクリーンアップしないでください.
0 3 * * * /usr/bin/mysql /var/log/mysql -mtime +N -name "mysql-bin.[0-9]"* | xargs rmは、0 3 * * * /usr/bin/mysql -e "PURGE MASTER LOGS BEFORE CURRENT_DATE - INTERVAL N DAY"の代わりに次のcronを使用します.4.3.3、Binlogバックアップのいくつかの注意事項
4.4、増分バックアップと差異バックアップ
≪インクリメンタル・バックアップ|Incremental Backup|emdw≫:任意のタイプのバックアップから変更されたすべてのコンテンツのバックアップ.差分バックアップ:特に、前回のフルバックアップ以降、変更されたすべてのコンテンツのバックアップを指します.
つまり、差分バックアップはフルバックアップに基づいています.インクリメンタル・バックアップは、指定した差分バックアップなど、任意のバックアップに基づいています.
次の例を挙げます.日曜日にフルバックアップを行い、月曜日に日曜日のフルバックアップに差分バックアップを行います.火曜日から2つの選択肢があります.1、日曜日のフルバックアップに基づいてバックアップを行う(違い).2、月曜日の差異に基づくバックアップ(増分)
差分バックアップオプション:
このように差分バックアップを行うと、リカバリ速度が向上します.しかし、フルバックアップは必要です.(
フルバックアップは低頻度で実行できますが、必要です).
4.5、ライブラリからのバックアップ
ライブラリからのバックアップでは、プライマリ・ライブラリに干渉することなく、プライマリ・ライブラリへの負荷を増やすオプションがある場合があります.次に、スレーブ・ライブラリからのバックアップを計画する場合は、スレーブ・ライブラリのプライマリ・ライブラリに対する位置(オフセット)など、より多くの情報を保存します.
まず
スレーブ・ライブラリはバックアップと等しくなく、スレーブ・ライブラリとプライマリ・ライブラリのデータが一致しないのが一般的です.次に、スレーブ・バックアップからプライマリ・ライブラリのバックアップ時の負荷を確実に軽減できますが、十分ではありません.安定化のため、プライマリ・ライブラリのバックアップ、フル・バックアップを推奨します.
4.6、その他の注意事項
4.6.1、オンラインバックアップとオフラインバックアップオフラインバックアップは最も簡単で安全である.一致性が一番いいです.問題は、ほとんどのデータベースがダウンタイムバックアップを受け入れられないことです.基本的にはオンラインバックアップ、またはダウンタイムバックアップを使用します.
ビジネスのピーク時にオンラインバックアップを行うことも考えられ、負荷が増大しても大きな影響はありません.
4.6.2、データ整合性データ整合性:複数のテーブル間のデータの整合性に関する要求.(たとえば、2つの論理関係のオペレーションが2つのトランザクションに分割され、バックアップが2つのトランザクション間で実行されると、データが一致しなくなります)InnoDBは、関連するテーブルのセットをダンプするときに、1つのトランザクションを開始することで、データの一貫性を大幅に保証できます.
ただし、関連するテーブルのセットの変更が2つのトランザクションに分割されているなど、トランザクションの設定が不合理な場合、データが一致しないことにも注意してください.(
テーブルのセットに関するアクションは、トランザクション内であることを確認する必要があります.
4.6.3、定期的にバックアップ回復テストを行い、全体の回復過程に必要な資源が回復できるバックアップこそ価値があり、バックアップがあればいいのではないことを確認する.
小結
この文書では、バックアップの基本的な知識と概念について説明します.基本的な概念、リカバリの重要性、バックアップとリカバリの簡単なポリシーが含まれています.また,バックアップ内容の選択,差分/インクリメンタルバックアップ,Binlogバックアップなどについても言及した.バックアップとリカバリの具体的な操作方法と実践については、引き続き学習する必要があります.