ディザスター リカバリー ドリルを実行する | Azure SQL データベース
適用対象: Azure SQL データベース
復旧ワークフローのためのアプリケーションの対応状況の検証は、定期的に実行することをお勧めします。 アプリケーションの動作、データの損失の影響やフェールオーバーによる中断を検証することをお勧めします。 これは、ビジネス継続性の証明として、ほとんどの業界標準で必要条件ともなっています。
ディザスター リカバリーの訓練は以下のもので構成されています。
- データ層の停止シミュレーション
- 復旧
- 復旧後のアプリケーションの整合性の検証
ビジネス継続性のためにアプリケーションをどのように設計したかによって、実行する訓練のワークフローは異なります。 この記事では、Azure SQL Database のコンテキストでディザスター リカバリーの訓練を行う際のベスト プラクティスについて説明します。
ディザスター リカバリーの訓練を実施する際のデータ損失の可能性を回避するために、運用環境のコピーから作成したテスト環境を使用して訓練を実行し、アプリケーションのフェールオーバーのワークフローの確認にもそれを使用することをお勧めします。
障害をシミュレートするために、ソース データベースの名前を変更できます。 この名前変更によって、アプリケーションの接続エラーが発生します。
- 「ディザスター リカバリー ガイダンス」の説明に従って、別のサーバーへのデータベースの geo リストアを実行します。
- アプリケーションの構成を変更して、復旧したデータベースに接続し、「復旧後のデータベースの構成」のガイドに従って、復旧を完了します。
復旧後に、アプリケーションの整合性を検証して訓練を完了します (接続文字列、ログイン、基本的な機能のテスト、その他の標準的なアプリケーションのサインオフのプロシージャの検証など)。
フェールオーバー グループを使用して保護されたデータベースの場合、ドリルには、セカンダリ サーバーへの計画フェールオーバーが含まれます。 計画されたフェールオーバーでは、ロールが切り替わったときに、フェールオーバー グループにあるプライマリ データベースとセカンダリ データベースの同期を維持するようにします。 計画外のフェールオーバーとは異なり、この操作ではデータは失われないため、訓練を運用環境で実行できます。
障害をシミュレートするために、データベースに接続されている Web アプリケーションまたは仮想マシンを無効にできます。 この障害のシミュレーションによって、Web クライアントの接続エラーが発生します。
- ディザスター リカバリー リージョンのアプリケーション構成が (完全にアクセス可能な新しいプライマリになる) 前のセカンダリをポイントしていることを確認します。
- セカンダリ サーバーから、フェールオーバー グループの計画フェールオーバーを開始します。
- 「 復旧後のデータベースの構成 」のガイドに従って、復旧を完了します。
復旧後に、アプリケーションの整合性を検証して訓練を完了します (接続性、基本的な機能のテスト、訓練のサインオフに必要なその他の検証など)。
詳細については、次を参照してください。
- 継続性のシナリオ。
- 自動バックアップ
- サービスによって開始されたバックアップからデータベースを復元します。
- より迅速な復旧オプションについては、アクティブ geo レプリケーションとフェールオーバー グループに関する記事を参照してください。
- 「ディザスター リカバリー ガイダンス」と「高可用性とディザスター リカバリーのチェックリスト」をご覧ください。