次の方法で共有

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

Applies to:Azure SQL Database

この記事では、プライマリ データベースから読み取り可能なセカンダリ データベースにデータを継続的にレプリケートできる、Azure SQL Database のアクティブ geo レプリケーション機能の概要について説明します。 読み取り可能なセカンダリ データベースは、プライマリと同じAzure リージョンにある場合もあれば、より一般的には別のリージョンにある場合もあります。 この種の読み取り可能セカンダリ データベースは、"geo セカンダリ" または "geo レプリカ" と呼ばれることもあります。

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

アクティブ geo レプリケーションを使用して SQL データベースを移行することもできます。

概要

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

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

アクティブ ジオ レプリケーションの図。

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

Geo レプリケーションを管理し、いずれかの方法を使用して Geo フェールオーバーを開始できます。

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

注

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

ジオレプリケーションは、リージョンの冗長性を提供します。 リージョン冗長により、自然災害、致命的な人的エラー、悪意のある行為によって引き起こされる、Azureリージョン全体またはリージョンの一部の永続的な損失からアプリケーションを迅速に復旧できます。 geo レプリケーションの RPO は、Azure SQL Database のビジネス継続性で確認できます。

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

SQL DB geo レプリケーションリレーションシップを示すAzure ポータルのスクリーンショット。

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

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

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

用語と機能

  • 自動非同期レプリケーション: 既存のデータベースの 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ポータルからはサポートされません。

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

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

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

ジオフェイルオーバーの準備

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

重要

ご使用のデータベースがフェールオーバー グループのメンバーである場合、geo レプリケーション フェールオーバー コマンドを使用してそのフェールオーバーを開始することはできません。 グループのフェールオーバー コマンドを使用してください。 個々のデータベースをフェールオーバーする必要がある場合、最初にそれをフェールオーバー グループから削除する必要があります。 Failover グループの概要とベスト プラクティス (Azure SQL Database)。

ジオセカンダリの設定

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

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

ヒント

geo レプリケーションのラグに関する詳細なトラブルシューティング ガイダンスについては、「 geo レプリケーションの再実行ラグのトラブルシューティング」を参照してください。

異なる構成で geo セカンダリを作成する場合は、プライマリのログ I/O レートを時間の経過と共に監視する必要があります。 これにより、レプリケーションの負荷を維持するために必要な geo セカンダリの最小コンピューティングサイズを見積もることができます。 たとえば、プライマリ データベースが P6 (1000 DTU) で、ログ I/O が 50%で維持されている場合、geo セカンダリは少なくとも P4 (500 DTU) である必要があります。 ログ I/O の履歴データを取得するには、 sys.resource_stats ビューを使用します。 短期的なスパイクをより適切に反映する粒度の高い最近のログ I/O データを取得するには、 sys.dm_db_resource_stats ビューを使用します。

ヒント

トランザクション ログのI/O制限は、次のシナリオで発生する可能性があります。

  • geo セカンダリのコンピューティング サイズがプライマリよりも小さい場合。 sys.dm_exec_requestsビューおよびsys.dm_os_wait_statsデータベースビューにて、待機タイプを探します。
  • また、一括挿入、 、インデックス ビルドの負荷の高いワークロードなど、コンピューティング サイズに関係のない理由で調整が発生する場合もあります。 さまざまな種類のログ I/O 制限における待機タイプの詳細については、「トランザクション ログ レート ガバナンス」を参照してください。

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

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

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

詳細については、ライセンスフリースタンバイレプリカを確認してください。

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

  • Azure ポータルを使用すると、両方のサブスクリプションが同じMicrosoft Entra テナント内にある限り、サブスクリプション間でアクティブ geo レプリケーションを設定できます。

    • プライマリが異なる Microsoft Entra テナントにあるサブスクリプションとは別のサブスクリプションで geo セカンダリ レプリカを作成するには、SQL 認証と T-SQL を使用します。 Azure SQL の cross-subscription geo レプリケーションは、Microsoft Entra 認証 を使用する場合、論理サーバーが別の Azure テナントにあるとサポートされません。
    • セットアップや geo フェールオーバーなどのサブスクリプション間 geo レプリケーション操作も、 データベース作成または更新 REST API を使用してサポートされます。

  • Microsoft Entra のみの認証を Azure SQL で有効にしている場合、プライマリまたはセカンダリの論理サーバーでの作成が試行されると、同じまたは異なる Microsoft Entra テナント内の論理サーバー上でのサブスクリプション間の geo セカンダリの作成は、Microsoft Entra ID ユーザーを使用して実行することはサポートされていません。

方法と手順については、「Tutorial: アクティブ geo レプリケーションとフェールオーバーの構成 (Azure SQL Database)を参照してください。

プライベート エンドポイント

プライベート エンドポイント経由でプライマリ サーバーに接続する場合、T-SQL を使用した geo セカンダリの追加はサポートされません。

プライベート エンドポイントが構成されているが、パブリック ネットワーク アクセスが許可される場合、パブリック IP アドレスからプライマリ サーバーに接続するときに geo セカンダリの追加がサポートされます。

geo セカンダリが追加されると、 パブリック ネットワーク アクセスを拒否できます。

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

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

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

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

フェールオーバー グループの詳細については、フェールオーバー グループ内のレプリカのスケールを確認してください。

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

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

注

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

ジオレプリケーションの遅延を監視する

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

プライマリ データベースに適用された変更がジオセカンダリに書き込まれた際の遅延を測定するには、ジオセカンダリの時刻をプライマリの同等の値と比較します。

ヒント

プライマリ上の が されている場合、プライマリは現在、geo セカンダリの背後にある距離を把握していないことを意味します。 これは、プロセスが再起動した後に発生する一時的な状態であることがほとんどです。 対象が長期間同じ値を返す場合は、アラートの送信を検討してください。 接続エラーが原因で、geo セカンダリがプライマリと通信できないことを示す場合があります。

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

プログラムを使ってアクティブ ジオレプリケーションを管理する

アクティブ 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)を参照してください。

重要

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

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

Troubleshooting

ジオレプリケーションの遅延のトラブルシューティングの詳細については、「ジオレプリケーションラグのトラブルシューティング」を参照してください。

関連するコンテンツ

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

その他のビジネス継続性コンテンツ

  • Azure SQL Database
    • フェールオーバー グループ
    • 無料スタンバイ レプリカ
  • ハイパースケール ジオレプリカ
  • Azure SQL Database の自動バックアップ
  • Azure SQL Database
  • Last updated on