フェールオーバーグループの概要とベストプラクティス (Azure SQL Managed Instance)

2025-09-11

この記事では、フェールオーバーグループ機能の概要と、Azure SQL Managed Instance で使用するためのベストプラクティスと推奨事項について説明します。フェールオーバーグループ機能を使用すると、SQL マネージドインスタンス内のすべてのユーザーデータベースのレプリケーションとフェールオーバーを別の Azure リージョンに管理できます。

開始するには、 Azure SQL Managed Instance のフェールオーバーグループの構成に関するページを参照してください。

概要

フェールオーバーグループ機能を使用すると、ある SQL マネージドインスタンスから別の Azure リージョン内の別の SQL マネージドインスタンスへのユーザーデータベースのレプリケーションとフェールオーバーを管理できます。フェールオーバーグループは、geo レプリケーションデータベースの大規模なデプロイと管理を簡略化するように設計されています。

詳しくは、Azure SQL Managed Instance の高可用性に関する記事をご覧ください。 geo フェールオーバー RPO と RTO については、「ビジネス継続性の概要」を参照してください。

エンドポイントリダイレクト

フェールオーバーグループは、geo フェールオーバー中も変更されない読み取り/書き込みおよび読み取り専用リスナーエンドポイントを提供します。接続は現在のプライマリに自動的にルーティングされるので、geo フェールオーバー後にアプリケーションの接続文字列を変更する必要はありません。 geo フェールオーバーでは、グループ内のすべてのセカンダリデータベースがプライマリロールに切り替まれます。 geo フェールオーバーが完了すると、DNS レコードが自動的に更新され、エンドポイントが新しいリージョンにリダイレクトされます。

読み取り専用ワークロードをオフロードする

プライマリデータベースへのトラフィックを減らすために、フェールオーバーグループ内のセカンダリデータベースを使用して、読み取り専用ワークロードをオフロードすることもできます。読み取り専用リスナーを使用して、読み取り専用のトラフィックを読み取り可能なセカンダリデータベースに送信します。

アプリケーションの回復

完全なビジネス継続性を実現するには、リージョンデータベースの冗長性を追加する方法は、ソリューションの一部に限定されます。致命的な障害の後にアプリケーション (サービス) をエンドツーエンドで復旧するには、そのサービスと依存しているサービスを構成するすべてのコンポーネントを復旧する必要があります。このようなコンポーネントの例には、クライアントソフトウェア (カスタム JavaScript が設定されたブラウザーなど)、Web フロントエンド、ストレージ、DNS などがあります。すべてのコンポーネントが同じ障害に耐性を持ち、アプリの復元時間目標（RTO）内で利用可能になることが重要です。そのため、依存するサービスをすべて特定し、これらのサービスが提供する保証と機能について把握しておく必要があります。そのうえで、依存するサービスのフェールオーバー中もサービスが確実に機能するように対策を講じる必要があります。

フェールオーバーポリシー

フェールオーバーグループでは、次の 2 つのフェールオーバーポリシーがサポートされています。

カスタマーマネージド (推奨) - お客様は、フェールオーバーグループ内の 1 つ以上のデータベースに影響を与える予期しない停止に気付いたときに、グループのフェールオーバーを実行できます。 PowerShell、Azure CLI、Rest API などのコマンドラインツールを使用する場合、カスタマーマネージドのフェールオーバーポリシー値は manual.
Microsoft マネージド - プライマリリージョンに影響を与える広範囲にわたる停止が発生した場合、Microsoft は、Microsoft が管理するように構成されたフェールオーバーポリシーを持つ影響を受ける すべての フェールオーバーグループのフェールオーバーを開始します。マイクロソフトマネージドフェールオーバーは、個々のフェールオーバーグループまたはリージョン内のフェールオーバーグループのサブセットに対して開始されません。 PowerShell、Azure CLI、Rest API などのコマンドラインツールを使用する場合、マイクロソフトが管理するフェールオーバーポリシーの値は automatic.

次の表に示すように、各フェールオーバーポリシーには、一意のユースケースセットと、フェールオーバースコープとデータ損失に対する対応する想定があります。

フェールオーバーポリシー	フェールオーバースコープ	ユースケース	データ損失の可能性
お客様による管理 (おすすめ)	フェールオーバーグループ	フェールオーバーグループ内の 1 つ以上のデータベースが停止の影響を受け、使用できなくなります。フェールオーバーを選択できます。	はい
Microsoft マネージド	リージョン内のすべてのフェールオーバーグループ	リージョンで広範囲にわたる障害が発生すると、データベースが使用できなくなるので、Microsoft Azure SQL サービスチームは強制フェールオーバーをトリガーすることを決定します。このオプションは、ディザスターリカバリーの責任をマイクロソフトに委任する必要があり、アプリケーションが少なくとも 1 時間以上の RTO (ダウンタイム) に耐えられる場合にのみ使用します。 Microsoft マネージドフェールオーバーは、極端な状況でのみ実行される場合があります。カスタマーマネージドフェールオーバーポリシーを強くお勧めします。	はい

お客様による管理

まれに、組み込みの可用性や高可用性では停止を軽減できません。また、フェールオーバーグループ内のデータベースは、データベースを使用するアプリケーションのサービスレベルアグリーメント (SLA) に許容できない期間は使用できなくなる可能性があります。データベースは、少数のデータベースのみに影響するローカライズされた問題が原因で使用できない場合があります。または、データセンター、可用性ゾーン、またはリージョンレベルにある可能性があります。いずれの場合も、ビジネス継続性を復元するために、強制フェールオーバーを開始できます。

フェールオーバーポリシーをカスタマーマネージドに設定することを強くお勧めします。フェールオーバーを開始してビジネス継続性を復元するタイミングを制御できます。フェールオーバーグループ内の 1 つ以上のデータベースに影響を与える予期しない停止が発生した場合に、フェールオーバーを開始できます。

Microsoft マネージド

マイクロソフトマネージドフェールオーバーポリシーでは、ディザスターリカバリーの責任が Azure SQL サービスに委任されます。 Azure SQL サービスで強制フェールオーバーを開始するには、次の条件を満たす必要があります。

自然災害イベント、構成の変更、ソフトウェアのバグまたはハードウェアコンポーネントの障害、およびリージョン内の多くのデータベースによって発生するリージョンレベルの停止が影響を受けます。
猶予期間が切れています。停電の規模を確認し、緩和するかどうかは人間の行動に依存するため、猶予期間を 1 時間以下に設定することはできません。

これらの条件が満たされると、Azure SQL サービスは、フェールオーバーポリシーがマイクロソフトマネージドに設定されているリージョン内のすべてのフェールオーバーグループに対して強制フェールオーバーを開始します。

重要

カスタマーマネージドフェールオーバーポリシーを使用して、ディザスターリカバリー計画をテストして実装します。 Microsoft マネージドフェールオーバーに依存しないでください。これは Microsoft がやむを得ない場合にのみ実行することがあります。 Microsoft マネージドフェールオーバーは、そのフェールオーバーポリシーが Microsoft マネージドに設定されているリージョン内のすべてのフェールオーバーグループに対して開始されます。個々のフェールオーバーグループに対して開始することはできません。フェールオーバーグループを選択的にフェールオーバーする必要がある場合は、カスタマーマネージドフェールオーバーポリシーを使用します。

フェールオーバーポリシーは、次の場合にのみマイクロソフトマネージドに設定します。

ディザスターリカバリーの責任を Azure SQL サービスに委任する必要があります。
アプリケーションは、データベースが少なくとも 1 時間以上使用できないことに耐えられます。
強制フェールオーバーの実際の時間は大きく異なる可能性があるため、猶予期間の有効期限が切れた後に強制フェールオーバーをトリガーすることは許容されます。
ゾーンの冗長性の構成や可用性の状態に関係なく、フェールオーバーグループ内のすべてのデータベースがフェールオーバーしてもかまいません。ゾーン冗長用に構成されたデータベースはゾーン障害に対する回復性があり、障害の影響を受ける可能性はありませんが、マイクロソフトマネージドフェールオーバーポリシーを使用するフェールオーバーグループの一部である場合でもフェールオーバーされます。
アプリケーションが使用する他の Azure サービスまたはコンポーネントに対するアプリケーションの依存関係を考慮せずに、フェールオーバーグループ内のデータベースを強制的にフェールオーバーすることは許容されます。これにより、アプリケーションのパフォーマンスの低下や使用不能が発生する可能性があります。
強制フェールオーバーの正確な時刻を制御できず、セカンダリデータベースの同期状態を無視するため、不明な量のデータ損失が発生してもかまいません。
フェールオーバーグループ内のプライマリレプリカとセカンダリレプリカのサービスレベル、コンピューティングレベル、コンピューティングサイズは同じです。

マイクロソフトによってフェールオーバーがトリガーされると、操作名 Failover Azure SQL フェールオーバーグループのエントリが Azure Monitor アクティビティログに追加されます。エントリには[リソース] の下のフェールオーバーグループの名前が含まれ、イベントによって開始されたイベントには、フェールオーバーがマイクロソフトによって開始されたことを示す 1 つのハイフン (-) が表示されます。この情報は、Azure portal の新しいプライマリサーバーまたはインスタンスの [アクティビティログ] ページでも確認できます。

用語と機能

フェールオーバーグループ (FOG)

フェールオーバーグループを使用すると、プライマリリージョンの停止によってプライマリ SQL マネージドインスタンスが使用できなくなった場合に備えて、SQL マネージドインスタンス内のすべてのユーザーデータベースを 1 つのユニットとして別の Azure リージョンにフェールオーバーできます。 SQL Managed Instance のフェールオーバーグループには、そのインスタンス内のすべてのユーザーデータベースが含まれています。そのため、1 つインスタンスにつき構成できるフェールオーバーグループは 1 つのみとなります。

重要

フェールオーバーグループの名前は、.database.windows.net ドメイン内でグローバルに一意である必要があります。
プライマリ

フェールオーバーグループ内のプライマリデータベースをホストする SQL マネージドインスタンス。
セカンダリ

フェールオーバーグループ内のセカンダリデータベースをホストする SQL マネージドインスタンス。セカンダリをプライマリと同じ Azure リージョンに配置することはできません。

重要

データベースにインメモリ OLTP オブジェクトが含まれている場合、インメモリ OLTP オブジェクトがメモリ内に存在するため、プライマリインスタンスとターゲットセカンダリ geo レプリカデータベースには一致するサービスレベルが必要です。 geo レプリカインスタンスのサービスレベルが低いと、メモリ不足の問題が発生する可能性があります。この問題が発生すると、セカンダリレプリカがデータベースの復旧に失敗し、セカンダリデータベースと geo セカンダリ上のインメモリ OLTP オブジェクトが使用できなくなる可能性があります。これにより、フェールオーバーも失敗する可能性があります。これを回避するには、geo セカンダリインスタンスのサービスレベルがプライマリデータベースのサービスレベルと一致していることを確認します。サービスレベルのアップグレードは、データサイズの操作になる場合があり、完了するまでに時間がかかる場合があります。

フェールオーバー (データ損失なし)

フェールオーバーでは、セカンダリがプライマリロールに切り替わる前に、プライマリデータベースとセカンダリデータベース間の完全なデータ同期が行われます。これにより、データ損失が発生しないことが保証されます。フェールオーバーは、プライマリにアクセスできる場合にのみ可能です。フェールオーバーは、次のシナリオで使用されます。
- データ損失が許容されない場合は、運用環境でディザスターリカバリー (DR) ドリルを行います
- ワークロードを別のリージョンに再配置します
- 機能停止が軽減 (フェールバック) された後、ワークロードをプライマリリージョンに返します
強制フェールオーバー (データ損失の可能性)

強制フェールオーバーの場合、最近の変更がプライマリから反映されるのを待たずに、直ちにセカンダリがプライマリに切り替わります。この操作を実行するとデータが失われる可能性があります。強制フェールオーバーは、機能停止時においてプライマリにアクセスできない場合に回復手段として使用されます。停止が緩和されると、以前のプライマリは自動的に再接続され、新しいセカンダリになります。フェールオーバーを実行してフェールバックし、レプリカを元のプライマリとセカンダリのロールに戻すこともできます。
データ消失の猶予期間

非同期レプリケーションを使用してデータがセカンダリにレプリケートされるため、マイクロソフトマネージドフェールオーバーポリシーを使用してグループを強制フェールオーバーすると、データが失われる可能性があります。アプリケーションのデータ損失の許容範囲が反映されるように、フェールオーバーポリシーをカスタマイズできます。 GracePeriodWithDataLossHours を構成することで、データ損失につながる可能性がある強制フェールオーバーの開始までに Azure SQLサービスが待機する時間を制御できます。

DNS ゾーン

新しい SQL Managed Instance の作成時に自動的に生成される一意の ID。このインスタンスのマルチドメイン (SAN) は、同じ DNS ゾーンのインスタンスに対するクライアント接続を認証する目的でプロビジョニングされます。同じフェールオーバーグループ内の 2 つの SQL マネージドインスタンスは、DNS ゾーンを共有する必要があります。
フェールオーバーグループの読み取り/書き込みリスナー

現在のプライマリをポイントする DNS CNAME レコード。フェールオーバーグループが作成されるときに自動的に作成され、フェールオーバー後にプライマリが変更された場合に、読み取り/書き込みワークロードがプライマリに透過的に再接続できるようにします。 SQL マネージドインスタンスでフェールオーバーグループが作成されると、リスナー URL の DNS CNAME レコードは <fog-name>.<zone_id>.database.windows.net形式になります。
フェールオーバーグループの読み取り専用リスナー

現在のセカンダリをポイントする DNS CNAME レコード。フェールオーバーグループが作成されるときに自動的に作成され、フェールオーバー後にセカンダリが変更された場合に、読み取り専用 SQL ワークロードがセカンダリに透過的に接続できるようにします。 SQL マネージドインスタンスでフェールオーバーグループが作成されると、リスナー URL の DNS CNAME レコードは <fog-name>.secondary.<zone_id>.database.windows.net形式になります。既定では、読み取り専用リスナーのフェールオーバーは無効になります。これにより、セカンダリがオフラインのときにプライマリのパフォーマンスに影響が及ばないようにします。ただし、セカンダリが回復するまで、読み取り専用セッションは接続できません。読み取り専用セッションのダウンタイムを許容できず、プライマリのパフォーマンスが下がる可能性があっても、読み取り専用と読み取り/書き込みの両方のトラフィックにプライマリを使用してもよければ、AllowReadOnlyFailoverToPrimary プロパティを構成することによって、読み取り専用リスナーのフェールオーバーを有効にできます。その場合、セカンダリが利用できないと、読み取り専用トラフィックがプライマリに自動的にリダイレクトされます。

注

AllowReadOnlyFailoverToPrimary プロパティは、マイクロソフトマネージドフェールオーバーポリシーが有効になっていて、強制フェールオーバーがトリガーされる場合にのみ有効です。その場合、プロパティが True に設定されている場合、新しいプライマリは読み取り/書き込みセッションと読み取り専用セッションの両方を提供します。

フェールオーバーグループのアーキテクチャ

フェールオーバーグループは、プライマリインスタンスで構成し、別の Azure リージョンのセカンダリインスタンスに接続する必要があります。プライマリインスタンス上のすべてのユーザーデータベースがセカンダリインスタンスにレプリケートされます。 masterやmsdbなどのシステムデータベースはレプリケートされません。

次の図は、SQL マネージドインスタンスとフェールオーバーグループを使用した geo 冗長クラウドアプリケーションの一般的な構成を示しています。

Azure SQL Managed Instance のフェールオーバーグループのダイアグラム

アプリケーションでデータ層として SQL Managed Instance を使用する場合は、ビジネス継続性を考慮して設計する際にこれらの一般的なガイドラインとベストプラクティスに従ってください。

geo セカンダリインスタンスを作成する

フェールオーバー後にプライマリ SQL Managed Instance への接続が中断されないようにするには、プライマリインスタンスとセカンダリインスタンスの両方が同じ DNS ゾーン内にある必要があります。同じマルチドメイン (SAN) 証明書を使用して、フェールオーバーグループ内の 2 つのインスタンスのいずれかへのクライアント接続を認証できます。アプリケーションを運用環境にデプロイする準備ができたら、別のリージョンでセカンダリ SQL Managed Instance を作成し、プライマリ SQL Managed Instance と DNS ゾーンを共有していることを確認します。これを行うには、インスタンスの作成時に省略可能なパラメーターを指定します。 PowerShell または REST API を使用している場合、省略可能なパラメーターの名前は DNSZonePartner です。テーブル内の対応する省略可能なフィールドのAzure portalは 、Primary Managed Instance です。

重要

サブネットに作成された最初の SQL マネージドインスタンスによって、同じサブネット内の後続のすべてのインスタンスの DNS ゾーンが決定されます。つまり、同じサブネットの 2 つのインスタンスが異なる DNS ゾーンに属することはできません。

プライマリインスタンスと同じ DNS ゾーンでのセカンダリ SQL Managed Instance の作成の詳細については、「Azure SQL Managed Instance のフェールオーバーグループを構成する」を参照してください。

ペアリージョンを使用する

パフォーマンス上の理由から、ペアになっているリージョンに両方の SQL マネージドインスタンスをデプロイします。 SQLManaged Instanceリージョン内のフェールオーバーグループのパフォーマンスは、ペア設定されていないリージョンと比較して優れたものになります。

Azure SQL Managed Instance は、一般に Azure ペアリージョンが同時にデプロイされない安全なデプロイプラクティスに従います。ただし、どのリージョンが最初にアップグレードされるかを予測することはできないため、デプロイの順序は保証されません。プライマリインスタンスが最初にアップグレードされ、セカンダリインスタンスが最初にアップグレードされる場合があります。

Azure SQL Managed Instance がフェールオーバーグループの一部であり、グループ内のインスタンスが Azure のペアになっているリージョン内にない場合は、プライマリデータベースとセカンダリデータベースに対して異なるメンテナンス期間スケジュールを選択します。たとえば、geo セカンダリデータベースのメンテナンス期間には [平日] を選択し、geo プライマリデータベースのメンテナンス期間には [週末] を選択します。

インスタンス間の geo レプリケーショントラフィックフローを有効にして最適化する

geo レプリケーショントラフィックフローを中断せずに行うには、プライマリインスタンスとセカンダリインスタンスをホストする仮想ネットワークサブネット間の接続を確立し、維持する必要があります。ネットワークトポロジとポリシーに基づいて選択できるインスタンス間の接続を提供するには、複数の方法があります。

その場合、グローバル仮想ネットワークピアリング (VNet ピアリング) が、フェールオーバーグループ内の 2 つのインスタンス間の接続を確立する方法として推奨されます。これにより、Microsoft バックボーンインフラストラクチャを使用して、ピアリングされた仮想ネットワーク間に低遅延で高帯域幅のプライベート接続が提供されます。ピアリングされた仮想ネットワーク間の通信では、パブリックインターネット、ゲートウェイ、追加の暗号化が必要ありません。

初期シード処理

SQL マネージドインスタンス間でフェールオーバーグループを確立する場合、データレプリケーションが開始される前に、最初のシード処理フェーズがあります。初期シード処理フェーズは、最も時間がかかり、最も負荷の高い操作です。初期シード処理が完了すると、データが同期され、後続のデータ変更のみがレプリケートされます。初期シード処理が完了するまでにかかる時間は、データのサイズ、レプリケートされたデータベースの数、プライマリデータベースでのワークロードの強度、プライマリインスタンスとセカンダリインスタンスをホストする仮想ネットワーク間のリンクの速度によって異なります。これは主に接続の確立方法によって異なります。通常の状況では、推奨されるグローバル仮想ネットワークピアリングを使用して接続が確立されると、SQL Managed Instance のシード処理速度は 1 時間に最大 360 GB になります。シード処理は、ユーザーデータベースのバッチに対して並列で実行されますが、すべてのデータベースで同時に実行されるわけではありません。インスタンスで多数のデータベースがホストされている場合は、複数のバッチが必要になる場合があります。

2 つのインスタンス間のリンクの速度が必要な速度よりも遅い場合は、シードする時間が大きな影響を受けそうになります。指定されたシード処理速度、データベースの数、データの合計サイズ、リンク速度を使用して、データレプリケーションの開始前に最初のシード処理フェーズにかかる時間を見積もることができます。たとえば、100 GB のデータベースが 1 つの場合、リンクで 1 時間あたり 84 GB をプッシュでき、他のデータベースにシードしていないのであれば、初期シード処理フェーズにかかる時間は約 1.2 時間になります。リンクが転送できるのが 1 時間あたり 10 GB のみの場合、100 GB のデータベースのシード処理には約 10 時間かかります。レプリケートするデータベースが複数ある場合は、シード処理が並列で実行されます。低速リンク速度と組み合わせると、最初のシード処理フェーズは、特にすべてのデータベースからのデータの並列シード処理が使用可能なリンク帯域幅を超える場合に、かなり長い時間がかかる場合があります。

重要

初期シード処理フェーズは、非常に低速または混雑したリンクでは数日かかる場合があります。この場合、フェールオーバーグループを作成するとタイムアウトする可能性があります。フェールオーバーグループの作成は、6 日後に自動的に取り消されます。

geo セカンダリインスタンスへの geo フェールオーバーを管理する

フェールオーバーグループは、プライマリ SQL マネージドインスタンス上のすべてのデータベースの geo フェールオーバーを管理します。グループが作成されると、インスタンス上の各データベースがジオセカンダリインスタンスに自動的にジオレプリケートされます。フェールオーバーグループを使用して、データベースのサブセットの部分的なフェールオーバーを開始することはできません。

重要

プライマリ SQL マネージドインスタンスでデータベースが削除された場合は、geo セカンダリ SQL マネージドインスタンスでも自動的に削除されます。

読み取り/書き込みリスナーを使用する (プライマリ MI)

読み取り/書き込みワークロードの場合は、サーバー名として <fog-name>.zone_id.database.windows.net を使用します。接続は自動的にプライマリに向けられる。この名前はフェールオーバー後に変更されません。 geo フェールオーバーには DNS レコードの更新が含まれるため、新しいクライアント接続は、クライアント DNS キャッシュが更新された後にのみ新しいプライマリにルーティングされます。セカンダリインスタンスは DNS ゾーンをプライマリと共有するために、クライアントアプリケーションは同じサーバー側 SAN 証明書を使用してそのゾーンに再接続できます。既存のクライアント接続を終了してから再作成して、新しいプライマリにルーティングする必要があります。読み取り/書き込みリスナーと読み取り専用リスナーは、 SQL マネージドインスタンスのパブリックエンドポイントを介して到達できません。

読み取りリスナーを使用する (セカンダリ MI)

データ待機時間に耐える読み取り専用ワークロードを論理的に分離している場合は、geo セカンダリで実行できます。 geo セカンダリに直接接続するには、サーバー名として <fog-name>.secondary.<zone_id>.database.windows.net を使用します。

Business Critical レベルの SQL Managed Instance では、接続文字列のパラメーターを使用して、ApplicationIntent=ReadOnlyを使用した読み取り専用クエリワークロードのオフロードがサポートされています。 Geo レプリケートされたセカンダリを構成した場合は、この機能を使用して、プライマリロケーション、または geo レプリケートされた場所の読み取り専用レプリカに接続できます。

プライマリロケーションの読み取り専用レプリカに接続するには、ApplicationIntent=ReadOnly と <fog-name>.<zone_id>.database.windows.net を使用します。
セカンダリロケーションの読み取り専用レプリカに接続するには、ApplicationIntent=ReadOnly と <fog-name>.secondary.<zone_id>.database.windows.net を使用します。

読み取り/書き込みリスナーと読み取り専用リスナーは、 SQL マネージドインスタンスのパブリックエンドポイントを介して到達できません。

フェールオーバー後のパフォーマンス低下の可能性

一般的な Azure アプリケーションでは、複数の Azure サービスを使用し、複数のコンポーネントで構成されます。グループの geo フェールオーバーは、Azure SQL コンポーネントだけの状態に基づいてトリガーされます。障害がプライマリリージョン内の他の Azure サービスに影響を与えない可能性があり、そのコンポーネントはそのリージョンで引き続き使用できる可能性があります。プライマリデータベースがセカンダリリージョンに切り替えられると、依存コンポーネント間の待機時間が長くなる場合があります。セカンダリリージョン内のすべてのアプリケーションのコンポーネントの冗長性を確保し、アプリケーションコンポーネントをデータベースと共にフェールオーバーして、リージョン間の待機時間が長いほどアプリケーションのパフォーマンスに影響を与えないようにします。

強制フェールオーバー後のデータ損失の可能性

プライマリリージョンで障害が発生した場合、最近のトランザクションが geo セカンダリにレプリケートされていない可能性があり、強制フェールオーバーが実行されるとデータが失われる可能性があります。

DNS の更新

読み取り/書き込みリスナーの DNS の更新は、フェールオーバーが開始された後すぐに行われます。この操作によるデータの損失はありません。ただし、通常の条件下では、データベースロールを切り替えるプロセスには最大 5 分かかることがあります。これが完了するまで、新しいプライマリインスタンスの一部のデータベースは引き続き読み取り専用となります。 PowerShell を使用してフェールオーバーが開始された場合、プライマリレプリカロールを切り替える操作は同時に発生します。 Azure portal を使用して開始された場合、UI で完了状態が示されます。 REST API を使用して開始された場合は、標準的な Azure Resource Manager のポーリングメカニズムを使用して、完了を監視します。

重要

geo フェールオーバーの原因となる停止が軽減された後は、手動計画フェールオーバーを使用してプライマリを元の場所に戻します。

ライセンスフリーの DR レプリカでコストを節約する

セカンダリ SQL マネージドインスタンスをディザスターリカバリー (DR) にのみ使用するように構成することで、SQL Server ライセンスコストを節約できます。これをセットアップするには、「Azure SQL Managed Instance のライセンスフリースタンバイレプリカを構成する」を参照してください。

セカンダリインスタンスが読み取りワークロードに使われていない限り、Microsoft はプライマリインスタンスと一致する数の無料仮想コアを提供します。その場合でも、セカンダリインスタンスで使われるコンピューティングとストレージについては課金されます。フェールオーバーグループは 1 つのレプリカのみをサポートし、レプリカは読み取り可能レプリカであるか、DR 専用レプリカとして指定されている必要があります。

システムデータベースのオブジェクトに依存するシナリオを実現させる

システムデータベースは、フェールオーバーグループのセカンダリインスタンスにはレプリケートされません。システムデータベースのオブジェクトに依存するシナリオを有効にするには、セカンダリインスタンスに同じオブジェクトを作成してください。プライマリインスタンスとの同期を維持します。

たとえば、セカンダリインスタンスで同じログインを使用する場合は、必ず同じ SIDで作成してください。

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

詳細については、「ログインとエージェントジョブのレプリケーション」を参照してください。

インスタンスのプロパティと保持ポリシーのインスタンスを同期する

フェールオーバーグループ内のインスタンスは Azure リソースとは別の状態のままであり、プライマリインスタンスの構成に加えられた変更はセカンダリインスタンスに自動的にレプリケートされません。プライマリインスタンスとセカンダリインスタンスの両方で、関連するすべての変更を必ず実行してください。たとえば、プライマリインスタンスでバックアップストレージの冗長性や長期的なバックアップ保持ポリシーを変更する場合は、セカンダリインスタンスでも変更してください。

インスタンスのスケーリング

プライマリインスタンスとセカンダリインスタンスの構成は同じである必要があります。これには、コンピューティングサイズ、ストレージサイズ、サービスレベルが含まれます。フェールオーバーグループの構成を変更する必要がある場合は、それに応じて各インスタンスを同じ構成にスケーリングすることで変更できます。詳細については、フェールオーバーグループ内のインスタンスのスケーリングに関するページを参照してください。

重要なデータが失われないようにする

ワイドエリアネットワークの待機時間が長いため、geo レプリケーションは非同期レプリケーションメカニズムを使用します。非同期レプリケーションを使用すると、プライマリに障害が発生した場合にデータ損失が回避される可能性があります。データを保護する方法については、「データ損失の防止」を参照してください。

フェールオーバーグループの状態

フェールオーバーグループは、データレプリケーションの現在の状態を説明する状態を報告します。

シード処理: 最初のシード処理は、すべてのユーザーデータベースがセカンダリインスタンスで初期化されるまで、フェールオーバーグループの作成後に行われます。ユーザーデータベースがまだセカンダリインスタンスにコピーされていないため、フェールオーバーグループが シード 状態の間はフェールオーバーを開始できません。
同期中: フェールオーバーグループの通常の状態。つまり、プライマリインスタンスでのデータ変更が、セカンダリインスタンスに非同期的にレプリケートされます。この状態では、データがすべての時点で完全に同期される保証はありません。フェールオーバーグループ内のインスタンス間のレプリケーションプロセスの非同期的な性質により、プライマリからセカンダリにレプリケートされるデータが変更される可能性があります。フェールオーバーグループが同期状態にある間は、自動フェールオーバーと手動フェールオーバーの両方を開始できます。
フェールオーバーの進行中: この状態は、自動または手動で開始されたフェールオーバーが進行中であることを示します。フェールオーバーグループがこの状態の間は、フェールオーバーグループに対する変更や追加のフェールオーバーを開始できません。

フェールバック

Microsoft が管理するフェールオーバーポリシーを使用してフェールオーバーグループを構成すると、定義された猶予期間に従って、障害シナリオ中に geo セカンダリサーバーへの強制フェールオーバーが開始されます。古いプライマリへのフェールバックは、手動で開始する必要があります。

機能の相互運用性

バックアップ

完全バックアップは、次のシナリオで作成されます。

初期シード処理が開始される前 (フェールオーバーグループを作成するとき)。
フェールオーバーの後。

完全バックアップは、スキップまたは遅延できないデータ操作のサイズであり、完了するまでに時間がかかる場合があります。完了に要する時間は、データのサイズ、データベースの数、プライマリデータベースのワークロードの強度によって異なります。完全バックアップにより、初期シード処理が大幅に遅れる可能性があり、フェールオーバー直後の新しいインスタンスでのフェールオーバー操作が遅延または妨げられる可能性があります。

以下、具体例に沿って説明します。

フェールオーバーグループのセカンダリインスタンスでホストされているデータベースは、フェールオーバー後、またはフェールオーバーグループが削除されるまで、そのインスタンスがプライマリになるまでバックアップされません。
フェールオーバー後にデータベースがプライマリロールに変更された後、またはフェールオーバーグループが削除された後にスタンドアロンになった後、ポイントインタイムリストアを容易にするためにデータベースの完全バックアップが自動的に開始されます。
そのインスタンスがフェールオーバーグループ内のセカンダリレプリカであった時点まで、データベースをインスタンスから復元することはできません。特定の時点に復元するには、その時点でプライマリであったインスタンスからデータベースを復元する必要があります。
同じ SQL マネージドインスタンスのペアで削除されたフェールオーバーグループを再作成するには、フェールオーバーグループが削除された後、すべてのユーザーデータベースを目的のセカンダリから削除する必要があります。データベースは、保留中のすべてのバックアップ操作が完了した後にのみ完全に削除されます。これには、完全バックアップ (データのサイズ操作) が実行されなかった場合も含まれます。データベースが非常に大きいフェールオーバーグループを削除した後、セカンダリインスタンスをクリーンアップする時間を許可します。各データベースでは、保留中の完全バックアップ操作が進行中である可能性があります。

完全バックアップは、スキップまたは遅延できないデータ操作のサイズであり、完了するまでに時間がかかる場合があります。完了に要する時間は、データのサイズ、データベースの数、プライマリデータベースのワークロードの強度によって異なります。完全バックアップでは初期シード処理が著しく遅れる可能性があり、フェールオーバーの直後に新しいインスタンスでフェールオーバー操作を遅延または回避できます。

ログ再生サービス

ログ再生サービス (LRS) を使用して Azure SQL Managed Instance に移行されたデータベースは、一括移行ステップが実行されるまでフェールオーバーグループに追加できません。 LRS で移行されたデータベースは、一括移行まで復元状態になり、復元状態のデータベースをフェールオーバーグループに追加することはできません。復元状態のデータベースでフェールオーバーグループを作成しようとすると、データベースの復元が完了するまでフェールオーバーグループの作成が遅れます。

トランザクションレプリケーション

フェールオーバーグループ内のインスタンスでのトランザクションレプリケーションの使用はサポートされています。ただし、SQL マネージドインスタンスをフェールオーバーグループに追加する前にレプリケーションを構成した場合、フェールオーバーグループの作成を開始するとレプリケーションが一時停止します。レプリケーションモニターには、 Replicated transactions are waiting for the next log backup or for mirroring partner to catch upの状態が表示されます。レプリケーションは、フェールオーバーグループが正常に作成されると、再開されます。

パブリッシャーまたはディストリビューター SQL マネージドインスタンスがフェールオーバーグループに存在する場合、フェールオーバーが発生した後に、SQL マネージドインスタンス管理者が、古いプライマリ上のすべてのパブリケーションをクリーンアップして、新しいプライマリ上でそれらを再構成する必要があります。このシナリオで必要なアクティビティの手順については、「トランザクションレプリケーションガイド」を確認してください。

アクセス許可と制限

フェールオーバーグループを構成する前に、アクセス許可と制限事項の一覧を確認してください。

フェールオーバーグループをプログラムで管理する

フェールオーバーグループは、Azure PowerShell、Azure CLI、および REST API を使用してプログラムで管理することもできます。詳細については、「フェールオーバーグループの構成」を参照してください。

ディザスターリカバリーの訓練

DR ドリルを実行するには、テストフェールオーバーのチュートリアルに従って手動計画フェールオーバーの使用をお勧めします。

この操作ではデータ損失に対するガードレールが提供されないため、強制フェールオーバーを使用してドリルを実行 することはお勧めしません。ただし、強制フェイルオーバー前に以下の条件を満たすことで、データ損失のない強制フェイルオーバーが可能になります。

ワークロードは、プライマリ SQL マネージドインスタンスで停止されます。
実行時間の長いトランザクションがすべて完了した。
プライマリ SQL マネージドインスタンスへのすべてのクライアント接続が切断されました。
フェールオーバーグループの状態が "同期中"である。

2 つの SQL マネージドインスタンスでロールが切り替っていることを確認してください。また、必要に応じて新しいプライマリ SQL マネージドインスタンスへの接続を確立し、読み取り/書き込みワークロードを開始する前に、フェールオーバーグループの状態が "フェールオーバーの進行中" から "同期中" に切り替わりました。

元の SQL マネージドインスタンスロールに対してデータ損失のないフェールバックを実行するには、強制フェールオーバーではなく手動の計画フェールオーバーを使用 することを強くお勧めします。強制フェールバックを使用する場合:

データロスレスフェイルオーバーと同じ手順に従います。
最初の強制フェールオーバーが完了した 直後に 強制フェールバックが実行された場合、以前のプライマリ SQL マネージドインスタンスで未処理の自動バックアップ操作が完了するのを待機する必要があるため、フェールバックの実行時間が長くなることが予想されます。
プライマリロールからセカンダリロールに移行するインスタンスに対する未処理の自動バックアップ操作は、このインスタンスでのデータベースの可用性に影響を与える可能性があります。
フェールオーバーグループの状態を使用して、両方のインスタンスがロールを正常に変更し、クライアント接続を受け入れる準備ができているかどうかを確認してください。

フィードバック

このページはお役に立ちましたか?