アクティブな地理的レプリケーション

  • [アーティクル]

適用対象:Azure SQL Database

アクティブ geo レプリケーションは、プライマリ データベースに対して継続的に同期された読み取り可能なセカンダリ データベースを作成できる機能です。 読み取り可能なセカンダリ データベースは、プライマリと同じ Azure リージョンにあっても、別のリージョン (こちらの方が一般的) にあってもかまいません。 この種の読み取り可能なセカンダリ データベースは、geo セカンダリまたは geo レプリカとも呼ばれます。

アクティブ geo レプリケーションはデータベースごとに構成され、手動フェールオーバーのみがサポートされます。 データベースのグループをフェールオーバーする場合、またはアプリケーションで安定した接続エンドポイントが必要な場合は、代わりにフェールオーバー グループを検討してください。

[アクティブ geo レプリケーションで SQL Database を移行する] を使用することもできます。

概要

アクティブ geo レプリケーションは、ビジネス継続性ソリューションとして設計されています。 アクティブ geo レプリケーションにより、地域的な災害や大規模な障害が発生した場合でも、個々のデータベースを迅速にディザスター リカバリーすることができます。 Geo レプリケーションを設定したら、別の Azure リージョンの geo セカンダリへの geo フェールオーバーを開始できます。 Geo フェールオーバーは、アプリケーションによってプログラムで、またはユーザーが手動で開始します。

次の図に、アクティブ geo レプリケーションを使用して行われる geo 冗長クラウド アプリケーションの一般的な構成を示します。

active geo-replication

何らかの理由でプライマリ データベースが失敗した場合は、任意のセカンダリ データベースに geo フェールオーバーを開始できます。 セカンダリがプライマリ ロールに昇格すると、他のすべてのセカンダリが新しいプライマリに自動的にリンクされます。

Geo レプリケーションを管理し、以下を使用して geo フェールオーバーを開始できます。

アクティブ geo レプリケーションでは、Always On 可用性グループ テクノロジを利用して、プライマリ レプリカで生成されたトランザクション ログをすべての geo レプリカに非同期的にレプリケートします。 特定の時点におけるセカンダリ データベースは、プライマリ データベースよりもわずかに古い可能性がありますが、セカンダリ上のデータはトランザクション上の一貫性が保証されます。 つまり、コミットされていないトランザクションによって行われた変更は表示されません。

Note

アクティブ geo レプリケーションでは、プライマリ レプリカからセカンダリ レプリカにデータベース トランザクション ログをストリーミングすることで、変更がレプリケートされます。 これは、サブスクライバー上でDML (INSERT、UPDATE、DELETE) コマンドを実行して変更をレプリケートするトランザクション レプリケーションとは無関係です。

geo レプリケーションは、リージョンの冗長性を提供します。 Geo レプリケーションで提供されるリージョン間の冗長性のため、自然災害、致命的なヒューマンエラー、または悪意のある行為によって Azure リージョン全体またはリージョンの一部が完全に失われた場合でも、アプリをすばやく復元できます。 Geo レプリケーション RPO については、「ビジネス継続性の概要」を参照してください。

次の図は、プライマリが米国中北部リージョン、geo セカンダリが米国中南部リージョンに構成されたアクティブ geo レプリケーションの例を示しています。

geo-replication relationship

アクティブ geo レプリケーションは、ディザスター リカバリーに加えて次のシナリオで使用できます。

  • データベースの移行: アクティブ geo レプリケーションを使用して、最小限のダウンタイムでデータベースをあるサーバーから別のサーバーに移行できます。
  • アプリケーションのアップグレード: アプリケーションのアップグレード時に、セカンダリをフェールバック コピーとして余分に作成することができます。

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

アクティブ geo レプリケーションの用語と機能

  • 自動非同期レプリケーション

    作成できるのは、既存のデータベースの geo セカンダリのみです。 Geo セカンダリは、プライマリ データベースを持つサーバー以外の任意の論理サーバーに作成できます。 作成されると、geo セカンダリ レプリカにプライマリ データベースのデータが設定されます。 このプロセスはシード処理と呼ばれます。 Geo セカンダリ データベースが作成およびシードされた後、プライマリ データベースの更新が geo セカンダリ データベースに非同期で自動的にレプリケートされます。 非同期レプリケーションとは、トランザクションがレプリケートされる前にプライマリデータベース上でコミットされることを意味します。

  • 読み取り可能なセカンダリ レプリカ

    アプリケーションは、プライマリ データベースへのアクセスに使用されているのと同じ、または異なるセキュリティ プリンシパルを使用して、geo セカンダリ レプリカにアクセスして読み取り専用クエリを実行できます。 詳細については、「読み取り専用レプリカを使用して読み取り専用クエリ ワークロードをオフロードする」を参照してください。

    重要

    Geo レプリケーションを使用して、同じリージョンにプライマリとしてセカンダリレプリカを作成できます。 これらのセカンダリを使用して、同じリージョンの読み取りスケールアウト シナリオを満たします。 ただし、同じリージョン内のセカンダリ レプリカは、致命的な障害や大規模な停止に対する更なる回復力を提供しないため、ディザスター リカバリーの目的に適したフェールオーバー ターゲットではありません。 また、可用性ゾーンの分離も保証されません。 ゾーン冗長の構成で Business Critical または Premium サービス レベルを使用するか、General Purpose サービス レベルのゾーン冗長の構成を使用して、可用性ゾーンの分離を行ってください。

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

    フェールオーバーでは、完全なデータ同期が完了した後、プライマリと geo セカンダリ データベースのロールが切り替わるためデータ損失はありません。 フェールオーバーの期間は、geo セカンダリに同期する必要があるプライマリのトランザクション ログのサイズによって異なります。 フェールオーバーは、次のシナリオ用に設計されています。

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

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

    強制フェールオーバーは、プライマリとの同期を待たずに、geoセカンダリをプライマリの役割に即座に切り替えます。 プライマリにコミットされていても、セカンダリにレプリケートされていないトランザクションは失われます。 この操作は、プライマリにアクセスできない停止時の復元方法として設計されていますが、データベースの可用性を迅速に復元する必要があります。 元のプライマリがオンラインに戻ると、自動的に再接続され、プライマリからの現在のデータを使用して再シードされ、新しいジオ・セカンダリになります。

    重要

    フェールオーバーまたは強制 フェールオーバーの後、新しいプライマリの接続エンドポイントが変更されます。これは、新しいプライマリが別の論理サーバーに位置されているからです。

  • 複数のセカンダリ geo データベース

    プライマリに対して最大 4 つの geo セカンダリを作成できます。 セカンダリが 1 つしか存在しない場合に障害が発生すると、新しいセカンダリ が作成されるまで、アプリケーションは高いリスクにさらされます。 セカンダリ が複数存在する場合、セカンダリ のいずれかに障害が発生しても、アプリケーションは保護された状態が維持されます。 読み取り専用のワークロードをスケール アウトするために、追加のセカンダリを使用することもできます。

    ヒント

    グローバルに分散されたアプリケーションの構築にアクティブ geo レプリケーションを使用し、4 つを超えるリージョンにデータへの読み取り専用アクセスを提供する必要がある場合は、セカンダリのセカンダリ (チェーンと呼ばれるプロセス) を作成し、追加の geo レプリカを作成できます。 チェーンされた geo レプリカでのレプリケーションのラグは、プライマリに直接接続されている geo レプリカよりも高くなる可能性があります。 チェーン geo レプリケーション トポロジの設定は、プログラムによってのみサポートされており、Azure portal からはサポートされていません。

  • エラスティック プール内のデータベースの geo レプリケーション

    セカンダリ データベースは、Single Database またはエラスティック プールのデータベースにできます。 Geo セカンダリ データベースごとにエラスティック プールの選択は独立しており、トポロジ内の他のレプリカ (プライマリまたはセカンダリ) の構成には依存しません。 各エラスティック プールは、1 つの論理サーバー内に含まれます。 論理サーバー上のデータベース名は一意である必要があるため、同じプライマリの複数の geo セカンダリがエラスティック プールを共有できません。

  • ユーザー制御の geo フェールオーバーとフェールバック

    初期シード処理が完了した geo セカンダリは、アプリケーションまたはユーザーがいつでもプライマリ ロールに明示的に切り替え (フェールオーバー) できます。 プライマリにアクセスできない停止中には、強制フェイルオーバーのみを使用することができ、ジオセカンダリを直ちに新しいプライマリに昇格させます。 停止が軽減された場合、システムは自動的に復旧されたプライマリを geo セカンダリにし、新しいプライマリで最新の状態に戻します。 geo レプリケーションの非同期の性質上、これらのトランザクションが geo セカンダリにレプリケートされる前にプライマリが失敗した場合、計画外の 地域フェールオーバー中に最近のトランザクションが失われる可能性があります。 複数の geo セカンダリを持つプライマリがフェールオーバーすると、システムは自動的にレプリケーション関係を再構成して、いかなるユーザー介入も必要とすることなく、残りの geo セカンダリを新しく昇格されたプライマリにリンクします。 geo フェールオーバーの原因となった障害が軽減された後、プライマリを元のリージョンに復帰させることが望ましい場合があります。 そのためには、手動フェールオーバーを実行してください。

  • スタンバイ レプリカ

    セカンダリ レプリカがディザスター リカバリー (DR) にのみ使用され、読み取りまたは書き込みのワークロードがない場合は、レプリカをスタンバイとして指定してライセンス コストを節約できます。

Geo フェールオーバーの準備

geo フェールオーバー後にアプリケーションが新しいプライマリにすぐアクセスできることが確実になるよう、セカンダリ サーバーの認証とネットワークが正しく構成されていることを確認してください。 詳細については、 障害復旧後の SQL Database のセキュリティに関するページを参照してください。 また、セカンダリデータベースのバックアップ保持ポリシーがプライマリのバックアップ保持ポリシーと一致していることを確認します。 この設定はデータベースの一部ではなく、プライマリからはレプリケートされません。 既定では、geo セカンダリは 7 日間の既定の PITR 保持期間で構成されます。 詳細については、「 SQL Database 自動バックアップ」を参照してください。

重要

ご使用のデータベースがフェールオーバー グループのメンバーである場合、geo レプリケーション フェールオーバー コマンドを使用してそのフェールオーバーを開始することはできません。 グループのフェールオーバー コマンドを使用してください。 個々のデータベースをフェールオーバーする必要がある場合、最初にそれをフェールオーバー グループから削除する必要があります。 詳細については、フェールオーバー グループに関する記事をご覧ください。

Geo セカンダリの構成

プライマリと geo セカンダリの両方が同じサービス レベルを持つ必要があります。 また、geoセカンダリは、プライマリと同じバックアップストレージの冗長性、コンピューティングレベル (プロビジョニング済みまたはサーバーレス) 、コンピューティングサイズ (DTUまたは仮想コア) で設定することを強くお勧めします。 プライマリで書き込みワークロードの負荷が高くなっている場合、コンピューティング サイズがより小さな geo セカンダリは維持できない可能性があります。 これにより、geo セカンダリでレプリケーションが発生し、最終的に geo セカンダリが利用できなくなる可能性があります。 このようなリスクを軽減するために、アクティブ geo レプリケーションは、必要に応じてプライマリのトランザクション ログ速度を減少 (スロットル) してセカンダリが追い付けるようにします。

バランスがとれていない geo セカンダリ構成の他の影響として、フェールオーバーの後、新しいプライマリのコンピューティング容量の不足のためにアプリケーションのパフォーマンスが低下する可能性があることが挙げられます。 その場合は、データベースが十分なリソースを確保するために拡張する必要があります。これには膨大な時間がかかる可能性があり、スケールアップ プロセスの最後には高可用性フェールオーバーが必要となり、アプリケーションのワークロードが中断される可能性があります。

別の設定でgeo-secondaryを作成する場合は、プライマリのログIOレートを長期的に監視する必要があります。 これにより、レプリケーションの負荷を維持するために必要な geo セカンダリの最小コンピューティングサイズを見積もることができます。 たとえば、プライマリ データベースが P6 (1000 DTU) で、ログ IO が 50% で維持されている場合、geo セカンダリは P4 (500 DTU) 以上である必要があります。 履歴ログ IO データを取得するには、sys.resource_stats ビューを使用します。 短期間の急増を詳細に反映した最新のログ IO データを取得するには、sys.dm_db_resource_stats ビューを使用します。

ヒント

geo セカンダリのコンピューティング サイズが低いため、プライマリで行われたトランザクション ログ IO のスロットリングは、HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO の待機の種類を使用して報告され、sys.dm_exec_requests および sys.dm_os_wait_stats データベース ビューに表示されます。

プライマリのトランザクション ログ IO は、geo セカンダリのコンピューティング サイズが小さいことに関連しない理由によりスロットルされる可能性があります。 この種類のスロットリングは、geo セカンダリのコンピューティング サイズがプライマリよりも同じかそれ以上である場合にも発生する可能性があります。 さまざまな種類のログ IO スロットリングの待機の種類などの詳細については、「トランザクション ログ速度ガバナンス」を参照してください。

既定では、geo セカンダリのバックアップ ストレージの冗長性は、プライマリ データベースのものと同じです。 別のバックアップ ストレージの冗長性を使用して geo セカンダリを構成することもできます。 バックアップは、常にプライマリ データベースで実行されます。 セカンダリが異なるバックアップ ストレージの冗長性で構成されている場合、geo セカンダリがプライマリに昇格されたときの geo フェールオーバー後に、新しいプライマリ (前のセカンダリ) で選択されたストレージの種類に従って (RA-GRS, ZRS, LRS)、バックアップが保存され、課金されます。

スタンバイ レプリカを使用してコストを節約する

セカンダリ レプリカがディザスター リカバリー (DR) にのみ使用され、読み取りまたは書き込みワークロードがない場合は、新しいアクティブ geo レプリケーションリレーションシップを構成するときにデータベースをスタンバイに指定することで、ライセンス コストを節約できます。

詳細については、ライセンスフリー スタンバイ レプリカに関する説明を参照してください。

サブスクリプション間 geo レプリケーション

Transact-SQL (T-SQL) を使用して、プライマリのサブスクリプションとは異なるサブスクリプションで geo セカンダリを作成します (同じ Microsoft Entra ID (旧称 Azure Active Directory) テナントであるかどうかにかかわらず)。 詳細については、「アクティブ geo レプリケーションの構成」を参照してください。

資格情報とファイアウォール規則の同期を保つ

データベースへの接続にパブリックネットワークアクセスを使用する場合は、geo レプリケートされたデータベースに対してデータベースレベルの IP ファイアウォール規則を使用することをお勧めします。 これらのルールはデータベースと共にレプリケートされます。これにより、すべての geo セカンダリがプライマリと同じ IP ファイアウォールルールを持つようになります。 このアプローチにより、プライマリとセカンダリ データベースをホストするサーバー上で、顧客がファイアウォール規則を手動で構成、管理する必要性がなくなります。 同様に、データアクセスに包含データベースユーザーを使用すると、プライマリデータベースとセカンダリデータベースの両方に同じ認証資格情報が常に割り当てられます。 これにより、geo フェールオーバー後に、認証資格情報の不一致による中断は発生しません。 包含ユーザーではなくログインとユーザーを使用している場合は、追加の手順を実行して、セカンダリ データベースに同じログインが存在することを確認する必要があります。 構成の詳細については、「ログインとユーザーを構成する方法」を参照してください。

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

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

Note

フェールオーバーグループの構成の一部として geo セカンダリを作成した場合は、geo セカンダリをスケールダウンすることは推奨されません。 これは、geo フェールオーバー後の通常のワークロードを処理するのに十分な容量がデータ層にあることを確認するためのものです。

重要

フェールオーバー グループのプライマリ データベースを上位のサービス レベル (エディション) にスケーリングするには、最初にセカンダリ データベースを上位のレベルにスケーリングする必要があります。 たとえば、プライマリを General Purpose から Business Critical にスケールアップする場合は、まず geo セカンダリを Business Critical にスケールアップする必要があります。 この規則に違反する方法でプライマリまたは geo セカンダリをスケーリングしようとすると、次のエラーが表示されます。

The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.

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

ワイドエリアネットワークの待機時間が長いため、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 レプリケーションのラグの監視

RPO に関する遅延を監視するには、プライマリ データベースの sys.dm_geo_replication_link_status の replication_lag_sec 列を使用します。 プライマリでコミットされたトランザクション間の遅延が秒単位で表示され、セカンダリのトランザクションログに書き込まれます。 たとえば、ラグが 1 秒の場合は、プライマリが停止によって影響を受け、geo フェールオーバーが開始されると、最後の 1 秒間にコミットされたトランザクションは失われます。

セカンダリに書き込み済みのプライマリ データベースに対する変更に関する遅延を測定するには、geo セカンダリの last_commit 時間を、プライマリの同じ値と比較します。

ヒント

プライマリの replication_lag_sec が NULL になっていることがありますが、これは、現時点でプライマリと geo セカンダリとの間の遅延時間が不明であることを意味します。 これは、プロセスが再起動した後に発生する一時的な状態であることがほとんどです。 replication_lag_sec から長時間にわたって NULL が返される場合は、アラートを送ることを検討してください。 接続エラーが原因で、geo セカンダリがプライマリと通信できないことを示す場合があります。

Geo セカンダリとプライマリ間の last_commit 時間に大きな差が生じる可能性のある状況は他にもあります。 例えば、長時間変更がなかったプライマリでコミットが行われた場合、差異は非常に大きくなりますが、すぐにゼロに戻ります。 この2つの値の差が長時間続く場合は、アラートを送信することを検討してください。

アクティブ geo レプリケーションのプログラムでの管理

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

単一データベースおよびプールされたデータベースの geo フェールオーバーを管理します。

重要

これらの T-SQL コマンドは、アクティブ geo レプリケーションにのみ適用され、フェールオーバー グループには適用されません。 また、フェールオーバーグループのみをサポートする SQL Managed Instance には適用されません。

コマンド 説明
ALTER DATABASE ADD SECONDARY ON SERVER 引数を使用して、既存のデータベースのセカンダリ データベースを作成し、データ レプリケーションを開始します。
ALTER DATABASE FAILOVER または FORCE_FAILOVER_ALLOW_DATA_LOSS を使用して、セカンダリ データベースをプライマリに切り替え、フェールオーバーを開始します
ALTER DATABASE REMOVE SECONDARY ON SERVER を使用して、SQL Database と指定されたセカンダリ データベース間でのデータ レプリケーションを終了します。
sys.geo_replication_links サーバー上の各データベースの、既存のレプリケーション リンクの情報をすべて返します。
sys.dm_geo_replication_link_status 最新のレプリケーション時刻、最後のレプリケーションの遅延、および指定されたデータベースのレプリケーション リンクに関する他の情報を取得します。
sys.dm_operation_status レプリケーション リンクの変更を含むすべてのデータベース操作の状態が表示されます。
sys.sp_wait_for_database_copy_sync コミットされたすべてのトランザクションが、geo セカンダリのトランザクションログに書き込まれるまで待機します。

単一データベースおよびプールされたデータベースの geo フェールオーバーを管理します。

Note

この記事では、Azure と対話するために推奨される PowerShell モジュールである Azure Az PowerShell モジュールを使用します。 Az PowerShell モジュールの使用を開始するには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

重要

PowerShell Azure Resource Manager モジュールは Azure SQL Database で引き続きサポートされますが、今後の開発はすべて Az.Sql モジュールを対象に行われます。 これらのコマンドレットについては、「AzureRM.Sql」を参照してください。 Az モジュールと AzureRm モジュールのコマンドの引数は実質的に同じです。

コマンドレット 説明
Get-AzSqlDatabase 1 つまたは複数のデータベースを取得します。
New-AzSqlDatabaseSecondary 既存のデータベースのセカンダリ データベースを作成し、データ レプリケーションを開始します。
Set-AzSqlDatabaseSecondary セカンダリ データベースをプライマリに切り替えて、フェールオーバーを開始します。
Remove-AzSqlDatabaseSecondary SQL Database と指定されたセカンダリ データベース間でのデータ レプリケーションを終了します。
Get-AzSqlDatabaseReplicationLink データベースの geo レプリケーションリンクを取得します。

ヒント

サンプル スクリプトについては、アクティブ geo レプリケーションを使用した単一データベースの構成およびフェールオーバーに関するページ、およびアクティブ geo レプリケーションを使用したプールされたデータベースの構成およびフェールオーバーに関するページをご覧ください。

REST API: 単一データベースおよびプールされたデータベースの geo フェールオーバーを管理します。

API 説明
Create または Update Database (createMode=Restore) プライマリまたはセカンダリ データベースを作成、更新、または復元します。
Get Create or Update Database Status 復元操作中にステータスを返します。
Set Secondary Database as Primary (Planned Failover) (セカンダリ データベースをプライマリとして設定する (計画されたフェールオーバー)) 現在のプライマリ データベースからフェールオーバーして、どのセカンダリ データベースがプライマリかを設定します。 このオプションは、SQL Managed Instance ではサポートされていません。
Set Secondary Database as Primary (計画されていないフェールオーバー) 現在のプライマリ データベースからフェールオーバーして、どのセカンダリ データベースがプライマリかを設定します。 この操作を行うとデータが失われる可能性があります。 このオプションは、SQL Managed Instance ではサポートされていません。
Get Replication Link geo レプリケーション パートナーシップで指定されたデータベースの特定のレプリケーション リンクを取得します。 sys.geo_replication_links カタログ ビューで表示可能な情報を取得します。 このオプションは、SQL Managed Instance ではサポートされていません。
Replication Links - List By Database geo レプリケーション パートナーシップで指定されたデータベースのすべてのレプリケーション リンクを取得します。 sys.geo_replication_links カタログ ビューで表示可能な情報を取得します。
Delete Replication Link データベース レプリケーション リンクを削除します。 フェールオーバー中には実行できません。

次のステップ