次の方法で共有

拡張された前処理と後処理によるデータベースと整合性のあるスナップショット

Azure Backup には、バックアップ中に Linux VM のアプリケーションの一貫性を確保するための組み込みの プリスクリプトと postscript フレームワーク が用意されています。 このフレームワークでは、ディスク スナップショットの前にアプリケーションを静かにする前付き文字と、スナップショットの後の通常の操作にアプリケーションを復元する後付き文字が自動的に実行されます。

カスタムの前付き文字と後付き文字の管理は、多くの場合、複雑で時間がかかります。 このプロセスを簡略化するために、Azure Backup では、一般的なデータベースに対してすぐに使用できる前付き文字と後付き文字を提供し、最小限の労力とメンテナンスでアプリケーション整合性スナップショットを有効にします。

次の図は、Azure Backup で拡張されたプリスクリプトと postscript を使用して、Linux データベースのアプリケーション整合性スナップショットを実現し、信頼性の高いバックアップと回復を実現する方法を示しています。

Azure Backup による Linux アプリケーション整合性スナップショットを示す図。

拡張されたプレスクリプトおよびポストスクリプトフレームワークの主な利点

新しい 強化された プレスクリプトとポストスクリプトのフレームワークには、以下の主な利点があります。

  • これらのプレスクリプトとポストスクリプトは、バックアップ拡張機能と共に Azure VM に直接インストールされるため、スクリプトを作成して外部の場所からダウンロードする必要がなくなります。
  • 前付き文字と後付き文字の定義と内容は、 GitHub で確認できます。 提案や変更は GitHub を通じて送信できます。これはトリアージされ、より広範なコミュニティに役立つよう追加されています。
  • 他のデータベース用の新しい前処理スクリプトと後処理スクリプトは、GitHubを介して利用可能です。これらはトリアージされ、より広範なコミュニティの利益のために対処されています。
  • この堅牢なフレームワークは、プリスクリプトの実行エラーやクラッシュなどのシナリオを処理するのに効率的です。 いずれにしても、ポストスクリプトは自動的に実行され、プリスクリプトで行われたすべての変更がロールバックされます。
  • また、このフレームワークには、外部ツールが更新プログラムをフェッチし、任意のメッセージまたはイベントに対して独自のアクション プランを準備するための メッセージング チャネルも用意されています。

強化されたプリスクリプトおよびポストスクリプト フレームワークのソリューション フロー

次の図は、データベース整合性スナップショットの拡張された前付きおよび後付きフレームワークのソリューション フローを示しています。

ソリューション フローを示す図。

サポート マトリックス

拡張フレームワークでは、次のデータベースについて説明します。

前提条件

接続の詳細を指定するには、 /etc/azureの workload.conf という構成ファイルのみを変更する必要があります。 この方法で、Azure Backup は関連するアプリケーションに接続し、前付き文字と後付き文字を実行できます。 構成ファイルには、次のパラメーターがあります。

[workload]
# valid values are mysql, oracle
workload_name =
command_path = 
linux_user =
credString = 
ipc_folder = 
timeout =

次の表では、パラメーターについて説明します。

パラメーター Mandatory 説明
workload_name はい アプリケーション整合性バックアップが必要なデータベースの名前を格納します。 現在サポートされる値は oracle または mysql です。
command_path/configuration_path ワークロード バイナリへのパスが含まれています。 ワークロード バイナリがパス変数として設定されている場合、このフィールドは必須ではありません。
linux_user はい データベース ユーザーサインインにアクセスできる Linux ユーザーのユーザー名が含まれます。 この値が設定されていない場合、root は既定のユーザーと見なされます。
credString データベースに接続するための資格情報文字列を表します。 サインイン文字列全体を格納します。
ipc_folder ワークロードは、特定のファイル システム パスにのみ書き込むことができます。 このフォルダパスを指定して、プリスクリプトが状態をこのフォルダパスに書き込めるようにします。
timeout はい データベースがクワイエット状態である最大時間制限。 既定値は 90 秒です。 60 秒未満の値を設定しないでください。

Note

JSON 定義は、Azure Backup が特定のデータベースに合わせて変更する可能性があるテンプレートです。 各データベースの構成ファイルを理解するには、 各データベースのマニュアルを参照してください。

拡張された前付きおよび後付き文字フレームワークを使用する全体的なエクスペリエンスは次のとおりです。

  • データベース環境を準備します。
  • 構成ファイルを編集します。
  • VM バックアップをトリガーします。
  • 必要に応じて、アプリケーション整合性復旧ポイントから VM またはディスクまたはファイルを復元します。

データベース バックアップ戦略を構築する

ストリーミングの代わりにスナップショットを使用する

通常、ストリーミング バックアップ (完全バックアップ、差分バックアップ、増分バックアップなど) とログは、バックアップ戦略でデータベース管理者によって使用されます。 設計の重要なポイントは次のとおりです。

  • パフォーマンスとコスト: 毎日の完全バックアップとログは、復元中に最も高速ですが、かなりのコストがかかります。 差分または増分ストリーミング バックアップの種類を含めると、コストは削減されますが、復元のパフォーマンスに影響する可能性があります。 しかしスナップショットでは、パフォーマンスとコストの最適な組み合わせが提供されます。 スナップショットは本質的に増分的であるため、バックアップ中のパフォーマンスへの影響が最も少ないため、高速に復元され、コストも節約されます。
  • データベースまたはインフラストラクチャへの影響: ストリーミング バックアップのパフォーマンスは、基になるストレージ IOPS と、ストリームがリモートの場所を対象とする場合に使用できるネットワーク帯域幅によって異なります。 スナップショットにはこの依存関係がなく、IOPS とネットワーク帯域幅に対する需要が減少します。
  • 再利用性: 異なる種類のストリーミング バックアップをトリガーするためのコマンドはデータベースごとに異なるので、スクリプトを簡単に再利用することはできません。 また、さまざまなバックアップの種類を使用している場合は、依存関係チェーンを評価してライフ サイクルを維持してください。 スナップショットの場合、依存関係チェーンがないため、スクリプトを簡単に記述できます。
  • 長期保有: 完全バックアップは、個別に移動および回復できるため、長期保有に常に役立ちます。 短期的な保有期間を持つ運用バックアップでは、スナップショットが適しています。

毎日のスナップショットと、長期保有のための完全バックアップが不定期に行われるログは、データベースに最適なバックアップ ポリシーです。

ログ バックアップ戦略

拡張された前付きおよび後付きフレームワークは、1 日に 1 回バックアップをスケジュールする Azure VM バックアップ上に構築されています。 このため、目標復旧ポイント (RPO) が 24 時間のデータ損失期間は、運用データベースには適していません。 このソリューションは、ログ バックアップが明示的にストリーミングされるログ バックアップ戦略によって補完されます。

Azure Blob Storage 上のネットワーク ファイル システム (NFS) と AFS (プレビュー) 上の NFS は、データベース VM にボリュームを直接簡単にマウントし、データベース クライアントを使用してログ バックアップを転送するのに役立ちます。 RPO であるデータ損失ウィンドウは、ログ バックアップの頻度によって決まります。 また、NFS ターゲットは高パフォーマンスである必要はありません。 データベース整合性スナップショットを作成した後、運用バックアップに対して通常のストリーミング (完全および増分) をトリガーする必要がない場合があります。

Note

通常、拡張されたプリスクリプトは、スナップショットを取得するためにデータベースを停止する前に、転送中のすべてのログトランザクションをログバックアップ先にフラッシュするようにします。 その結果、スナップショットはデータベース整合性があり、復旧中は信頼性が高くなります。

復旧戦略

データベース整合性スナップショットが作成され、ログ バックアップが NFS ボリュームにストリーミングされた後、データベースの復旧戦略では、Azure VM バックアップの復旧機能を使用できます。 ログバックアップを行う機能は、データベースクライアントを使用して適用されます。 復旧戦略のオプションは次のとおりです。

  • データベース整合性復旧ポイントから新しい VM を作成します。 この VM には、接続されたログ マウント ポイントが既にあるはずです。 データベース クライアントを使用して、ポイントインタイム リストアのための復旧コマンドを実行します。
  • データベース整合性復旧ポイントからディスクを作成し、別のターゲット VM に接続します。 次に、ログの宛先をマウントし、データベース クライアントを使用して、ポイントインタイム リカバリー用の復旧コマンドを実行します。
  • ファイル回復オプションを使用し、スクリプトを生成します。 ターゲット VM でスクリプトを実行し、復旧ポイントを iSCSI ディスクとして接続します。 次に、データベース クライアントを使用して、アタッチされているディスクでデータベース固有の検証機能を実行し、バックアップ データを検証します。 また、データベース 全体を復旧するのではなく、データベース クライアントを使用して、いくつかのテーブルまたはファイルをエクスポートまたは回復します。
  • リージョンの災害時には、リージョンをまたがる復元機能を使用して、セカンダリ ペア リージョンから前述のアクションを実行します。

まとめ

データベース整合性スナップショットとカスタム ソリューションを使用してバックアップされたログを使用すると、パフォーマンスとコスト効率に優れたデータベース バックアップ ソリューションを構築できます。 このソリューションでは、Azure VM バックアップの利点を使用し、データベース クライアントの機能も再利用します。

  • Last updated on