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