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

  • [アーティクル]

適用対象:Azure SQL Database

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

開始するには、「自動フェールオーバー グループの構成」を確認してください。 エンドツーエンドのエクスペリエンスについては、「自動フェールオーバー グループのチュートリアル」を参照してください。

注意

  • この記事では、Azure SQL Managed Database の自動フェールオーバー グループについて説明します。 Azure SQL Managed Instance については、「Azure SQL Managed Instance で自動フェールオーバー グループを構成する」を参照してください。
  • 自動フェールオーバー グループでは、グループ内のすべてのデータベースを別のリージョンの 1 つのセカンダリ論理サーバーにのみ geo レプリケートできます。 同じプライマリ レプリカに対して複数Azure SQL Database geo セカンダリ レプリカ (同じリージョンまたは異なるリージョン) を作成する必要がある場合は、アクティブ geo レプリケーションを使用します。

概要

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

Automatic failover

geo フェールオーバーは手動で開始するか、ユーザー定義ポリシーに基づいて Azure サービスに委任できます。 後者のオプションの場合、プライマリ リージョンで発生した致命的な障害やその他の計画外のイベントにより SQL Database や SQL Managed Instance の可用性がすべてまたは一部失われたときに、セカンダリ リージョンの複数の関連データベースを自動的に復元できます。 通常、これらは組み込みの高可用性インフラストラクチャでは自動的に軽減できない停止です。 geo フェールオーバー トリガーの例としては、自然災害や、コンピューティング ノードでの OS カーネル メモリ リークが原因でテナントまたは制御リングがダウンした場合のインシデントがあります。

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

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

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

自動フェールオーバー グループには、geo フェールオーバー中にそのまま残る読み取り/書き込みおよび読み取り専用リスナー エンドポイントが用意されています。 接続は現在のプライマリに自動的にルーティングされるので、geo フェールオーバー後にアプリケーションの接続文字列を変更する必要はありません。 手動または自動フェールオーバーのアクティブ化を使用する場合でも、geo フェールオーバーでは、グループ内のすべてのセカンダリ データベースがプライマリ ロールに切り替まれます。 geo フェールオーバーが完了すると、DNS レコードが自動的に更新され、エンドポイントが新しいリージョンにリダイレクトされます。 geo フェールオーバー RPO と RTO については、「ビジネス継続性の 概要」を参照してください。

アプリケーションの回復

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

詳しくは、Azure SQL Database の高可用性に関する記事をご覧ください。

用語と機能

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

    フェールオーバー グループは、プライマリ リージョンでの機能停止により、すべてまたは一部のプライマリ データベースが使用できなくなった場合に、1 つの単位として別の Azure リージョンにフェールオーバーできる単一の論理サーバーによって管理されるデータベースの名前付きグループです。

    重要

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

  • サーバー

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

  • プライマリ

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

  • セカンダリ

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

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

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

    重要

    既存のセカンダリ データベースである場合を除き、セカンダリ論理サーバーに同じ名前のデータベースがないことを確認してください。

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

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

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

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

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

    現在のセカンダリをポイントする DNS CNAME レコード。 フェールオーバー グループが作成されると自動的に作成され、フェールオーバー後にセカンダリが変更されると、読み取り専用の SQL ワークロードがセカンダリに透過的に接続できます。 サーバーでフェールオーバー グループが作成されたときに、リスナー URL の DNS CNAME レコードの形式は <fog-name>.secondary.database.windows.net になります。

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

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

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

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

    Note

    停止の規模とそれを軽減する速度の検証には人間が関わる必要があるため、1 時間未満には猶予期間を設定できず、フェールオーバーの正確な時刻が設定された猶予期間とは若干異なる場合があります。 この制約は、データの同期状態に関係なく、フェールオーバー グループ内のすべてのデータベースに適用されます。

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

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

    Note

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

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

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

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

    Note

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

  • 計画されていないフェールオーバー

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

  • 手動フェールオーバー

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

  • データ消失の猶予期間

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

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

Azure SQL Database のフェールオーバー グループには、通常同じアプリケーションによって使用される、1 つまたは複数のデータベースを含めることができます。 自動フェールオーバー ポリシーで自動フェールオーバー グループを使用している場合、グループ内の 1 つ以上のデータベースに影響を与える停止により、自動 geo フェールオーバーが発生します。

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

Diagram shows a typical configuration of a geo-redundant cloud application using multiple databases and auto-failover group.

ビジネス継続性を念頭に置いてサービスを設計する場合は、この記事で説明されている一般的なガイドラインとベスト プラクティスに従ってください。 フェールオーバー グループを構成する場合は、geo フェールオーバー後に geo セカンダリが新しいプライマリになったときに、セカンダリの認証とネットワーク アクセスが正しく機能するように設定されていることを確認します。 詳細については、 障害復旧後の SQL Database のセキュリティに関するページを参照してください。 ディザスター リカバリーのソリューション設計の詳細については、アクティブ geo レプリケーションを使用したディザスター リカバリー用のクラウド ソリューションの設計に関するページを参照してください。

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

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

パフォーマンス上の理由により、両方のマネージド インスタンスを、ペアになっているリージョンにデプロイします。 ペアのリージョン内の Azure SQL Database フェールオーバー グループのパフォーマンスは、ペアになっていないリージョンより優れています。

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

データベースで geo レプリケーションまたは自動フェールオーバー グループが構成されていて、geo レプリケーションが 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、接続文字列のサーバー名として を使用します。 接続は自動的に geo セカンダリに向けられる。 ApplicationIntent=ReadOnly を使用して、接続文字列で読み取りの意図を示すこともお勧めします。

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

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

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

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

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

プライマリ リージョンで障害が発生した場合、最近のトランザクションを geo セカンダリにレプリケートできない可能性があります。 自動フェールオーバー ポリシーが構成されている場合、自動 geo フェールオーバーを開始する前に、 で指定した期間システム GracePeriodWithDataLossHours が待機します。 既定値は 1 時間です。 これにより、データが失われるのを超えるデータベースの可用性が向上します。 24 時間など、より大きな数に設定したり、自動 geo フェールオーバーを無効にしたりすると、データベースの可用性を犠牲にしてデータ損失の可能性 GracePeriodWithDataLossHours を減らできます。

重要

DTC が 800 以下、仮想コア数が 8 以下、データベース数が 250 を超えるエラスティック プールでは、計画された geo フェールオーバーの時間の長さやパフォーマンスの低下などの問題が発生する可能性があります。 これらの問題は、書き込み集中型のワークロード、geo レプリカが地理的に広く分離されている場合、またはデータベースごとに複数のセカンダリ geo レプリカが使用されている場合に発生する可能性が高い。 これらの問題の症状は、時間の過ぎた geo レプリケーションのラグが増加し、停止中のデータ損失が拡大する可能性があります。 このラグは、sys.dm_geo_replication_link_status を使用して監視できます。 これらの問題が発生した場合の軽減策には、DTC または仮想コアを増やしたり、プール内の geo レプリケートされたデータベースの数を減らしたりするために、プールをスケールアップする作業が含まれます。

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

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

フェールオーバーグループと仮想ネットワークサービスエンドポイントの使用

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

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

Note

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

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

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

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

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

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

重要

地域的な障害発生時のビジネス継続性を保証するには、フロントエンドコンポーネントとデータベースの両方で地理的な冗長性を確保する必要があります。

プライマリデータベースのスケーリング

Geo セカンダリを切断せずに、プライマリデータベースを (同じサービスレベル内の) 別のコンピューティングサイズにスケールアップまたはスケールダウンすることができます。 スケールアップするときは、まず geo セカンダリをスケールアップしてから、プライマリをスケールアップすることをお勧めします。 スケールダウンする場合は、順序を逆にします。最初にプライマリをスケールダウンし、次にセカンダリをスケールダウンします。 データベースを別のサービス階層にスケーリングする場合は、この推奨設定が適用されます。

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

Note

フェールオーバーグループの構成の一部として geo セカンダリを作成した場合は、geo セカンダリをスケールダウンすることは推奨されません。 これは、geo フェールオーバー後の通常のワークロードを処理するのに十分な容量がデータ層にあることを確認するためのものです。 障害が原因で以前の geo プライマリが使用できない場合、強制フェールオーバー後に geo セカンダリをスケーリングできないことがあります。 私たちはこの制限を認識しており、間もなく修正する予定です。

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

ワイドエリアネットワークの待機時間が長いため、geo レプリケーションは非同期レプリケーションメカニズムを使用します。 非同期レプリケーションを使用すると、プライマリに障害が発生した場合にデータ損失が回避される可能性があります。 重要なトランザクションをデータ損失から保護するために、アプリケーション開発者はトランザクションをコミットした直後に sp_wait_for_database_copy_sync ストアドプロシージャを呼び出すことができます。 を呼び出す sp_wait_for_database_copy_sync と、最後にコミットされたトランザクションが転送され、セカンダリデータベースのトランザクションログに書き込まれるまで、呼び出し元のスレッドがブロックされます。 ただし、転送されたトランザクションがセカンダリで再生 (再実行) されるのを待機することはありません。 sp_wait_for_database_copy_sync は、特定の geo レプリケーションリンクにスコープが設定されています。 プライマリ データベースへの接続権限を持つユーザーが、このプロシージャを呼び出すことができます。

Note

sp_wait_for_database_copy_sync 特定のトランザクションの geo フェールオーバー後のデータ損失を防ぎますが、読み取りアクセスの完全同期は保証しません。 プロシージャ呼び出しによって発生する遅延は sp_wait_for_database_copy_sync 大きくなる可能性があり、呼び出し時のプライマリでまだ転送されていないトランザクションログのサイズによって異なります。

フェールバック

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

アクセス許可

フェールオーバー グループに対するアクセス許可は、Azure ロールベースのアクセス制御 (Azure RBAC) によって管理されます。

フェールオーバー グループを作成および管理するには、Azure RBAC 書き込みアクセスが必要です。 SQL Server 共同作成者ロールには、フェールオーバー グループを管理するために必要なすべてのアクセス許可があります。

特定のアクセス許可スコープについては、Azure SQL Database の自動フェイルオーバー グループを設定する方法を確認してください。

制限事項

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

  • 同じ Azure リージョン内の 2 つのサーバー間で、フェールオーバー グループを作成することはできません。
  • フェールオーバー グループの名前を変更することはできません。 グループを削除し、別の名前で再作成する必要があります。
  • フェールオーバー グループ内のデータベースでは、データベース名の変更はサポートされていません。 データベースの名前を変更したり、フェールオーバー グループからデータベースを削除したりするには、フェールオーバー グループを一時的に削除する必要があります。

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

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

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

Note

Az.SQL 3.11.0 以降の Azure Powershell では、-PartnerSubscriptionId パラメーターを使って、サブスクリプション全体に自動フェールオーバー グループをデプロイできます。 詳細については、以下の例を参照してください。

次のステップ