次の方法で共有

ディザスター リカバリー ドリルを実行する | Azure SQL データベース

  • [アーティクル]

適用対象: Azure SQL データベース

復旧ワークフローのためのアプリケーションの対応状況の検証は、定期的に実行することをお勧めします。 アプリケーションの動作、データの損失の影響やフェールオーバーによる中断を検証することをお勧めします。 これは、ビジネス継続性の証明として、ほとんどの業界標準で必要条件ともなっています。

ディザスター リカバリーの訓練は以下のもので構成されています。

  • データ層の停止シミュレーション
  • 復旧
  • 復旧後のアプリケーションの整合性の検証

ビジネス継続性のためにアプリケーションをどのように設計したかによって、実行する訓練のワークフローは異なります。 この記事では、Azure SQL Database のコンテキストでディザスター リカバリーの訓練を行う際のベスト プラクティスについて説明します。

geo リストア

ディザスター リカバリーの訓練を実施する際のデータ損失の可能性を回避するために、運用環境のコピーから作成したテスト環境を使用して訓練を実行し、アプリケーションのフェールオーバーのワークフローの確認にもそれを使用することをお勧めします。

障害のシミュレーション

障害をシミュレートするために、ソース データベースの名前を変更できます。 この名前変更によって、アプリケーションの接続エラーが発生します。

Recovery

検証

復旧後に、アプリケーションの整合性を検証して訓練を完了します (接続文字列、ログイン、基本的な機能のテスト、その他の標準的なアプリケーションのサインオフのプロシージャの検証など)。

フェールオーバー グループ

フェールオーバー グループを使用して保護されたデータベースの場合、ドリルには、セカンダリ サーバーへの計画フェールオーバーが含まれます。 計画されたフェールオーバーでは、ロールが切り替わったときに、フェールオーバー グループにあるプライマリ データベースとセカンダリ データベースの同期を維持するようにします。 計画外のフェールオーバーとは異なり、この操作ではデータは失われないため、訓練を運用環境で実行できます。

障害のシミュレーション

障害をシミュレートするために、データベースに接続されている Web アプリケーションまたは仮想マシンを無効にできます。 この障害のシミュレーションによって、Web クライアントの接続エラーが発生します。

Recovery

  • ディザスター リカバリー リージョンのアプリケーション構成が (完全にアクセス可能な新しいプライマリになる) 前のセカンダリをポイントしていることを確認します。
  • セカンダリ サーバーから、フェールオーバー グループの計画フェールオーバーを開始します。
  • 「 復旧後のデータベースの構成 」のガイドに従って、復旧を完了します。

検証

復旧後に、アプリケーションの整合性を検証して訓練を完了します (接続性、基本的な機能のテスト、訓練のサインオフに必要なその他の検証など)。

関連するコンテンツ

詳細については、次を参照してください。