geo リストアを使用して、データベースのバックアップからマルチテナント SaaS アプリケーションを復旧する
適用対象:
Azure SQL Database
このチュートリアルでは、テナント単位データベース モデルを使用して実装されているマルチテナント SaaS アプリケーションの、完全なディザスター リカバリー シナリオを見ていきます。 自動的に保守されている geo 冗長バックアップのカタログおよびテナント データベースを代替復旧リージョンに復元するには、geo リストアを使用します。 停止が解決したら、geo レプリケーションを使用して、変更されたデータベースを元のリージョンに復帰します。
geo リストアは、Azure SQL Database 向けの最もコストが低いディザスター リカバリー ソリューションです。 ただし、geo 冗長バックアップから復元すると、最大 1 時間のデータ損失が発生する可能性があります。 各データベースのサイズによっては、かなりの時間がかかることがあります。
注意
geo リストアではなく geo レプリケーションを使用して、可能な限り低い RPO と RTO でアプリケーションを復旧します。
このチュートリアルでは、復元ワークフローと復帰ワークフローの両方について説明します。 学習内容は次のとおりです。
- データベースとエラスティック プールの構成情報をテナントのカタログに同期する。
- アプリケーション、サーバー、プールが含まれるミラー イメージ環境を復旧リージョンに設定する。
- geo リストアを使用してカタログおよびテナント データベースを復旧する。
- 停止が解決したら、geo レプリケーションを使用して、テナント カタログと変更されたテナント データベースを復帰する。
- 各データベースが復元 (または復帰) されるときにカタログを更新して、各テナントのデータベースのアクティブなコピーの現在の場所を追跡する。
- 待機時間を減らすため、アプリケーションとテナント データベースが常に同じ Azure リージョンに併置されるようにする。
このチュートリアルを開始する前に、次の前提条件を満たしておいてください。
- Wingtip Tickets SaaS テナント単位データベース アプリをデプロイする。 5 分未満でデプロイするには、Wingtip Tickets SaaS テナント単位データベース アプリケーションのデプロイと探索に関するページを参照してください。
- Azure PowerShell をインストールします。 詳細については、「Azure PowerShell を使ってみる」をご覧ください。
geo リストア復旧パターンの概要
ディザスター リカバリー (DR) は、コンプライアンス上の理由またはビジネス継続性のため、多くのアプリケーションにとって重要な考慮事項です。 長時間にわたるサービス停止が発生しても、適切に準備された DR 計画があればビジネスの中断を最小限にできます。 geo リストアに基づく DR 計画では、いくつかの目標を達成する必要があります。
- テナント データベースの復元に確実に利用できるように、選択した復旧リージョン内に、すべての必要な容量を可能な限り早く確保します。
- 元のプールとデータベースの構成を反映するミラー イメージ復旧環境を確立します。
- 元のリージョンがオンラインに戻った場合に、復元プロセスを途中で取り消すことができるようにします。
- 新しいテナントのオンボードをできるだけ早く再開できるように、テナントのプロビジョニングをすばやく有効にします。
- テナントが優先順位に従って復元されるように最適化します。
- 可能であれば、並列で手順を実行して、できる限り早くテナントがオンラインになるように最適化します。
- 停止に対する回復力があり、再起動可能かつべき等であるようにします。
- 停止が解決したら、テナントに与える影響を最小限に抑えて元のリージョンにデータベースを復帰します。
注意
アプリケーションは、アプリケーションが展開されたリージョンのペア リージョンに復旧されます。 詳細については、「Azure のペアになっているリージョン」をご覧ください。
このチュートリアルでは、Azure SQL Database と Azure プラットフォームの以下の機能を使って、これらの課題に対応します。
- Azure Resource Manager テンプレート。すべての必要な容量を可能な限り早く確保します。 復旧リージョン内に元のサーバーとエラスティック プールのミラー イメージをプロビジョニングするために、Azure Resource Manager テンプレートを使用します。 新しいテナントをプロビジョニングするために、別のサーバーとプールも作成されます。
- Elastic Database Client Library (EDCL)。テナント データベース カタログを作成および保守します。 拡張されたカタログには、定期的に更新されるプールとデータベース構成情報が含まれています。
- EDCL のシャード管理復旧機能。復旧と復帰の間に、カタログに含まれるデータベースの場所エントリを保守します。
- geo リストア。自動的に保守されている geo 冗長バックアップのカタログおよびテナント データベースを復旧します。
- テナントの優先順で送信される非同期の復元操作。プールが過負荷にならないように、システムによってプールごとにキューへ格納され、バッチ処理されます。 これらの操作は、必要に応じて実行前または実行中に取り消すことができます。
- geo レプリケーション。停止の解決後に元のリージョンにデータベースを復帰します。 geo レプリケーションを使用すると、データ損失が発生せず、テナントに与える影響が最小限に抑えられます。
- SQL Server の DNS エイリアス。カタログの場所に関係なく、カタログ同期プロセスがアクティブなカタログに接続できるようにします。
ディザスター リカバリー スクリプトを取得する
このチュートリアルで使用されている DR スクリプトは、Wingtip Tickets SaaS のテナントごとのデータベースの GitHub リポジトリで入手できます。 Wingtip Tickets 管理スクリプトをダウンロードしてブロック解除する手順に関する一般的なガイダンスを参照してください。
重要
すべての Wingtip Tickets 管理スクリプトと同様に、DR スクリプトはサンプル品質なので、運用環境では使わないでください。
アプリケーションの正常性状態を確認する
復旧プロセスを始める前に、アプリケーションの通常の正常な状態を確認します。
Web ブラウザーで、Wingtip Tickets イベント ハブ (http://events.wingtip-dpt.<user>.trafficmanager.net、<user> は実際の展開でのユーザーの値に置き換えます) を開きます。
ページの下部までスクロールし、フッターでカタログ サーバー名と場所を確認します。 場所は、アプリを展開したリージョンです。
ヒント
マウス ポインターをその場所に置くと、ディスプレイが拡大表示されます。
Contoso Concert Hall テナントを選択して、そのイベント ページを開きます。
フッターで、テナントのサーバー名を確認します。 場所は、カタログ サーバーの場所と同じです。
Azure Portal で、アプリが展開されているリソース グループを確認して開きます。
アプリ サービス コンポーネントと SQL Database がデプロイされているリソースとリージョンを確認します。
テナントの構成をカタログに同期する
このタスクでは、サーバー、エラスティック プール、およびデータベースの構成をテナント カタログに同期するプロセスを開始します。 この情報は、復旧リージョンでミラー イメージ環境を構成するために後で使用されます。
重要
わかりやすくするため、これらのサンプルでは、同期プロセスおよびその他の実行時間の長い復旧プロセスと復帰プロセスは、クライアント ユーザーのログインで実行されるローカル PowerShell ジョブまたはセッションとして実装されています。 ログイン時に発行される認証トークンは、数時間で有効期限が切れ、ジョブは失敗するようになります。 運用のシナリオでは、実行時間の長いプロセスは、サービス プリンシパルで実行される、何らかの信頼性の高い Azure サービスとしてを実装する必要があります。 「Azure PowerShell を使用して資格情報でのサービス プリンシパルを作成する」をご覧ください。
PowerShell ISE で、...\Learning Modules\UserConfig.psm1 ファイルを開きます。 10 行目と 11 行目の
<resourcegroup>および<user>は、アプリを展開したときに使った値に置き換えます。 ファイルを保存します。PowerShell ISE で、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 スクリプトを開きます。
このチュートリアルでは、この PowerShell スクリプトの各シナリオを実行するので、このファイルは開いたまましてください。
次のように設定します。
$DemoScenario = 1: テナント サーバーとプールの構成情報をカタログに同期するバックグラウンド ジョブを開始します。
F5 キーを選択して、同期スクリプトを実行します。
この情報は、後で復旧リージョンにサーバー、プール、およびデータベースのミラー イメージを作成するために使用されます。
PowerShell ウィンドウはバックグラウンドで実行させたままにして、チュートリアルの残りの部分を続けます。
注意
同期プロセスは、DNS エイリアスを使ってカタログに接続します。 このエイリアスは、復元および復帰の間に、アクティブなカタログを指すように変更されます。 同期プロセスは、復旧リージョンで行われたデータベースまたはプールの構成の変更を使って、カタログを最新の状態に維持します。 復帰では、これらの変更が元のリージョンの同等のリソースに適用されます。
geo リストア復旧プロセスの概要
geo リストア復旧プロセスでは、アプリケーションを展開し、バックアップのデータベースを復旧リージョンに復元します。
復旧プロセスでは、次の処理が行われます。
元のリージョンで Web アプリの Azure Traffic Manager エンドポイントを無効にします。 エンドポイントを無効にすることで、復旧の間に元のリージョンがオンラインになったときに、ユーザーが無効な状態のアプリに接続するのを防ぎます。
復旧リージョンに復旧カタログ サーバーをプロビジョニングし、カタログ データベースの geo リストアを実行し、復元されたカタログ サーバーを指すように別名 activecatalog を更新します。 カタログの別名を変更すると、カタログ同期プロセスは常にアクティブなカタログに同期されます。
復元する前に、復旧カタログの既存のすべてのテナントをオフラインとマークして、テナント データベースにアクセスできないようにします。
復旧リージョンにアプリのインスタンスをプロビジョニングし、復旧リージョン内の復元されたカタログを使用するように構成します。 待機時間を最小限に抑えるため、サンプル アプリは同じリージョン内のテナント データベースに常に接続するように設計されています。
新しいテナントがプロビジョニングされるサーバーとエラスティック プールをプロビジョニングします。 このようなリソースを作成して、新しいテナントのプロビジョニングが既存のテナントの復旧を妨げないようにします。
復旧リージョン内の新しいテナント データベースのサーバーを指すように、新しいテナントの別名を更新します。 この別名を変更することで、新しいテナントのデータベースが復旧リージョンでプロビジョニングされるようにします。
テナント データベースを復元するために、復旧リージョン内にサーバーとエラスティック プールをプロビジョニングします。 これらのサーバーとプールは、元のリージョン内の構成のミラー イメージです。 プロビジョニング プールは、すべてのデータベースを復元するために必要な容量を事前に確保します。
あるリージョンで停止が発生すると、ペアのリージョンで利用できるリソースに大きな負荷がかかる可能性があります。 DR の geo リストアに依存している場合は、迅速にリソースを確保することをお勧めします。 特定のリージョン内でアプリケーションを復旧することが重要な場合は、geo レプリケーションを検討してください。
復旧リージョンで Web アプリの Traffic Manager エンドポイントを有効にします。 このエンドポイントを有効にすると、アプリケーションは新しいテナントをプロビジョニングできるようになります。 この段階では、既存のテナントはまだオフラインです。
要求のバッチを送信し、優先順位に従ってデータベースを復元します。
バッチは、データベースがすべてのプールに並列に復元されるように編成されています。
復元要求は非同期に送信されるので、すばやく送信され、実行のキューは各プールに格納されます。
復元要求はすべてのプールで並列に処理されるので、重要なテナントを多数のプールに分散する場合に適しています。
サービスを監視して、データベースを復元するタイミングを判断します。 テナント データベースが復元されると、カタログでオンラインとマークされ、テナント データベースの rowversion の合計が記録されます。
テナントがカタログでオンラインとマークされるとすぐに、アプリケーションはテナント データベースにアクセスできるようになります。
テナント データベースでの rowversion 値の合計が、カタログに格納されます。 この合計はフィンガープリントとして機能し、復帰プロセスはこの値を使うことにより、データベースが復旧リージョンで更新されたかどうかを判断できます。
復旧スクリプトを実行する
重要
このチュートリアルでは、geo 冗長バックアップからデータベースを復元します。 geo 冗長バックアップは通常 10 分以内に使用できるようになりますが、最大 1 時間かかる場合があります。 使用できるようになるまで、スクリプトは一時停止されます。
アプリケーションが展開されているリージョンで停止が発生したものと想定して、復旧スクリプトを実行します。
PowerShell ISE で、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 スクリプトに次の値を設定します。
$DemoScenario = 2: geo 冗長バックアップから復元することで、アプリを復旧リージョンに復旧します。
F5 キーを選択して、スクリプトを実行します。
新しい PowerShell ウィンドウでスクリプトが開き、並列に実行される一連の PowerShell ジョブが開始されます。 これらのジョブで、サーバー、プール、およびデータベースが復旧リージョンに復元されます。
復旧リージョンは、アプリケーションを展開した Azure リージョンに関連付けられているペア リージョンです。 詳細については、「Azure のペアになっているリージョン」をご覧ください。
PowerShell ウィンドウで復旧プロセスの状態を監視します。
注意
復旧ジョブのコードを調べるには、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\RecoveryJobs フォルダーにある PowerShell スクリプトを確認します。
復旧中にアプリケーションの状態を確認する
Traffic Manager でアプリケーション エンドポイントが無効になっている間は、アプリケーションを使用できません。 カタログが復元され、すべてのテナントはオフラインとマークされます。 次に復旧リージョン内のアプリケーション エンドポイントが有効になり、アプリケーションはオンラインに戻ります。 アプリケーションは使用できますが、データベースが復元されるまで、イベント ハブ内のテナントはオフラインと表示されます。 オフラインのテナント データベースを処理できるようにアプリケーションを設計することが重要です。
カタログ データベースが復旧された後、テナントがオンラインに戻る前に、Web ブラウザーで Wingtip Tickets イベント ハブを更新します。
フッターで、カタログ サーバー名に -recovery というサフィックスが付いていて、復旧リージョンに存在することを確認します。
まだ復元されていないテナントはオフラインとしてマークされていて、選択できないことを確認します。
テナントがオフラインの間にテナントのイベント ページを直接開いた場合は、テナントがオフラインであることを示す通知が表示されます。 たとえば、Contoso Concert Hall がオフラインのときに、http://events.wingtip-dpt.<ユーザー>.trafficmanager.net/contosoconcerthall を開いてみます。
復旧リージョン内に新しいテナントをプロビジョニングする
テナント データベースが復元される前であっても、復旧リージョン内に新しいテナントをプロビジョニングできます。 復旧リージョン内にプロビジョニングされた新しいテナント データベースは、復旧されたデータベースに後で復帰されます。
PowerShell ISE で、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 スクリプトを開き、次のプロパティを設定します。
$DemoScenario = 3: 復旧リージョンで新しいテナントをプロビジョニングします。
F5 キーを選択して、スクリプトを実行します。
プロビジョニングが終了すると、Hawthorn Hall のイベント ページがブラウザーで開きます。
Hawthorn Hall データベースが復旧リージョン内にあることを確認します。
ブラウザーで、Wingtip Tickets イベント ハブ ページを更新して、Hawthorn Hall が含まれていることを確認します。
他のテナントの復元を待たずに Hawthorn Hall をプロビジョニングした場合、他のテナントはまだオフラインになっている可能性があります。
アプリケーションの復旧された状態を確認する
復旧プロセスが終了すると、アプリケーションとすべてのテナントは、復旧リージョンで完全に機能するようになります。
すべてのテナントが復旧されたことが PowerShell コンソール ウィンドウの表示で示されたら、イベント ハブを更新します。
新しいテナント Hawthorn Hall も含めて、すべてのテナントがオンラインと表示されます。
Contoso Concert Hall をクリックし、イベント ページを開きます。
フッターで、復旧リージョンの復旧サーバー上にデータベースがあることを確認します。
Azure Portal で、リソース グループの一覧を開きます。
展開したリソース グループに加えて、-recovery というサフィックスが付いた復旧リソース グループが表示されることを確認します。 復旧リソース グループには、復旧プロセスの間に作成されたすべてのリソースと、停止中に作成された新しいリソースが含まれます。
復旧リソース グループを開き、次の項目を確認します。
サフィックス -recovery が付いた、catalog サーバーと tenants1 サーバーの復旧バージョン。 これらのサーバー上の復元されたカタログ データベースとテナント データベースはすべて、元のリージョンで使われていた名前のままです。
tenants2-dpt-<ユーザー>-recovery SQL サーバー。 このサーバーは、停止中の新しいテナントのプロビジョニングに使われます。
events-wingtip-dpt-<recoveryregion>-<ユーザー> という名前のアプリ サービス。これは、Events アプリの復旧インスタンスです。
tenants2-dpt-<ユーザー>-recovery SQL サーバーを開きます。 データベース hawthornhall とエラスティック プール Pool1 が含まれることを確認します。 hawthornhall データベースは、Pool1 エラスティック プール内のエラスティック データベースとして構成されています。
テナントのデータを変更する
このタスクでは、復元されたテナント データベースの 1 つを更新します。 復帰プロセスで、変更された復元済みのデータベースが元のリージョンにコピーされます。
ブラウザーで、Contoso Concert Hall のイベント一覧を探し、イベントをスクロールして、最後のイベント Seriously Strauss を確認します。
PowerShell ISE で、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 スクリプトに次の値を設定します。
$DemoScenario = 4: 復旧リージョン内のテナントからイベントを削除します。
F5 キーを選択して、スクリプトを実行します。
Contoso Concert Hall のイベント ページ (http://events.wingtip-dpt.<ユーザー>.trafficmanager.net/contosoconcerthall) を更新し、イベント Seriously Strauss がないことを確認します。
チュートリアルのこの時点で、アプリケーションを復旧し、復旧リージョン内で実行しています。 新しいテナントは復旧リージョン内にプロビジョニングし、復元されたテナントのいずれかのデータを変更しています。
注意
このサンプルの他のチュートリアルは、復旧状態のアプリを使用して実行するように設計されていません。 他のチュートリアルを調べる場合は、まずアプリケーションを復帰してください。
復帰プロセスの概要
復帰プロセスでは、停止が解決した後に、アプリケーションとそのデータベースを元のリージョンに戻します。
このプロセスの内容は次のとおりです。
進行中の復元アクティビティを終了し、未処理または実行中のデータベース復元要求を取り消します。
停止後に変更されていない元のリージョンのテナント データベースを再アクティブ化します。 これらのデータベースには、まだ復旧されていないものと、その後に変更されなかったものが含まれます。 再アクティブ化されたデータベースは、テナントが最後にアクセスしたデータベースとまったく同じです。
新しいテナントのサーバーとエラスティック プールのミラー イメージを元のリージョンにプロビジョニングします。 このアクションが完了すると、このサーバーを指すように新しいテナントの別名が更新されます。 別名を更新すると、復旧リージョンではなく、元のリージョン内で新しいテナントのオンボードが実行されます。
geo レプリケーションを使用して、復旧リージョンから元のリージョンにカタログを移動します。
停止中に復旧リージョンに加えられた変更と一致するように、元のリージョンのプール構成を更新します。
停止中に作成された新しいデータベースをホストするために、必要なサーバーとプールを作成します。
geo レプリケーションを使用して、復元後に更新された復元済みテナント データベースと、停止中にプロビジョニングされたすべての新しいテナント データベースを復帰します。
復元プロセス中に復旧リージョン内に作成されたリソースをクリーンアップします。
復帰する必要のあるテナント データベース数を制限するために、手順 1 から 3 はすぐに実行されます。
手順 4 は、停止中に復旧リージョン内のカタログが変更された場合にのみ実行されます。 新しいテナントが作成された場合、または復旧リージョン内のいずれかのデータベースまたはプール構成が変更された場合、カタログは更新されます。
手順 7 で、テナントの中断を最小限に抑え、データが失われないことが重要です。 この目標を達成するために、このプロセスでは geo レプリケーションを使用します。
各データベースの geo レプリケーションが実行される前に、元のリージョン内の対応するデータベースは削除されます。 削除後に復旧リージョン内のデータベースの geo レプリケーションが実行され、元のリージョン内にセカンダリ レプリカが作成されます。 レプリケーションが完了すると、カタログ内のテナントはオフラインとマークされ、復旧リージョン内のデータベースに対するすべての接続は切断されます。 次にデータベースはフェールオーバーされ、すべての保留中のトランザクションはセカンダリで処理されるので、データは失われません。
フェールオーバー時に、データベース ロールは逆になります。 元のリージョン内のセカンダリはプライマリ読み取り/書き込みデータベースになり、復旧リージョン内のデータベースは読み取り専用のセカンダリになります。 カタログ内のテナント エントリは、元のリージョン内のデータベースを指すように更新され、テナントはオンラインとマークされます。 この時点でデータベースの復帰は完了です。
接続が切断されたときに自動的に再接続するように、再試行ロジックを使用してアプリケーションを作成する必要があります。 接続を仲介するカタログを使用すると、元のリージョン内の復帰したデータベースに接続されます。 通常、この短い切断が認識されることはありませんが、データベースの復帰は勤務時間外に行うのがよいかもしれません。
データベースが復帰したら、復旧リージョン内のセカンダリ データベースを削除できます。 元のリージョン内のデータベースは、DR 保護のために geo リストアに再び依存するようになります。
手順 8 では、復旧サーバーとプールを含む復旧リージョン内のリソースが削除されます。
復帰スクリプトを実行する
停止が解決したものとして、復帰スクリプトを実行します。
このチュートリアルに従っている場合、Fabrikam Jazz Club と Dogwood Dojo は変更されていないため、元のリージョン内ですぐに再アクティブ化されます。 次に、新しいテナントの Hawthorn Hall と、Contoso Concert Hall (変更されているため) が復帰されます。 このスクリプトでは、Hawthorn Hall がプロビジョニングされたときに更新されたカタログも復帰されます。
PowerShell ISE で、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 で、この PowerShell インスタンスでカタログ同期プロセスがまだ実行されていることを確認します。 必要な場合は、次のように設定して再起動します。
$DemoScenario = 1: テナント サーバー、プール、およびデータベースの構成情報のカタログへの同期を開始します。
F5 キーを選択して、スクリプトを実行します。
復帰プロセスを開始するには、次のように設定します。
$DemoScenario = 5: アプリを元のリージョンに復帰します。
F5 キーを選択して、新しい PowerShell ウィンドウで復旧スクリプトを実行します。 復帰には数分かかり、PowerShell ウィンドウで監視できます。
スクリプトが実行されている間に、イベント ハブのページ (http://events.wingtip-dpt.<ユーザー>.trafficmanager.net) を更新します。
すべてのテナントがオンラインであり、このプロセス全体を通じてアクセスできることを確認します。
Fabrikam Jazz Club を選択して開きます。 このテナントを変更しなかった場合は、フッターで、サーバーが元のサーバーに戻っていることを確認します。
Contoso Concert Hall のイベント ページを開くか、更新します。 最初にフッターで、データベースがまだ -recovery サーバー上にあることを確認します。
復帰プロセスが終了したら、Contoso Concert Hall のイベント ページを更新し、データベースが元のリージョン内にあることを確認します。
イベント ハブをもう一度更新し、Hawthorn Hall を開きます。 そのデータベースも元のリージョン内にあることを確認します。
復帰後に復旧リージョンのリソースをクリーンアップする
復帰が完了したら、復旧リージョン内のリソースを削除することができます。
重要
これらのリソースは、関連するすべての課金を止めるためにすぐに削除します。
復元プロセスで、復旧リソース グループ内にすべての復旧リソースが作成されます。 クリーンアップ プロセスで、このリソース グループは削除され、カタログからリソースへのすべての参照が削除されます。
PowerShell ISE で、...\Learning Modules\Business Continuity and Disaster Recovery\DR-RestoreFromBackup\Demo-RestoreFromBackup.ps1 スクリプトに、次のように設定します。
$DemoScenario = 6: 復旧リージョンから、古いリソースを削除します。
F5 キーを選択して、スクリプトを実行します。
スクリプトをクリーンアップすると、アプリケーションは開始された場所に戻ります。 この時点で、スクリプトをもう一度実行するか、他のチュートリアルを試すことができます。
アプリとデータベースが併置されるようにアプリケーションを設計する
このアプリケーションは、テナントのデータベースと同じリージョン内のインスタンスから常に接続するように設計されています。 このように設計すると、アプリケーションとデータベースの間の待機時間が減少します。 この最適化では、データベースとアプリの間の対話の方が、ユーザーとアプリの間の対話より頻繁に行われるものと想定されています。
復帰の過程で、しばらくの間、テナント データベースが復旧リージョンと元のリージョンに分散することがあります。 データベースごとに、アプリはテナント サーバーの名前で DNS 参照を行って、データベースが存在するリージョンを調べます。 サーバー名は別名です。 別名のサーバー名には、リージョンの名前が含まれています。 アプリケーションとデータベースのリージョンが異なる場合、アプリケーションはサーバーと同じリージョン内のインスタンスにリダイレクトします。 データベースと同じリージョン内のインスタンスにリダイレクトすることで、アプリとデータベース間の待機時間を最小限に抑えられます。
次のステップ
このチュートリアルでは、以下の内容を学習しました。
- テナント カタログを使用して定期的に更新された構成情報を保持し、別のリージョン内にミラー イメージの復旧環境を作成できるようにする。
- geo リストアを使用してデータベースを復旧リージョンに復旧する。
- 復元されたテナント データベースの場所を反映するようにテナント カタログを更新する。
- DNS エイリアスを使用して、再構成することなくアプリケーションをテナント カタログに接続できるようにする。
- 停止が解決した後に、geo レプリケーションを使用して、復旧したデータベースを元のリージョンに復帰する。
チュートリアル「データベースの geo レプリケーションを使用したマルチテナント SaaS アプリケーションのディザスター リカバリー」を試して、geo レプリケーションを使用して大規模なマルチテナント アプリケーションを復旧するために必要な時間を大幅に短縮する方法を学んでください。
その他のリソース
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示