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

Applies to:Azure SQL Database

フェールオーバー グループ機能を使うと、論理サーバー上の一部または全てのデータベースの、別のリージョンの論理サーバーへのレプリケーションやフェールオーバーを管理できます。 この記事では、フェールオーバー グループ機能の概要と、Azure SQL Databaseで使用するためのベスト プラクティスと推奨事項について説明します。

この機能の使用を開始するには、 Azure SQL Databaseを確認します。

Azure SQL Database のディザスター リカバリーについて詳しく知るには、こちらのビデオをご覧ください。

概要

フェールオーバー グループ機能を使用すると、別のAzure リージョンへのデータベースのレプリケーションとフェールオーバーを管理できます。 論理サーバ内のユーザデータベースのすべて、またはサブセットを別の論理サーバにレプリケー トするように選択できます。 これは、アクティブ geo レプリケーション機能に基づく宣言型の抽象化であり、geo レプリケーション対応データベースの大規模なデプロイと管理を簡素化するように設計されています。

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 などのコマンド ライン ツールを使用する場合、Microsoft マネージドのフェールオーバー ポリシー値は automatic です。

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

お客様による管理

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

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

Microsoft マネージド

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

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

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

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

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

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

用語と機能

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

  フェールオーバー グループは、Azurelogical サーバーによって管理されるデータベースの名前付きグループです>プライマリ リージョンで障害が発生したために、すべてのプライマリ データベースまたは一部のプライマリ データベースが使用できなくなった場合に、別のAzure リージョンにユニットとしてフェールオーバーできます。

  重要

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

• サーバー

  論理サーバー上のユーザー データベースの一部またはすべてをフェールオーバー グループに配置できます。 また、サーバーでは、単一サーバー上の複数のフェールオーバー グループがサポートされます。

• プライマリ

  フェールオーバー グループのプライマリ データベースのホストとなる論理サーバー。

• セカンダリ

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

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

  フェールオーバーでは、セカンダリがプライマリ ロールに切り替わる前に、プライマリ データベースとセカンダリ データベース間の完全なデータ同期が行われます。 これにより、データ損失が発生しないことが保証されます。 フェールオーバーは、プライマリにアクセスできる場合にのみ可能です。 フェールオーバーは、次のシナリオで使用されます。

  • データ損失が許容されない場合は、運用環境でディザスター リカバリー (DR) ドリルを行います
  • ワークロードを別のリージョンに再配置します
  • 機能停止が軽減 (フェールバック) された後、ワークロードをプライマリ リージョンに返します

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

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

• データ消失の猶予期間

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

• フェールオーバー グループへの単一データベースの追加

  同じ論理サーバー上の複数の単一データベースを、同じフェールオーバー グループに配置できます。 フェールオーバー グループに単一データベースを追加すると、フェールオーバー グループの作成時に指定したセカンダリ サーバー上に、同じエディションとコンピューティング サイズを使用するセカンダリ データベースが自動的に作成されます。 セカンダリ サーバーにセカンダリ データベースが既に存在するデータベースを追加する場合、その geo レプリケーション リンクがグループに継承されます。 フェールオーバー グループの一部でないサーバーにセカンダリ データベースが既に存在するデータベースを追加すると、セカンダリ サーバーに新しいセカンダリデータベースが作成されます。

  重要

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

• エラスティック プール内のデータベースをフェールオーバー グループに追加する

  1 つのエラスティック プール内のすべてまたは複数のデータベースを同じフェールオーバー グループに置くことができます。 プライマリ データベースがエラスティック プール内にある場合、セカンダリは同じ名前のエラスティック プール (セカンダリ プール) に自動的に作成されます。 セカンダリ サーバーに全く同じ名前のエラスティック プールが含まれており、フェールオーバー グループによって作成されるセカンダリ データベースをホストするのに十分な空き容量があることを確認する必要があります。 セカンダリ プールにセカンダリ データベースが既に存在するプールにデータベースを追加する場合、その geo レプリケーション リンクがグループに継承されます。 フェールオーバー グループの一部でないサーバーにセカンダリ データベースが既に存在するデータベースを追加すると、セカンダリ プールに新しいセカンダリデータベースが作成されます。

• フェールオーバー グループの読み取り/書き込みリスナー

  現在のプライマリをポイントする DNS CNAME レコード。 フェールオーバー グループが作成されるときに自動的に作成され、フェールオーバー後にプライマリが変更された場合に、読み取り/書き込みワークロードがプライマリに透過的に再接続できるようにします。 サーバーでフェールオーバー グループが作成されたときに、リスナー URL の DNS CNAME レコードの形式は になります。 フェールオーバー後、DNS レコードが自動的に更新され、リスナーが新しいプライマリにリダイレクトされます。

• フェールオーバー グループの読み取り専用リスナー

  現在のセカンダリを指す DNS CNAME レコード。 フェールオーバー グループが作成されるときに自動的に作成され、フェールオーバー後にセカンダリが変更された場合に、読み取り専用 SQL ワークロードがセカンダリに透過的に接続できるようにします。 サーバーでフェールオーバー グループが作成されたときに、リスナー URL の DNS CNAME レコードの形式は になります。 既定では、読み取り専用リスナーのフェールオーバーは無効になります。これにより、セカンダリがオフラインのときにプライマリのパフォーマンスに影響が及ばないようにします。 ただし、セカンダリが回復するまで、読み取り専用セッションは接続できません。

• 複数のフェールオーバー グループ

  同じサーバーのペアに対して複数のフェールオーバー グループを構成して、geo フェールオーバーのスコープを制御できます。 各グループは独立してフェールオーバーします。 データベースごとのテナント アプリケーションが複数のリージョンにデプロイされ、エラスティック プールを使用している場合は、この機能を使用して、各プール内のプライマリ データベースとセカンダリ データベースを混在できます。 これにより、一部のテナント データベースに対する停止の影響を軽減できる場合があります。

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

Azure SQL Databaseのフェールオーバー グループには、通常は同じアプリケーションで使用される 1 つまたは複数のデータベースを含めることができます。 フェールオーバー グループは、別のAzure リージョンのセカンダリ サーバーに接続するプライマリ サーバーで構成する必要があります。 フェールオーバー グループには、プライマリ サーバーのすべてのデータベースまたは一部のデータベースを含めることができます。 次の図は、フェールオーバー グループで複数のデータベースを使用する、地理冗長クラウド アプリケーションの典型的な構成を示したものです：

図には、複数のデータベースとフェールオーバー グループを使用する Geo 冗長クラウド アプリケーションの一般的な構成が示されています。

ビジネス継続性を念頭に置いてサービスを設計する場合は、この記事で説明されている一般的なガイドラインとベスト プラクティスに従ってください。 フェールオーバー グループを構成する場合は、geo フェールオーバー後に geo セカンダリが新しいプライマリになったときに、セカンダリの認証とネットワーク アクセスが正しく機能するように設定されていることを確認します。 詳細については、「ジオリストアまたはフェールオーバーの Azure SQL Database セキュリティの構成と管理を参照してください。 詳細については、「 Azure SQL Database と Geo-restore for Azure SQL Database を使用したグローバルに使用可能なサービスの設計」を参照してください。

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

プライマリ サーバーとセカンダリ サーバーの間でフェールオーバー グループを作成する場合は、ペアになっているリージョンのフェールオーバー グループの方が、ペアになっていないリージョンと比較してパフォーマンスが向上するため、ペアになっているリージョンを使用します。　　

安全な展開方法に従って、Azure SQL Databaseは一般に、ペアになっているリージョンを同時に更新しません。 ただし、最初にアップグレードされるリージョンを予測することはできないため、デプロイの順序は保証されません。 プライマリ サーバーが最初にアップグレードされ、2 番目にアップグレードされる場合があります。

geo-replication または failover groups が、Azure リージョンのペアリングに合わないデータベース用に構成されている場合は、プライマリ データベースとセカンダリ データベースに対して異なるメンテナンス期間スケジュールを使用します。 たとえば、geo セカンダリ データベースのメンテナンス期間には [平日] を選択し、geo プライマリ データベースのメンテナンス期間には [週末] を選択できます。

初期シード処理

データベースまたはエラスティック プールをフェールオーバー グループに追加する場合、データ レプリケーションが開始される前に、初期シード処理フェーズがあります。 初期シード処理フェーズは、最も時間がかかり、最も負荷の高い操作です。 初期シード処理が完了すると、データは同期され、その後はそれ以降のデータ変更のみがレプリケートされます。 初期シード処理が完了するまでにかかる時間は、データのサイズ、レプリケートされたデータベースの数、プライマリ データベースにかかる負荷、プライマリとセカンダリデータベース間のリンクの速度によって異なります。 通常の環境において可能なシード処理の速度は、SQL Database では最大 500 GB/時になります。 シード処理は、すべてのデータベースに対して並列で実行されます。

フェールオーバー グループ内のすべてのデータベースの数

フェールオーバー グループ内のデータベースの数は、フェールオーバー操作と強制フェールオーバー操作の両方の時間に直接影響します。

• フェールオーバー中 (計画フェールオーバーとも呼ばれます) は、すべてのプライマリ データベースがセカンダリと完全に同期され、準備完了状態になります。 コントロール プレーンが過負荷にならないように、データベースはバッチで準備されます。 このため、フェールオーバー グループ内のデータベースの数を制限することを強くお勧めします。
• 強制フェールオーバーの場合、データ同期が開始されないため、準備フェーズが迅速化されます。 フェールオーバー時間を短縮し、予測可能にするには、フェールオーバー グループ内のデータベースを少ない数に抑えることが有用です。

複数のフェールオーバー グループを使用して、複数のデータベースをフェールオーバーする

1 つまたは複数のフェールオーバー グループを異なるリージョンの 2 つのサーバー (プライマリおよびセカンダリ サーバー) 間に作成できます。 各グループには、プライマリ リージョンに発生した機能停止によりすべてまたは一部のプライマリ データベースが使用できなくなった際にユニットとして復元できる、1 つまたは複数のデータベースを含めることができます。 フェールオーバー グループを作成すると、プライマリと同じサービス目標を持つ geo セカンダリ データベースが作成されます。 既存の geo レプリケーション関係をフェールオーバー グループに追加する場合は、geo セカンダリがプライマリと同じサービス レベルとコンピューティング サイズで構成されていることを確認します。

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

読み取り/書き込みワークロードの場合は、接続文字列のサーバー名として <fog-name>.database.windows.net を使用します。 接続は自動的にプライマリに向けられる。 この名前はフェールオーバー後に変更されません。 フェールオーバーでは DNS レコードの更新が行われるため、クライアントの接続は、クライアント DNS キャッシュが最新の情報に更新された後にのみ新しいプライマリにリダイレクトされます。 プライマリおよびセカンダリ リスナーの DNS レコードの有効期限 (TTL) は 30 秒です。

読み取り専用リスナー（セカンダリ）を使用する

データ待機時間に耐える読み取り専用ワークロードを論理的に分離している場合は、geo セカンダリで実行できます。 読み取り専用セッションの場合は、接続文字列のサーバー名として <fog-name>.secondary.database.windows.net を使用します。 接続は自動的にジオセカンダリに向けられる。 ApplicationIntent=ReadOnlyを使用して、接続文字列で読み取り意図を示すこともできます。

Premium、Business Critical、Hyperscale サービス レベルでは、SQL Database では、接続文字列の パラメーターを使用して、ApplicationIntent=ReadOnly を使用して読み取り専用クエリ ワークロードをオフロードできます。 地理的セカンダリを構成した場合、この機能を使用してプライマリまたは地理的セカンダリの場所にある読み取り専用レプリカに接続できます。

セカンダリ ロケーションの読み取り専用レプリカに接続するには、 と を使用します。

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

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

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

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

フェールバック

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

複数のセカンダリ

各フェールオーバー グループは、同じリージョンまたは異なるリージョン内の複数のセカンダリ サーバーをサポートできます。 この構成では、ディザスター リカバリーの追加オプションが提供され、読み取り専用ワークロードを複数のリージョンに分散できます。 複数のセカンダリを構成する場合は、次の点を考慮してください。

• フェールオーバー グループごとに最大 4 つのセカンダリ サーバーを指定できます。
• 各セカンダリ サーバーは、プライマリ サーバーと互いに同じリージョンまたは異なるリージョンに配置できます。
• 各セカンダリ サーバーは、プライマリ サーバーとの独自の geo レプリケーション リンクを保持します。
• フェールオーバーは、任意のセカンダリ サーバーに対して開始できます。
• 読み取り専用のワークロードを適切に処理するには、読み取り専用リスナーをセカンダリ サーバーの 1 つだけに構成でき、別のリージョンのセカンダリに対する必要があります。
• この構成では、チェーニング（ジオレプリカのジオレプリカの作成）はサポートされていません。

アクセス許可と制限

アクセス許可と制限事項の一覧については、フェールオーバー グループの構成ガイドを参照してください。

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

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

高可用性 (ゾーン冗長) を有効にする

冗長性 を通じての可用性 は、リージョン内の可用性ゾーンの停止から保護することで、回復性がさらに向上します。

1 つ以上のデータベースを含むフェールオーバー グループを作成する場合、プライマリ データベースの高可用性設定に関係なく、セカンダリ データベースの高可用性を有効にするオプションはありません。

Hyperscale 以外のデータベースを使用したゾーン冗長

フェールオーバー グループを使用して作成されたセカンダリ データベースは、既定では高可用性が有効になりません。 フェールオーバー グループが作成されたら、グループに含まれるデータベースで高可用性を有効にします。 この動作は、最初にアクティブ geo レプリケーションを作成し、必要に応じてフェールオーバー グループにデータベースを追加する場合にも適用されます。

Hyperscale を使用したゾーン冗長

フェールオーバー グループを使用して作成されたセカンダリ データベースは、それぞれのプライマリ データベースの高可用性設定を継承します。 そのため、プライマリ データベースで高可用性が有効になっている場合、セカンダリ データベースでも有効になります。 逆に、プライマリ データベースで高可用性が有効になっていない場合、セカンダリ データベースでも有効になりません。

リージョンでの可用性ゾーンのサポート

プライマリ データベースで高可用性が有効になっており、追加されるセカンダリ データベースが、まだ可用性ゾーンをサポートしていないリージョン内にあるシナリオでは、ワークフローは、コード 45122 で失敗し、"フェールオーバー グループの作成または更新操作は正常に完了しましたが、一部のデータベースをフェールオーバー グループに追加、またはフェールオーバー グループから削除できませんでした。 ゾーン冗長データベースまたはプールのプロビジョニングは、現在の要求ではサポートされていません" というエラー メッセージが表示されます。この問題を回避するには、セカンダリ データベースの作成時に、高可用性を有効または無効にするアクティブ geo レプリケーションを使用します。 その後、必要に応じて、これらのデータベースをフェールオーバー グループに追加できます。

関連するコンテンツ

• サンプル スクリプトは、次をご覧ください：
  • PowerShell を使用して Azure SQL Database のアクティブ ジオレプリケーションを構成します
  • PowerShell を使用して、Azure SQL Database のプールされたデータベースに対してアクティブ geo レプリケーションを構成します
  • PowerShell を使用して、フェールオーバー グループにAzure SQL Databaseを追加します
• ビジネス継続性の概要およびシナリオについては、ビジネス継続性の概要を参照してください。
• 自動バックアップAzure SQL Databaseについては、「SQL Database 自動バックアップ」を参照してください。
• 自動バックアップを使用して復旧する方法については、 サービス主導のバックアップからのデータベース復元に関する記事を参照してください。
• 新しいプライマリ サーバーとデータベースの認証要件については、 障害復旧後の SQL Database のセキュリティに関する記事を参照してください。
• geo レプリケーションの問題のトラブルシューティングについては、「 geo レプリケーションの再実行ラグのトラブルシューティング」を参照してください。