MySQLのバックアップとリカバリの簡単な分析

1. はじめに

データは貴重です。データベース システムとして、MySQL のバックアップは非常に重要かつ必要です。バックアップには、障害の防止、セキュリティ要件、ロールバック、監査、削除および変更要件など、何千もの理由があります。バックアップの重要性は自明です。バックアップそのものだけでなく、そのバックアップをいかに活用してサービスを復旧するかも重要な課題です。復旧に活用できないバックアップは意味がありません。この記事では、主にバックアップとリカバリの 2 つの側面について簡単に紹介します。

この記事は、「High Performance MySQL」のバックアップ関連の章の読書メモです。

2. バックアップとリカバリの簡単な定義

冒頭でも述べたように、バックアップは誰もがよく知っていることであり、人々が注目するのは簡単です。要求に応じて通常のスクリプトを作成したり、他の方法を使用したりするのが一般的です。しかし、回復はそれほど劇的なものではなかった。たとえば、自動バックアップが毎週/毎日スケジュールされているとします。しかし、バックアップの復元テストはどのくらいの頻度で実行されるのでしょうか?バックアップは完了しましたか?回復に使えますか？障害が発生した場合、回復プロセスは簡単に実行できますか?

バックアップはデータ ソースのみです。データ ソースを使用してシステムを完全に復元する方法。これも非常に重要です。バックアップとリカバリは、MySQL の運用と保守において習得する必要があるものです。

バックアップの目的は回復です。復元できない場合は、バックアップとは呼ばれません (たとえば、RAID アレイはバックアップではありません。DROP DATABASE を実行すると、RAID アレイは復元できません)

[復元]と[回復]の違い:

• 復元: バックアップ ファイルから内容を抽出してロードすることを指します。
• リカバリ: バックアップ ファイルの復元、MySQL の再起動、構成の変更、その他の操作など、サービスを通常の動作に戻すための一連の対策。
  

つまり、リカバリとは、例外が発生する前に実行されたすべての操作 (パラメータの変更、サービスの再起動など) を復元することです。バックアップを復元するだけではありません。

3. 復旧計画で考慮すべきいくつかの要素

復旧計画を設計する際には、さまざまなニーズに応じてより適切な計画を実行できるように、いくつかの要素を考慮する必要があります。 RPO (目標復旧ポイント) と RTO (目標復旧時間) の 2 つの要件に基づいて、適切な復旧戦略を策定するのに役立ちます。

• RPO (目標復旧ポイント): どの程度のデータ損失が許容されるか? (すべてのデータを復元する必要がありますか、それとも最後のバックアップ以降のデータの損失を許容できますか?)
• RTO (目標復旧時間): データを復旧するのにどれくらいの時間がかかりますか? （ユーザーがどこまで受け入れることができるか）
  

おそらく、次のことも考慮する必要があります: 何を復元する必要があるか? (サーバー全体、単一のデータベース、単一のテーブル、またはトランザクション)

次に、リカバリ プランを定期的にテストし、データを抽出してバックアップが実際に有効かどうかをテストし、完全なバックアップ リカバリを実行してリカバリ プロセス全体を理解して、実際に問題が発生したときにリカバリが秩序正しく完了できるようにする必要があります。

4. バックアップ

4.1. バックアップには何が含まれますか?

最も簡単な戦略は、データとテーブル定義のみをバックアップすることです。ただし、データベースを復元するにはより多くのコンテンツが必要であり、バックアップが十分であればあるほど、復元は容易になります。 （主に需要に応じて）

たとえば、実際の状況に基づいて次のコンテンツをバックアップすることを検討できます。

1. Binlog および InnoDB トランザクション ログ。

2. マスター/スレーブ ライブラリ構成ファイル。

3. データベースのオペレーティング システム構成 (cron、スクリプト、カーネル パラメータ)

つまり、バックアップの内容は必要に応じて拡張できます。データベースの回復や再構築（より高速な回復など）の需要が高い場合は、より多くのコンテンツをバックアップする必要もあります。データベースを最初から復元する機能が必要な場合は、さらに作業が必要になります。

4.2 物理バックアップと論理バックアップ

物理バックアップと論理バックアップの間のちょっとした選択:

• 大規模なデータベースの場合、物理的なバックアップは必須です。論理バックアップが遅すぎる場合は、補助としてスナップショットベースのバックアップを使用することも検討できます。
• 小規模なデータベースの場合、論理バックアップでほぼ十分です。
  

物理バックアップはシンプルで効率的ですが、論理バックアップも可能な限り行う必要があります。 [特定のニーズとリソースの割り当てに応じて、両方が必要になります]

2 つ目: テストを行っていない限り、バックアップが使用可能であると想定することはできません。たとえば、データベースをテストするには、mysqlcheck -A を使用します。

4.3 バイナリログバックアップ

Binlog は、ポイントインタイムリカバリに必要なため、バックアップの重要な部分でもあります。さらに、Binlog は一般的に非常に小さいため、頻繁なバックアップの実装が容易です。特定の時点のデータのバックアップとそれ以降のすべての Binlog があれば、すべての変更をロールバックできます。

4.3.1. Binlog をバックアップするためのいくつかの戦略

フラッシュログ
--log_slave_updata

expire_log_days は、ログ ファイルの内容ではなく、変更時刻によって決定されることに注意してください。 (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

代わりに次の cron を使用してください。

0 3 * * * /usr/bin/mysql -e "CURRENT_DATE より前のマスターログを消去 - 間隔 N 日"

4.3.3. Binlog バックアップに関する注意事項

• 保持期間を長くすることは単なる構成であり、Binlog 自体をバックアップする必要がないことを意味するものではありません。最新のバックアップと組み合わせて使用​​できるように、バイナリログは定期的にバックアップする必要があります。
• スレーブ ライブラリも Binlog を使用することに注意してください。したがって、スレーブライブラリとバックアップの Binlog 管理を区別する必要があります。
  

4.4. 増分バックアップと差分バックアップ

増分バックアップ: あらゆるタイプのバックアップ以降に変更されたすべてのコンテンツのバックアップ。

差分バックアップ: 具体的には、最後の完全バックアップ以降に変更されたすべてのコンテンツのバックアップを指します。

つまり、差分バックアップは完全バックアップに基づいています。増分バックアップは、任意のバックアップ (指定された差分バックアップなど) に基づいています。

差分バックアップオプション:

• 変更されていないテーブルはバックアップしないでください。
• 変更されていない行をバックアップしない
  

差分バックアップを実行すると、回復速度が向上します。ただし、完全なバックアップは必要です。 (完全バックアップはより低い頻度で実行できますが、実行する必要があります)。

4.5. データベースからのバックアップ

スレーブでのバックアップは、マスターに干渉せず、マスターにさらなる負荷をかけないようにするオプションとなる場合があります。次に、スレーブからバックアップすることを計画している場合は、マスターに対するスレーブの位置 (オフセット) などの詳細な情報を保存する必要があります。

まず、スレーブ データベースはバックアップと等しくなく、スレーブ データベースとマスター データベースのデータが一致しないことが非常によくあります。第二に、スレーブ データベースからのバックアップは、確かにマスター データベースのバックアップ時の負荷を軽減できますが、それだけでは十分ではありません。安定性のために、メインデータベースのバックアップと完全バックアップを実行することをお勧めします。

4.6 その他の注意事項

4.6.1. オンラインバックアップとオフラインバックアップ

オフライン バックアップは最も簡単で安全です。一貫性も最高です。問題は、ほとんどのデータベースがバックアップのためのダウンタイムを許容できないことです。そのため、オンライン バックアップ、つまりノンストップ バックアップが引き続き使用されます。

業務のオフピーク時にオンラインバックアップを実行することを検討できます。これにより、負荷が増加しても大きな影響はありません。

4.6.2 データの一貫性

データの一貫性: 複数のテーブル間のデータの一貫性に関する要件。 (例えば、論理的に関連する2つの操作を2つのトランザクションに分割し、2つのトランザクション間でバックアップを実行すると、データの不整合が発生します)

InnoDB は、関連するテーブルのセットをダンプするときにトランザクションを開始できるため、データの一貫性を大幅に確保できます。

ただし、トランザクション設定が適切でない場合、たとえば、関連するテーブル セットの変更が 2 つのトランザクションに分割されている場合、データの不整合が発生する可能性があることに注意してください。 (テーブルセットに対する関連操作は 1 つのトランザクション内で確実に実行する必要があります)

4.6.3. 定期的にバックアップとリカバリのテストを実行し、リカバリプロセス全体に必要なリソースを確認します。

単にバックアップを取るだけでなく、復元できるバックアップが重要です。

まとめ

この記事では、バックアップの基本的な知識と概念、基本的な概念、リカバリの重要性、バックアップとリカバリの簡単な戦略について説明します。また、バックアップ コンテンツの選択、差分/増分バックアップ、Binlog バックアップなどについても説明します。バックアップとリカバリの具体的な操作方法と実践を理解するには、引き続き学習する必要があります。

上記は、MySQL のバックアップとリカバリの詳細についての簡単な分析です。MySQL のバックアップとリカバリの詳細については、123WORDPRESS.COM の他の関連記事に注目してください。