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

適用対象: Azure SQL Managed Instance

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

この機能の使用を開始するには、「Azure SQL Managed Instance のフェールオーバー グループの構成」を参照してください。

概要

フェールオーバー グループ機能を使うと、マネージド インスタンスから別の Azure リージョンのマネージド インスタンスへのユーザー データベースのレプリケーションとフェールオーバーを管理できます。 フェールオーバー グループは、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.
• マイクロソフトマネージド - プライマリ リージョンに影響を与える広範囲にわたる停止が発生した場合、マイクロソフトは、マイクロソフトが管理するように構成されたフェールオーバー ポリシーを持つ影響を受けるすべてのフェールオーバー グループのフェールオーバーを開始します。 マイクロソフトマネージド フェールオーバーは、個々のフェールオーバー グループまたはリージョン内のフェールオーバー グループのサブセットに対して開始されません。 PowerShell、Azure CLI、Rest API などのコマンド ライン ツールを使用する場合、マイクロソフトが管理するフェールオーバー ポリシーの値は automatic.

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

お客様による管理

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

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

Microsoft マネージド

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

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

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

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

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

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

用語と機能

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

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

  重要

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

• プライマリ

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

• セカンダリ

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

  重要

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

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

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

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

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

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

• データ消失の猶予期間

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

• DNS ゾーン

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

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

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

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

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

  Note

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

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

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

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

アプリケーションでデータ層として 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 です。

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

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

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

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

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

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

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

• グローバル仮想ネットワーク ピアリング
• VPN ゲートウェイ
• Azure ExpressRoute

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

初期シード処理

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

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

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

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

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

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

読み取りリスナーを使用する (セカンダリ 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 を使用します。

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

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

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

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

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

DNS の更新

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

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

セカンダリ マネージド インスタンスをディザスター リカバリー (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 セカンダリをスケールアップしてから、プライマリをスケールアップすることをお勧めします。 同じサービス レベル内でスケールダウンするときは、順序を逆にします。つまり最初にプライマリをスケールダウンしてから、セカンダリをスケールダウンします。 インスタンスを異なるサービス レベルにスケーリングするときは、この推奨事項が適用されます。 この一連の操作は、サービス レベルと仮想コア、ストレージをスケーリングする場合に適用されます。

下位の SKU の geo セカンダリが過負荷になり、アップグレードまたはダウングレード プロセス中に再シードする必要があるという問題を回避するために、このシーケンスが特に推奨されます。

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

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

ユーザーが開始した計画的な geo フェールオーバー中のデータ損失を防ぐために、レプリケーションが自動的かつ一時的に同期レプリケーションに変更されてから、フェールオーバーが実行されます。 geo フェールオーバーが完了すると、レプリケーションは非同期モードに戻ります。

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

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

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

フェールバック

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

機能の相互運用性

バックアップ

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

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

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

ログ再生サービス

ログ再生サービス (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 ドリルを実行するには、テスト フェールオーバーのチュートリアルに従って手動計画フェールオーバーの使用をお勧めします。

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

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

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

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

• データ ロスレス フェイルオーバーと同じ手順に従います。
• 最初の強制フェールオーバーが完了した直後に強制フェールバックが実行された場合、以前のプライマリ マネージド インスタンスで未処理の自動バックアップ操作が完了するのを待機する必要があるため、フェールバックの実行時間が長くなることが予想されます。

関連するコンテンツ

• フェールオーバー グループを構成する
• PowerShell を使用してマネージド インスタンスをフェールオーバー グループに追加する
• Azure SQL Managed Instance のライセンスフリー スタンバイ レプリカを構成する
• Azure SQL Managed Instance によるビジネス継続性の概要
• Azure SQL Managed Instance での自動バックアップ
• Azure SQL Managed Instance のバックアップからデータベースを復元する