自動フェールオーバー グループを使用して、複数のデータベースの透過的な調整されたフェールオーバーを有効にする

適用対象: Azure SQL Database Azure SQL Managed Instance

自動フェールオーバー グループ機能を使用すると、サーバー上のデータベースのグループ、またはマネージド インスタンス内のすべてのデータベースの別のリージョンへのレプリケーションやフェールオーバーを管理できます。 これは、既存のアクティブ geo レプリケーション機能に基づく宣言型の抽象化であり、geo レプリケーション対応データベースの大規模なデプロイと管理を簡素化するように設計されています。 フェールオーバーは、手動で開始することも、ユーザー定義ポリシーに基づいて Azure サービスに委任することもできます。 後者のオプションの場合、プライマリ リージョンで発生した致命的な障害やその他の計画外のイベントにより SQL Database や SQL Managed Instance の可用性がすべてまたは一部失われたときに、セカンダリ リージョンの複数の関連データベースを自動的に復元できます。 フェールオーバー グループには、通常同じアプリケーションによって使用される、1 つまたは複数のデータベースを含めることができます。 さらに、読み取り可能なセカンダリ データベースを使用して、読み取り専用クエリ ワークロードをオフロードできます。 自動フェールオーバー グループには複数のデータベースが関与するため、これらのデータベースをプライマリ サーバーに構成する必要があります。 自動フェールオーバー グループでは、グループ内のすべてのデータベースを、別のリージョンの 1 つのセカンダリ サーバーまたはインスタンスのみへのレプリケートがサポートされます。

注意

自動フェールオーバー グループは現在、Hyperscale サービス レベルではサポートされていません。 Hyperscale データベースの地理的フェールオーバーの場合は、アクティブ geo レプリケーションを使用してください。

注意

同じまたは異なるリージョンで複数の Azure SQL Database セカンダリが必要な場合は、アクティブ geo レプリケーションを使用してください。

自動フェールオーバー グループ ポリシーで自動フェールオーバー グループを使用しているときに、グループ内で 1 つ以上のデータベースに影響する機能停止が発生すると、自動フェールオーバーが行われます。 通常、これらは、組み込みの自動高可用性操作では自己軽減できないインシデントです。 フェールオーバー トリガーの例には、複数のコンピューティング ノードでの OS カーネル メモリ リークによる SQL Database テナント リングまたは制御リングのダウンが原因で発生するインシデントや、所定のハードウェアの使用停止中に間違ったネットワーク ケーブルが切断されたことによる 1 つまたは複数のテナント リングのダウンが原因で発生するインシデントがあります。 詳細については、SQL Database の高可用性に関する記事を参照してください。

さらに、自動フェールオーバー グループには、フェールオーバー中にそのまま残る読み取り/書き込みリスナー エンドポイントと読み取り専用リスナー エンドポイントが用意されています。 手動または自動フェールオーバーのどちらをアクティブ化するにしても、フェールオーバーはグループ内のすべてのデータベースをプライマリに切り替えます。 データベースのフェールオーバーが完了した後、DNS レコードが自動的に更新され、エンドポイントが新しいリージョンにリダイレクトされます。 特定の RPO および RTO データについては、ビジネス継続性の概要に関するページを参照してください。

自動フェールオーバー グループ ポリシーで自動フェールオーバー グループを使用しているときに、サーバーまたはマネージド インスタンスのデータベースに影響する機能停止が発生すると、自動フェールオーバーが行われます。 自動フェールオーバー グループは、以下を使用して管理できます。

フェールオーバー後は、データベースおよびサーバー、またはインスタンスの認証要件が確実に新しいプライマリで構成されるようにしてください。 詳細については、 障害復旧後の SQL Database のセキュリティに関するページを参照してください。

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

用語と機能

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

    フェールオーバー グループは、プライマリ リージョンでの機能停止により、すべてまたは一部のプライマリ データベースが使用できなくなった場合に、1 つの単位として別のリージョンにフェールオーバーできるマネージド インスタンス内の、または単一サーバーによって管理されるデータベースの名前付きグループです。 SQL Managed Instance に対して作成された場合、フェールオーバー グループには、そのインスタンス内のすべてのユーザー データベースが含まれています。そのため、インスタンス上に構成できるフェールオーバー グループは 1 つのみとなります。

    重要

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

  • サーバー

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

  • プライマリ

    フェールオーバー グループのプライマリ データベースをホストするサーバーまたはマネージド インスタンス。

  • セカンダリ

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

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

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

    重要

    既存のセカンダリ データベースである場合を除き、セカンダリ サーバーに同じ名前のデータベースがないことを確認してください。 SQL Managed Instance のフェールオーバー グループでは、すべてのユーザー データベースがレプリケートされます。 フェールオーバー グループで、レプリケーション対象としてユーザー データベースのサブセットを選択することはできません。

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

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

  • 初期シード処理

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

    SQL Managed Instance の場合は、初期シード処理フェーズの時間を見積もるときに、2 つのインスタンス間の Express Route リンクの速度を考慮してください。 2 つのインスタンス間のリンクの速度が、必要なものより遅い場合、シード処理の時間が特に影響を受ける可能性があります。 提示したシード処理速度、データベースの数、データの合計サイズ、およびリンク速度を使用して、データ レプリケーションが開始される前に初期シード処理フェーズにかかる時間を見積もることができます。 たとえば、100 GB のデータベースが 1 つの場合、リンクで 1 時間あたり 84 GB をプッシュでき、他のデータベースにシードしていないのであれば、初期シード処理フェーズにかかる時間は約 1.2 時間になります。 リンクが転送できるのが 1 時間あたり 10 GB のみの場合、100 GB のデータベースのシード処理には約 10 時間かかります。 レプリケートするデータベースが複数ある場合、シード処理は並列で実行されます。そして、低速リンク速度と組み合わせると、すべてのデータベースからのデータの並列シード処理が使用可能なリンク帯域幅を超えている場合は、初期シード処理の時間が大幅に長くなることがあります。 2 つのインスタンス間のネットワーク帯域幅が制限されていて、複数のマネージド インスタンスをフェールオーバー グループに追加する場合は、複数のマネージド インスタンスを 1 つずつ順番にフェールオーバー グループに追加することを検討してください。 2 つのマネージド インスタンスの間に適切なサイズのゲートウェイ SKU があり、企業ネットワークの帯域幅で許される場合は、最大 360 GB/時の速度を実現できます。

  • DNS ゾーン

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

    注意

    SQL Database に対して作成されたフェールオーバー グループには、DNS ゾーン ID は必要ありません。

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

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

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

    セカンダリの URL を指す読み取り専用リスナーを指す、形成された DNS CNAME レコード。 フェールオーバー グループの作成時に自動的に作成され、指定された負荷分散規則を使用して、読み取り専用 SQL ワークロードが透過的にセカンダリに接続できるようにします。 サーバーでフェールオーバー グループが作成されたときに、リスナー URL の DNS CNAME レコードの形式は <fog-name>.secondary.database.windows.net になります。 SQL Managed Instance でフェールオーバー グループが作成されたときに、リスナー URL の DNS CNAME レコードの形式は <fog-name>.secondary.<zone_id>.database.windows.net になります。

  • 自動フェールオーバー ポリシー

    既定では、フェールオーバー グループは自動フェールオーバー ポリシーを使用して構成されます。 システムはエラーが検出され、猶予期間が終了すると、フェールオーバーをトリガーします。 システムでは、影響の規模が原因で、組み込みの高可用性インフラストラクチャによって機能停止を軽減できないかどうかを確認する必要があります。 アプリケーションから、または手動でフェールオーバー ワークフローを制御するには、自動フェールオーバーをオフにします。

    注意

    障害の規模とその軽減にかかる時間の検証には、人間による操作が必要なため、猶予期間を 1 時間未満に設定することはできません。 この制約は、データの同期状態に関係なく、フェールオーバー グループ内のすべてのデータベースに適用されます。

  • 読み取り専用フェールオーバー ポリシー

    既定では、読み取り専用リスナーのフェールオーバーは無効になっています。 セカンダリがオフラインのとき、プライマリのパフォーマンスに影響が出ないようにします。 ただし、セカンダリが回復するまで、読み取り専用セッションは接続できません。 読み取り専用セッションのダウンタイムを許容できず、プライマリのパフォーマンスが下がる可能性があっても、読み取り専用と読み取り/書き込みの両方のトラフィックにプライマリを使用してもよければ、AllowReadOnlyFailoverToPrimary プロパティを構成することによって、読み取り専用リスナーのフェールオーバーを有効にできます。 その場合、セカンダリが利用できないと、読み取り専用トラフィックがプライマリに自動的にリダイレクトされます。

    注意

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

  • 計画されたフェールオーバー

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

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

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

  • 手動フェールオーバー

    自動フェールオーバー構成に関係なくいつでも手動でフェールオーバーを開始することができます。 プライマリに影響する障害が発生したときに、自動フェールオーバー ポリシーが構成されていない場合、セカンダリをプライマリ ロールに昇格させるために手動でのフェールオーバーが必要です。 強制的 (計画外) またはフレンドリ (計画された) フェールオーバーを開始できます。 フレンドリ フェールオーバーは、以前のプライマリにアクセスできる場合にのみ可能であり、データを失うことなくプライマリをセカンダリ リージョンに再配置するために使用できます。 フェールオーバーが完了すると、確実に新しいプライマリに接続されるように、DNS レコードが自動的に更新されます。

  • データ消失の猶予期間

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

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

    サーバーの同じペアに対して複数のフェールオーバー グループを構成して、フェールオーバーの範囲を制御できます。 各グループは独立してフェールオーバーします。 マルチテナント アプリケーションがエラスティック プールを使用する場合、この機能を使用して各プールのプライマリ データベースとセカンダリ プライマリを混在させることができます。 こうすることで、機能停止の影響をテナントの半分に抑えることができます。

    注意

    SQL Managed Instance では、複数のフェールオーバー グループはサポートされません。

アクセス許可

フェールオーバー グループに対するアクセス許可は、Azure ロールベースのアクセス制御 (Azure RBAC) によって管理されます。 SQL Server 共同作成者ロールには、フェールオーバー グループを管理するために必要なすべてのアクセス許可があります。

フェールオーバー グループの作成

フェールオーバー グループを作成するには、プライマリ サーバーとセカンダリ サーバーの両方、およびフェールオーバー グループ内のすべてのデータベースへの Azure RBAC 書き込みアクセス権が必要です。 SQL Managed Instance の場合、プライマリとセカンダリの両方の SQL Managed Instance への Azure RBAC 書き込みアクセス権が必要です。しかし、個々の SQL Managed Instance データベースをフェールオーバー グループに対して追加または削除することはできないため、個々のデータベースに対するアクセス許可は関係しません。

フェールオーバー グループの更新

フェールオーバー グループを更新するには、そのフェールオーバー グループ、および現在のプライマリ サーバーまたはマネージド インスタンス上のすべてのデータベースへの Azure RBAC 書き込みアクセス権が必要です。

フェールオーバー グループをフェールオーバーする

フェールオーバー グループをフェールオーバーするには、新しいプライマリ サーバーまたはマネージド インスタンス上のフェールオーバー グループへの Azure RBAC 書き込みアクセス権が必要です。

SQL Database のベスト プラクティス

自動フェールオーバー グループはプライマリ サーバーに構成する必要があり、それを別の Azure リージョンのセカンダリ サーバーに接続します。 グループには、これらのサーバーのすべてまたは一部のデータベースを含めることができます。 次の図に、複数のデータベースと自動フェールオーバー グループを使用する、geo 冗長クラウド アプリケーションの一般的な構成を示します。

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

注意

フェールオーバー グループに SQL Database のデータベースを追加する詳細なステップバイステップのチュートリアルについては、フェールオーバー グループへの SQL Database の追加に関するページを参照してください。

ビジネス継続性を考慮してサービスを設計する場合は、次の一般的なガイドラインに従います。

1 つまたは複数のフェールオーバー グループを使用して複数のデータベースのフェールオーバーを管理する

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

OLTP ワークロードに読み取り/書き込みのリスナーを使用する

OLTP 操作を実行するときに、サーバー URL として <fog-name>.database.windows.net を使用すると、自動的にプライマリに接続されます。 この URL はフェールオーバー後にも変更されません。 フェールオーバーでは DNS レコードの更新が行われるため、クライアントの接続は、クライアント DNS キャッシュが最新の情報に更新された後にのみ新しいプライマリにリダイレクトされます。

読み取り専用ワークロードに読み取り専用リスナーを使用する

データがある程度古くても構わない、論理的に分離された読み取り専用ワークロードがある場合、アプリケーションでセカンダリ データベースを使用できます。 読み取り専用セッションでは、サーバー URL として <fog-name>.secondary.database.windows.net を使用すると、自動的にセカンダリに接続されます。 ApplicationIntent=ReadOnly を使用して、接続文字列で読み取りの意図を示すこともお勧めします。

注意

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

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

パフォーマンスの低下に対して準備する

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

データ損失に対して準備する

機能停止が検出された場合は、GracePeriodWithDataLossHours で指定した期間、Azure が待機状態となります。 既定値は 1 時間です。 データの損失が許容できない場合は、必ず、GracePeriodWithDataLossHours を十分大きい数値 (24 時間など) に設定してください。 セカンダリからプライマリにフェールバックするには、手動のグループ フェールオーバーを使用します。

重要

800 以下の DTU と 250 を超えるデータベースを持ち、geo レプリケーションを使用するエラスティック プールでは、計画されたフェールオーバーに時間がかかったりパフォーマンスが低下したりする問題が発生することがあります。 こうした問題は、geo レプリケーション エンドポイントが地理的に広く分散している場合や、各データベースで複数のセカンダリ エンドポイントが使用されている場合に、書き込みの負荷が高いワークロードで発生しやすくなります。 このような症状は、geo レプリケーションのラグが時間の経過と共に増加するときに見られます。 このラグは、sys.dm_geo_replication_link_status を使用して監視できます。 この問題が発生する場合は、プール DTU の数を増やしたり、同じプール内で geo レプリケーションされるデータベースの数を減らしたりするなどの緩和策があります。

フェールオーバー グループのセカンダリ リージョンを変更する

変更のシーケンスを説明するために、サーバー A はプライマリ サーバー、サーバー B は既存のセカンダリ サーバー、サーバー C は 3 番目のリージョンの新しいセカンダリであると仮定します。 移行を行うには、次の手順を実行します。

  1. サーバー A の各データベースの追加のセカンダリを、アクティブ geo レプリケーションを使用してサーバー C に作成します。 サーバー A の各データベースには、2 つのセカンダリがあり、1 つはサーバー B に、もう 1 つはサーバー C にあります。これにより、移行中、プライマリ データベースが確実に保護された状態を維持できます。
  2. フェールオーバー グループを削除します。 この時点では、ログインは失敗します。 これは、フェールオーバー グループ リスナーの SQL エイリアスが削除されていて、ゲートウェイがフェールオーバー グループの名前を認識しないためです。
  3. サーバー A と C の間で同じ名前のフェールオーバー グループを再作成します。この時点で、ログインは失敗しなくなります。
  4. サーバー A のすべてのプライマリ データベースを新しいフェールオーバー グループに追加します。
  5. サーバー B を削除します。B のすべてのデータベースは自動的に削除されます。

フェールオーバー グループのプライマリ リージョンを変更する

変更のシーケンスを説明するために、サーバー A はプライマリ サーバー、サーバー B は既存のセカンダリ サーバー、サーバー C は 3 番目のリージョンの新しいプライマリであると仮定します。 移行を行うには、次の手順を実行します。

  1. 計画されたフェールオーバーを実行して、プライマリ サーバーを B に切り替えます。サーバー A が新しいセカンダリ サーバーになります。 フェールオーバーによって、数分間のダウンタイムが発生する場合があります。 実際の時間は、フェールオーバー グループのサイズによって異なります。
  2. サーバー B の各データベースの追加のセカンダリを、アクティブ geo レプリケーションを使用してサーバー C に作成します。 サーバー B の各データベースには、2 つのセカンダリがあり、1 つはサーバー A に、もう 1 つはサーバー C にあります。これにより、移行中、プライマリ データベースが確実に保護された状態を維持できます。
  3. フェールオーバー グループを削除します。 この時点では、ログインは失敗します。 これは、フェールオーバー グループ リスナーの SQL エイリアスが削除されていて、ゲートウェイがフェールオーバー グループの名前を認識しないためです。
  4. サーバー B と C の間で同じ名前のフェールオーバー グループを再作成します。この時点で、ログインは失敗しなくなります。
  5. B のすべてのプライマリ データベースを新しいフェールオーバー グループに追加します。
  6. フェールオーバー グループの計画されたフェールオーバーを実行して B と C を切り替えます。これで、サーバー C がプライマリになり、B がセカンダリになります。 サーバー A 上のすべてのセカンダリ データベースは、自動的に C のプライマリにリンクされます。手順 1 と同様に、フェールオーバーによって数分間のダウンタイムが発生する場合があります。
  7. サーバー A を削除します。A のすべてのデータベースは自動的に削除されます。

重要

フェールオーバー グループを削除すると、リスナー エンドポイントの DNS レコードも削除されます。 その時点では、他のユーザーが同じ名前のフェールオーバー グループまたはサーバー エイリアスを作成する可能性がゼロではなく、それが起こると、そのフェールオーバー グループやサーバー エイリアスは再び使用できなくなります。 このリスクを最小限に抑えるために、一般的なフェールオーバー グループ名は使用しないでください。

SQL Managed Instance のベスト プラクティス

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

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

自動フェールオーバーの図

注意

フェールオーバー グループを使用するための SQL Managed Instance の追加に関する詳細なステップバイステップのチュートリアルについては、フェールオーバー グループへのマネージド インスタンスの追加に関するページを参照してください。

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

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

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

重要

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

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

geo ペア リージョンの使用

パフォーマンス上の理由により、両方のマネージド インスタンスを、ペアになっているリージョンにデプロイします。 geo ペア リージョンに存在するマネージド インスタンスは、ペアになっていないリージョンと比較すると、パフォーマンスがはるかに優れています。

2 つのインスタンス間のレプリケーション トラフィックを有効にする

各インスタンスは独自の VNet に分離されるため、これらの VNet 間の 2 方向トラフィックを許可する必要があります。 Azure VPN ゲートウェイに関するページを参照してください

異なるサブスクリプションのマネージド インスタンス間でフェールオーバー グループを作成する

サブスクリプションが同じ Azure Active Directory テナントに関連付けられている限り、2 つの異なるサブスクリプションの SQL Managed Instances 間でフェールオーバー グループを作成することができます。 PowerShell API を使用する場合は、セカンダリ SQL Managed Instance の PartnerSubscriptionId パラメーターを指定することでこれを実行できます。 REST API を使用している場合、properties.managedInstancePairs パラメーターに含まれる各インスタンス ID は、独自のサブスクリプション ID を持つことができます。

重要

Azure portal では、異なるサブスクリプション間でのフェールオーバー グループの作成はサポートされません。 また、異なるサブスクリプションやリソース グループにまたがる既存のフェールオーバー グループについては、プライマリ SQL Managed Instance からポータルを使用して手動でフェールオーバーを開始することはできません。 代わりに、geo セカンダリ インスタンスから開始してください。

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

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

重要

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

OLTP ワークロードに読み取り/書き込みのリスナーを使用する

OLTP 操作を実行するときに、サーバー URL として <fog-name>.zone_id.database.windows.net を使用すると、自動的にプライマリに接続されます。 この URL はフェールオーバー後にも変更されません。 フェールオーバーでは DNS レコードの更新が行われるため、クライアントの接続は、クライアント DNS キャッシュが最新の情報に更新された後にのみ新しいプライマリにリダイレクトされます。 セカンダリ インスタンスでは DNS ゾーンをプライマリと共有するため、同じ SAN 証明書を使用してクライアント アプリケーションを再接続できます。

読み取り専用リスナーを使用してセカンダリ インスタンスに接続する

データがある程度古くても構わない、論理的に分離された読み取り専用ワークロードがある場合、アプリケーションでセカンダリ データベースを使用できます。 geo レプリケートされたセカンダリに直接接続するには、<fog-name>.secondary.<zone_id>.database.windows.net をサーバー URL として使用します。これにより、geo レプリケートされたセカンダリに直接接続されます。

注意

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 を使用します。

パフォーマンスの低下に対して準備する

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

データ損失に対して準備する

機能停止が検出された場合、経験的にデータの損失がゼロであれば、読み取り/書き込みのフェールオーバーがトリガーされます。 そうでないと、GracePeriodWithDataLossHours を使用して指定した期間のフェールオーバーは延期されます。 GracePeriodWithDataLossHours を指定した場合は、データの損失に備えてください。 一般に、機能の停止中、Azure では可用性が重視されます。 データの損失が許容できない場合は、必ず、GracePeriodWithDataLossHours を十分大きい数値 (24 時間など) に設定するか、自動フェールオーバーを無効にしてください。

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

重要

プライマリを元の場所に戻すには、手動のグループ フェールオーバーを使用します。 フェールオーバーの原因となった機能停止が軽減されたら、プライマリ データベースを元の場所に移動できます。 そのためには、グループの手動フェールオーバーを開始する必要があります。

フェールオーバー グループのセカンダリ リージョンを変更する

インスタンス A がプライマリ インスタンス、インスタンス B が既存のセカンダリ インスタンス、インスタンス C が 3 番目のリージョン内の新しいセカンダリ インスタンスであるとします。 移行を行うには、次の手順を実行します。

  1. 同じ DNS ゾーン内で、A と同じサイズのインスタンス C を作成します。
  2. インスタンス A と B 間のフェールオーバー グループを削除します。この時点ではログインは失敗します。フェールオーバー グループ リスナーの SQL エイリアスが削除されていて、ゲートウェイがフェールオーバー グループ名を認識しないためです。 セカンダリ データベースはプライマリから切断され、読み取り/書き込みデータベースになります。
  3. インスタンス A と C の間に同じ名前のフェールオーバー グループを作成します。SQL Managed Instance を含むフェールオーバー グループのチュートリアルに関するページの手順に従ってください。 これはデータ サイズに左右される操作であり、インスタンス A のすべてのデータベースがシード処理され、同期されると完了します。
  4. 不要な料金が発生しないように、インスタンス B が不要であれば削除してください。

注意

手順 2 の後、手順 3 が完了するまでは、インスタンス A のデータベースは、インスタンス A の致命的な障害から保護されないままになります。

フェールオーバー グループのプライマリ リージョンを変更する

インスタンス A がプライマリ インスタンス、インスタンス B が既存のセカンダリ インスタンス、インスタンス C が 3 番目のリージョン内の新しいプライマリ インスタンスであるとします。 移行を行うには、次の手順を実行します。

  1. 同じ DNS ゾーン内で、B と同じサイズのインスタンス C を作成します。
  2. インスタンス B に接続し、手動でフェールオーバーしてプライマリ インスタンスを B に切り替えます。インスタンス A が自動的に新しいセカンダリ インスタンスになります。
  3. インスタンス A と B 間のフェールオーバー グループを削除します。この時点ではログインは失敗します。フェールオーバー グループ リスナーの SQL エイリアスが削除されていて、ゲートウェイがフェールオーバー グループ名を認識しないためです。 セカンダリ データベースはプライマリから切断され、読み取り/書き込みデータベースになります。
  4. インスタンス A と C の間に同じ名前のフェールオーバー グループを作成します。マネージド インスタンスを含むフェールオーバー グループのチュートリアルに関する記事の手順に従ってください。 これはデータ サイズに左右される操作であり、インスタンス A のすべてのデータベースがシード処理され、同期されると完了します。
  5. 不要な料金が発生しないように、インスタンス A が不要であれば削除してください。

注意事項

手順 3 の後、手順 4 が完了するまでは、インスタンス A のデータベースは、インスタンス A の致命的な障害から保護されないままになります。

重要

フェールオーバー グループを削除すると、リスナー エンドポイントの DNS レコードも削除されます。 その時点では、他のユーザーが同じ名前のフェールオーバー グループまたはサーバー エイリアスを作成する可能性がゼロではなく、それが起こると、そのフェールオーバー グループやサーバー エイリアスは再び使用できなくなります。 このリスクを最小限に抑えるために、一般的なフェールオーバー グループ名は使用しないでください。

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

システム データベースは、フェールオーバー グループのセカンダリ インスタンスにはレプリケート されません。 システム データベースのオブジェクトに依存するシナリオを実現するには、セカンダリ インスタンスに同じオブジェクトを作成し、プライマリ インスタンスとの同期を維持する必要があります。 たとえば、セカンダリ インスタンスで同じログインを使用する予定の場合は、必ず、同じ SID でそれらを作成してください。

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

プライマリ インスタンスとセカンダリ インスタンスの間でインスタンスのプロパティと保持ポリシーを同期する

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

フェールオーバー グループとネットワーク セキュリティ

一部のアプリケーションについてセキュリティ規則では、データ層へのネットワーク アクセスを、VM や Web サービスなど、特定の 1 つまたは複数のコンポーネントに限定する必要があります。ビジネス継続性の設計と、フェールオーバー グループの使用において、この要件は課題となっています。 このような制限付きアクセスを実装する場合は、次のオプションを検討してください。

フェールオーバー グループと仮想ネットワーク規則を使用する

仮想ネットワーク サービス エンドポイントおよび規則を使用して、SQL Database または SQL Managed Instance のデータベースへのアクセスを制限する場合、各仮想ネットワーク サービス エンドポイントは 1 つの Azure リージョンにのみ適用されることに注意してください。 エンドポイントが他のリージョンを有効にして、サブネットからの通信を許可することはありません。 そのため、同じリージョンにデプロイされているクライアント アプリケーションのみが、プライマリ データベースに接続できます。 フェールオーバーの結果として SQL Database クライアント セッションは別の (セカンダリ) リージョン内のサーバーに再ルーティングされるので、これらのセッションは、そのリージョンの外部にあるクライアントから発生した場合に失敗します。 そのため、参加するサーバーまたはインスタンスが仮想ネットワーク規則に含まれている場合、自動フェールオーバー ポリシーを有効にすることはできません。 手動フェールオーバーをサポートするには、次の手順を行います。

  1. セカンダリ リージョンで (Web サービスや仮想マシンなどの) アプリケーションのフロントエンド コンポーネントの冗長コピーをプロビジョニングする
  2. プライマリ サーバーとセカンダリ サーバーに対して別々に仮想ネットワーク規則を構成する
  3. Traffic Manager の構成を使用したフロント エンド フェールオーバーを有効にする
  4. 機能停止が検出されたときに手動フェールオーバーを開始する。 このオプションは、フロント エンドとデータ層の間で一貫した待機時間を必要とするアプリケーションに対して最適化されており、フロント エンド、データ層、またはこの両方が機能停止の影響を受ける場合に回復をサポートします。

注意

読み取り専用リスナー を使用して読み取り専用ワークロードの負荷を分散する場合は、このワークロードを必ずセカンダリ リージョン内の VM などのリソースで実行することで、セカンダリ データベースに接続できるようにします。

フェールオーバー グループおよびファイアウォール規則を使用する

ビジネス継続性計画でグループを使用するフェールオーバーと自動フェールオーバーが必要な場合は、従来のファイアウォール規則を使用して、SQL Database 内のデータベースへのアクセスを制限することができます。 自動フェールオーバーをサポートするには、次の手順を行います。

  1. パブリック IP を作成します
  2. パブリック ロード バランサーを作成し、パブリック IP を割り当てます。
  3. フロント エンド コンポーネントに対して仮想ネットワークと仮想マシンを作成します。
  4. ネットワーク セキュリティ グループを作成し、受信接続を構成します。
  5. ‘Sql’ サービス タグを使用して、確実に Azure SQL Database への送信接続が開かれるようにします。
  6. SQL Database ファイアウォール規則を作成して、手順 1 で作成したパブリック IP アドレスからの受信トラフィックを許可します。

送信アクセスを構成する方法と、ファイアウォール規則で使用する IP の詳細については、ロード バランサー送信接続に関するページを参照してください。

上記の構成では、自動フェールオーバーによって、フロント エンド コンポーネントからの接続がブロックされることはありません。また、フロント エンドとデータ層の間の長い待機時間がアプリケーションで許容されることを前提としています。

重要

リージョンの機能停止に対してビジネス継続性を保証するためには、フロント エンド コンポーネントとデータベースの両方に対して地理的な冗長性を確保する必要があります。

マネージド インスタンスとその VNet の間の geo レプリケーションを有効にする

2 つの異なるリージョンのプライマリとセカンダリの SQL Managed Instance の間にフェールオーバー グループを設定すると、各インスタンスは独立した仮想ネットワークを使用して分離されます。 これらの VNet 間のレプリケーション トラフィックを許可するには、以下の前提条件が満たされていることを確認します。

  • SQL Managed Instance の 2 つのインスタンスは、異なる Azure リージョンにある必要があります。

  • SQL Managed Instance の 2 つのインスタンスは同じサービス レベルである必要があり、ストレージ サイズも同じである必要があります。

  • SQL Managed Instance のセカンダリ インスタンスは空 (ユーザー データベースなし) である必要があります。

  • SQL Managed Instance のインスタンスによって使用される仮想ネットワークは、VPN Gateway または Express Route 経由で接続されている必要があります。 2 つの仮想ネットワークがオンプレミスのネットワーク経由で接続されている場合、ポート 5022 および 11000-11999 をブロックするファイアウォール規則がないことを確認します。 グローバル VNet ピアリングはサポート対象ですが、次の注記で説明する制限事項があります。

    重要

    2020 年 9 月 22 日に、新しく作成された仮想クラスターに対するグローバル仮想ネットワーク ピアリングのサポートが発表されました。 つまり、この発表日の後に空のサブネット内に作成された SQL Managed Instance のほか、これらのサブネット内に作成されたそれ以降のすべてのマネージド インスタンスでグローバル仮想ネットワーク ピアリングがサポートされます。 その他のすべての SQL Managed Instance では、グローバル仮想ネットワーク ピアリングの制約のために、ピアリングのサポートが同じリージョン内のネットワークに制限されます。 詳細については、Azure Virtual Networks のよく寄せられる質問に関する記事の関連セクションも参照してください。 この発表日の前に作成された仮想クラスターの SQL Managed Instance でグローバル仮想ネットワーク ピアリングを使用できるようにするには、そのインスタンス上で既定以外のメンテナンス期間を構成することを検討してください。それにより、そのインスタンスが、グローバル仮想ネットワーク ピアリングをサポートする新しい仮想クラスターに移動されます。

  • 2 つの SQL Managed Instance VNet に、重複する IP アドレスを含めることはできません。

  • 他のマネージド インスタンスのサブネットからの接続では、インバウンドおよびアウトバウンドでポート 5022 およびその範囲の 11000 から 12000 を開くように、ネットワーク セキュリティ グループ (NSG) を設定する必要があります。 これで、インスタンス間のレプリケーション トラフィックを許可します。

    重要

    NSG セキュリティ規則が正しく構成されていないと、データベースのコピー操作が停止します。

  • セカンダリ SQL Managed Instance は正しい DNS ゾーン ID で構成されます。 DNS ゾーンは、SQL Managed Instance と基になる仮想クラスターのプロパティであり、ホスト名のアドレスにその ID が含まれます。 ゾーン ID は、各 VNet で最初の SQL Managed Instance が作成されたときに、ランダムな文字列として生成され、同じ ID が同じサブネットの他のすべてのインスタンスに割り当てられます。 一度割り当てられると、DNS ゾーンは変更できません。 同じフェールオーバー グループに含まれる SQL Managed Instance で、DNS ゾーンを共有する必要があります。 これは、セカンダリ インスタンスの作成時、プライマリ インスタンスのゾーン ID を DnsZonePartner パラメーターの値として渡すことで実行します。

    注意

    SQL Managed Instance を使用したフェールオーバー グループの構成の詳細なチュートリアルについては、フェールオーバー グループへの SQL Managed Instance の追加に関するページを参照してください。

プライマリ データベースのアップグレードまたはダウングレード

セカンダリ データベースの接続を解除することなく、プライマリ データベースを異なるコンピューティング サイズにアップグレードまたはダウングレードできます。 アップグレードの場合は、最初にすべてのセカンダリ データベースをアップグレードしてからプライマリ データベースをアップグレードすることをお勧めします。 ダウングレードは逆の順序で行います。つまり、最初にプライマリ データベースをダウングレードしてからすべてのセカンダリ データベースをダウングレードします。 データベースを異なるサービス レベルにアップグレードまたはダウングレードすると、この推奨事項が強制されます。

より低い SKU のセカンダリが過負荷になり、アップグレードまたはダウングレー ドのプロセス中に再シードする必要があるという問題を回避するために、このシーケンスが特に推奨されます。 プライマリを読み取り専用にすることでこの問題を回避することもできます。その場合、プライマリへのすべての読み取り/書き込みワークロードに影響が出ることになります。

注意

セカンダリ データベースをフェールオーバー グループ構成の一部として作成した場合、セカンダリ データベースをダウングレードすることはお勧めできません。 これは、フェールオーバーがアクティブ化された後にデータ層に通常のワークロードを処理するのに十分な容量を確保するためです。

重要なデータの損失の防止

ワイド エリア ネットワークの遅延は大きいため、連続コピーでは非同期のレプリケーション メカニズムが使用されます。 非同期レプリケーションでは、障害が発生した場合に部分的なデータ損失が避けられません。 しかし、データ損失が許されないアプリケーションもあります。 重要な更新情報を保護するには、アプリケーション開発者は、トランザクションがコミットされた直後に sp_wait_for_database_copy_sync ステム プロシージャを呼び出すことができます。 sp_wait_for_database_copy_sync を呼び出すと、最後にコミットされたトランザクションがセカンダリ データベースに転送されるまで、呼び出しスレッドがブロックされます。 ただし、転送されたトランザクションがセカンダリで再生およびコミットされるのを待つことはありません。 sp_wait_for_database_copy_sync は、特定の連続コピー リンクを対象としています。 プライマリ データベースへの接続権限を持つユーザーが、このプロシージャを呼び出すことができます。

注意

sp_wait_for_database_copy_sync は、フェールオーバー後のデータの損失を防ぎますが、読み取りアクセスに対して完全な同期を保証しません。 sp_wait_for_database_copy_sync プロシージャ呼び出しによる遅延は、長くなる場合があり、呼び出し時のトランザクション ログのサイズによって異なります。

フェールオーバー グループとポイントインタイム リストア

フェールオーバー グループでのポイントインタイム リストアの使用については、特定の時点への復元 (PITR) に関するページを参照してください。

フェールオーバー グループの制限

次の制限事項に注意してください。

  • 同じ Azure リージョン内の 2 つのサーバーまたはインスタンス間で、フェールオーバー グループを作成することはできません。
  • フェールオーバー グループの名前を変更することはできません。 グループを削除し、別の名前で再作成する必要があります。
  • データベース名の変更は、フェールオーバー グループ内のインスタンスに対してはサポートされていません。 データベース名を変更するには、フェールオーバー グループを一時的に削除する必要があります。
  • システム データベースは、フェールオーバー グループのセカンダリ インスタンスには レプリケートされません。 したがって、システム データベースのオブジェクトに依存するシナリオでは、オブジェクトをセカンダリ インスタンスで手動で作成する必要があります。また、プライマリ インスタンスで行われた変更があれば、手動で同期を保つ必要があります。 唯一の例外は SQL Managed Instance のサービス マスター キー (SMK) で、これはフェールオーバー グループの作成時にセカンダリ インスタンスに自動的にレプリケートされます。 ただし、プライマリ インスタンスでの SMK のその後の変更は、セカンダリ インスタンスにレプリケートされません。
  • インスタンスが自動フェールオーバー グループに参加している場合に、インスタンスの接続の種類を変更しても、フェールオーバー グループ リスナー エンドポイントを介して確立された接続で有効になりません。 接続の種類の変更を有効にするには、自動フェールオーバー グループを一時的に削除して再作成する必要があります。

フェールオーバー グループのプログラムによる管理

前に説明したように、自動フェールオーバー グループとアクティブ geo レプリケーションは、Azure PowerShell および REST API を使用してプログラムによって管理することもできます。 次の表では、使用できるコマンド セットについて説明します。 アクティブ geo レプリケーションには、管理のための Azure Resource Manager API 一式 (Azure SQL Database REST APIAzure PowerShell コマンドレットなど) が含まれています。 これらの API では、リソース グループを使用する必要があり、Azure のロール ベースのアクセス制御 (Azure RBAC) がサポートされます。 アクセス ロールの実装方法の詳細については、Azure のロール ベースのアクセス制御 (Azure RBAC) に関するページをご覧ください。

SQL Database のフェールオーバーを管理する

コマンドレット 説明
New-AzSqlDatabaseFailoverGroup このコマンドはフェールオーバー グループを作成し、それをプライマリとセカンダリの両方のサーバーに登録します。
Remove-AzSqlDatabaseFailoverGroup フェールオーバー グループをサーバーから削除します。
Get-AzSqlDatabaseFailoverGroup フェールオーバー グループの構成を取得します。
Set-AzSqlDatabaseFailoverGroup フェールオーバー グループの構成を変更します。
Switch-AzSqlDatabaseFailoverGroup セカンダリ サーバーへのフェールオーバー グループのフェールオーバーをトリガーします
Add-AzSqlDatabaseToFailoverGroup 1 つまたは複数のデータベースをフェールオーバー グループに追加します。

SQL Managed Instance のフェールオーバーを管理する

コマンドレット 説明
New-AzSqlDatabaseInstanceFailoverGroup このコマンドはフェールオーバー グループを作成し、それをプライマリとセカンダリの両方のインスタンスに登録します。
Set-AzSqlDatabaseInstanceFailoverGroup フェールオーバー グループの構成を変更します。
Get-AzSqlDatabaseInstanceFailoverGroup フェールオーバー グループの構成を取得します。
Switch-AzSqlDatabaseInstanceFailoverGroup フェールオーバー グループのセカンダリ インスタンスに対するフェールオーバーをトリガーします。
Remove-AzSqlDatabaseInstanceFailoverGroup フェールオーバー グループを削除します

次のステップ