データベース整合性スナップショットのための拡張事前/事後スクリプト

Microsoft Azure Backup サービスには、Microsoft Azure Backup を使用して Linux VM がアプリケーションの整合性を実現するための事前/事後スクリプト フレームワークが既に提供されています。 これには、ディスクのスナップショットを作成する前に (アプリケーションを停止するために) 事前スクリプトを呼び出すことと、アプリケーションを通常モードに戻すためにスナップショットの完了後に事後スクリプト (アプリケーションを停止解除するためのコマンド) を呼び出すことが含まれます。

事前/事後スクリプトの作成、デバッグ、メンテナンスは困難な場合があります。 この複雑さを解消するため、Azure Backup には、マーキー データベースにおいて最小限のオーバーヘッドでアプリケーション整合性スナップショットを取得するために、簡素化された事前/事後スクリプトのエクスペリエンスが用意されています。

新しい "拡張" 事前/事後スクリプト フレームワークには、以下のような主な利点があります。

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

ソリューション フロー

サポート マトリックス

拡張フレームワークの対象となるデータベースの一覧を次に示します。

• Oracle (一般公開) - サポート マトリックスへのリンク
• MySQL (プレビュー)

前提条件

接続の詳細を指定するために必要なのは、/etc/azure の構成ファイル workload.conf を変更することだけです。 これで、Azure Backup が関連アプリケーションに接続し、事前/事後スクリプトを実行できるようになります。 構成ファイルには、次のパラメーターがあります。

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

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

拡張事前/事後スクリプト フレームワークを使用するための全体的なエクスペリエンスは次のとおりです。

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

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

ストリーミングでなくスナップショットの使用

通常、ストリーミング バックアップ (完全バックアップ、差分バックアップ、増分バックアップなど) とログは、バックアップ戦略でデータベース管理者によって使用されます。 以下に、設計上の重要な要点の一部を示します。

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

そのため、毎日のスナップショットとログに加えて、長期保有のための完全バックアップを時折実施することが、データベースにとって最適なバックアップ ポリシーです。

ログ バックアップ戦略

拡張事前/事後スクリプト フレームワークは、1 日に 1 回バックアップをスケジュールする Azure VM バックアップ上に構築されています。 そのため、RPO の 24 時間のデータ損失期間は、実稼働データベースには適していません。 このソリューションは、ログ バックアップが明示的にストリーミングされるログ バックアップ戦略によって補完されます。

BLOB で NFS を使用したり、AFS (プレビュー) で NFS を使用したりすると、データベース VM にボリュームを直接マウントし、データベース クライアントを使用してログ バックアップを転送することが容易になります。 RPO であるデータ損失期間は、ログ バックアップの頻度まで低下します。 また、データベース整合性スナップショットの作成後に、運用バックアップのために定期的なストリーミング (完全と増分) をトリガーする必要がない場合もあるため、NFS ターゲットは高パフォーマンスである必要はありません。

復旧戦略

データベース整合性スナップショットが作成され、ログ バックアップが NFS ボリュームにストリーミングされると、データベースの復旧戦略では、Azure VM バックアップの復旧機能を利用できます。 データベース クライアントを使用して、それに、ログ バックアップの機能がさらに加わります。 復旧戦略のいくつかのオプションを次に示します。

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

まとめ

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