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