Azure SQL データベースのディザスター リカバリー ガイダンス

適用対象: Azure SQL データベース

• Azure SQL Database
• Azure SQL Managed Instance

Azure SQL データベースは、ミッション クリティカルで常に利用できるようになっている必要があるさまざまなアプリケーションをサポートするために、業界トップの 99.99% 以上の高可用性が保証されています。 また、Azure SQL データベースには、リージョンで停止が発生した場合にディザスター リカバリーを迅速に実行するための、ターン キーのビジネス継続性機能を用意する機能も備わっています。 この記事には、アプリケーションのデプロイ前に確認する重要な情報が含まれています。

高可用性を継続的に提供することに努めてはいますが、Azure SQL データベースサービスが停止し、それが原因でデータベースが利用できなくなり、アプリケーションへの影響が出ることがあります。 サービスの監視によって、接続エラー、障害、パフォーマンスの問題を広範囲にわたって引き起こす問題が検出されると、ユーザーに逐次情報を提供するために、サービスで自動的に停止が宣言されます。

サービス停止

Azure SQL データベースサービスが停止した場合は、次の場所でその停止に関連する追加の詳細を確認できます。

• Azure portal のバナー

  サブスクリプションが影響を受けることが確認された場合は、Azure portal の [通知] にサービスに問題があることを知らせる停止アラートが発生します。

  

• [ヘルプとサポート] または [サポートとトラブルシューティング]

  [ヘルプとサポート] または [サポートとトラブルシューティング] からサポート チケットを作成すると、リソースに影響を与える問題に関する情報が表示されます。 影響の詳細と概要を確認するには、[View outage details] (停止の詳細を確認する) を選択します。 アラートは [新しいサポート リクエスト] ページでも確認できます。

  

• サービス正常性

  Azure portal の [サービス正常性] ページでは、Azure データ センターの全体的な状態に関する情報を確認できます。 Azure portal の検索バーで「サービス正常性」と検索し、[有効なイベント] カテゴリの [サービスの問題] を確認します。 また、[ヘルプ] メニューの任意のリソースの [リソース正常性] ページで、個々のリソースの正常性を確認することもできます。 次に示すのは [サービス正常性] ページのサンプル スクリーンショットで、東南アジアでのアクティブなサービスの問題に関する情報が表示されています。

  

• 電子メール通知

  アラートが設定されている場合、サービスの停止によりサブスクリプションとリソースが影響を受けると、azure-noreply@microsoft.com からメール通知が届きます。 メールの本文は一般的に、"アクティビティ ログ アラート ... が Azure サブスクリプション ... のサービスの問題によってトリガーされました" で始まります。 サービス正常性のアラートの詳細については、「Azure portal を使用して Azure サービスの通知でアクティビティ ログ アラートを受け取る」を参照してください。

• 可用性のメトリック

  Azure portal で Azure SQL Database 可用性のメトリックのアラートを監視および構成できます。

停止中にディザスター リカバリーを開始するタイミング

アプリケーション リソースに影響を与えるサービスの停止が発生した場合は、次の一連のアクションを実施することを検討してください。

• Azure チームはできるだけ早くサービスが利用できるようになるように取り組みますが、根本原因によってはしばらくかかることがあります。 長いダウンタイムを許容できるアプリケーションの場合は、回復が完了するのを待つだけで済みます。 この場合、ユーザーによる操作は必要ありません。 [ヘルプ] メニューの任意のリソースの [リソース正常性] ページで、個々のリソースの正常性を確認します。 停止に関する更新情報と最新情報については、[リソース正常性] ページを参照してください。 リージョンの回復後に、アプリケーションの可用性が復元されます。

• 別の Azure リージョンへの復旧には、アプリケーション接続文字列の変更や DNS リダイレクトの使用が必要になる可能性があり、永続的なデータ損失が発生する場合があります。 したがって、ディザスター リカバリーは、停止期間がアプリケーションの目標復旧時間 (RTO) に迫っている場合にのみ実行してください。 アプリケーションを運用環境にデプロイする際には、アプリケーションの正常性を定期的に監視し、アプリケーション層からデータベースへの接続エラーが長引いている場合にのみ復旧が保証されることを表明する必要があります。 ダウンタイムに対するアプリケーションの許容度とビジネス上の責任に応じて、サービスが復旧するまで待つか、ディザスター リカバリーを開始するかどうかを自分で決めることができます。

障害復旧ガイダンス

あるリージョンの Azure SQL データベースの停止が長期間にわたって対処されておらず、アプリケーションのサービス レベル アグリーメント (SLA) に影響が出ている場合は、次の手順を検討してください。

geo レプリケーションされたセカンダリ サーバーへのフェールオーバー (データ損失なし)

アクティブ geo レプリケーションまたはフェールオーバー グループが有効になっている場合は、Azure portal でプライマリ データベースとセカンダリ データベースのリソースの状態がオンラインになっていることを確認します。 その場合、プライマリ データベースとセカンダリ データベースの両方のデータ プレーンは正常です。 Azure portal、T-SQL、PowerShell、または Azure CLI を使用して、アクティブ geo レプリケーションまたはフェールオーバー グループのセカンダリ リージョンへのフェールオーバーを開始します。

注意

フェールオーバーでは、ロールを切り替える前に完全なデータ同期が必要であり、データが失われることはありません。 サービスの停止の種類によっては、データが失われないフェールオーバーが成功するという保証はありませんが、最初の復旧オプションとして試してみる価値はあります。

フェールオーバーを開始するには、次のリンクを使用します。

テクノロジ	方法	手順
アクティブ geo レプリケーション	PowerShell	PowerShell を使用した geo レプリケーション セカンダリへのフェールオーバー
	T-SQL	T-SQL を使用した geo レプリケーション セカンダリへのフェールオーバー
フェールオーバー グループ	Azure CLI	Azure CLI を使用したセカンダリ サーバーへのフェールオーバー
	Azure portal	Azure portal を使用したセカンダリ サーバーへのフェールオーバー
	PowerShell	PowerShell を使用したセカンダリ サーバーへのフェールオーバー

geo レプリケーションされたセカンダリ サーバーへの強制フェールオーバー (データ損失が発生する可能性あり)

フェールオーバーが円滑に完了せずにエラーが発生するか、プライマリ データベースのステータスがオンラインでない場合、セカンダリ リージョンへのデータ損失の可能性を伴う強制フェールオーバーを慎重に検討してください。

強制的なフェールオーバーを開始するには、次のリンクを使用します。

テクノロジ	方法	手順
アクティブ geo レプリケーション	Azure CLI	Azure CLI を使用した geo レプリケーション セカンダリへの強制フェールオーバー
	Azure portal	Azure ポータル経由での geo レプリケーション セカンダリーへの強制フェールオーバー
	PowerShell	PowerShell を使用した geo レプリケーション セカンダリへの強制フェールオーバー
	T-SQL	T-SQL を使用した geo レプリケーション セカンダリへの強制フェールオーバー
フェールオーバー グループ	Azure portal	Azure portal 経由でセカンダリ サーバーに強制フェールオーバー しますが、[強制フェールオーバー] を選択します。
	Azure CLI	Azure CLI を使用したセカンダリ サーバーへの強制フェールオーバー (ただし --allow-data-loss を使用する)
	PowerShell	PowerShell を使用したセカンダリ サーバーへの強制フェールオーバー (ただし -AllowDataLoss を使用する)

geo リストア

アクティブ geo レプリケーションもフェールオーバー グループも有効にしていない場合は、最後の手段として geo リストアを使用して停止から復旧できます。 geo リストアには、geo レプリケートされたバックアップがソースとして使われます。 geo レプリケートされた最新のバックアップから任意の Azure リージョン内の任意の論理サーバーでデータベースを復元することができます。 障害によってデータベースまたは全体のリージョンデータセンターにアクセスできない場合でも、geo リストアを要求できます。

Azure CLI、Azure portal、PowerShell、または REST API による geo リストアの詳細については、Azure SQL データベースの geo リストアを参照してください。

復旧後のデータベースの構成

geo フェールオーバーまたは geo リストアを使用して停止から復旧する場合は、通常のアプリケーション機能を再開できるように新しいデータベースへの接続が正しく構成されていることを確認する必要があります。 復旧後のデータベースをすぐ運用できるようにするためのタスクのチェックリストを次に示します。

重要

ディザスター リカバリー戦略の定期的な訓練を実施して、アプリケーションの許容度と、復旧手順のすべての運用面を確認することをお勧めします。 アプリケーション インフラストラクチャの他のレイヤーでは、再構成が必要になる場合があります。 回復性があるアーキテクチャの手順の詳細については、「Azure SQL Database の高可用性とディザスター リカバリーのチェックリスト」を参照してください。

接続文字列を更新する

• アクティブ geo レプリケーションまたは geo リストアを使用する場合は、通常のアプリケーション機能を再開できるように新しいデータベースへの接続が正しく構成されていることを確認する必要があります。 復旧後のデータベースは別のサーバーに存在するため、そのサーバーを示すようにアプリケーションの接続文字列を更新する必要があります。 接続文字列の変更の詳細については、 接続ライブラリの適切な開発言語を参照してください。
• フェールオーバー グループを使用して停止から復旧し、アプリケーション接続文字列で読み取り/書き込みリスナーと読み取り専用リスナーを使用している場合、接続は新しいプライマリに自動的にリダイレクトされるため、それ以上の操作は必要ありません。

ファイアウォール規則の構成

セカンダリ サーバーおよびデータベースで構成されているファイアウォール規則が、プライマリ サーバーとプライマリ データベースで構成されているものと一致することを確認する必要があります。 詳細については、「ファイアウォール設定の構成方法」をご覧ください。

ログインとデータベース ユーザーを構成する

新しいプライマリ サーバーの master データベースに必要なログインを作成します。また、master データベースにあるこれらのログインに、適切なアクセス許可が付与されていることを確認します (ある場合)。 詳細については、「障害復旧後のセキュリティ」をご覧ください。

テレメトリ アラートを設定する

既存のアラート ルールの設定を更新し、新しいプライマリ データベースおよび異なるサーバーにマップされるようにする必要があります。 データベースのアラート ルールの詳細については、「アラート通知の受信」および「サービス正常性を追跡する」を参照してください。

監査を有効にする

プライマリ サーバーで監査が構成されている場合は、セカンダリ サーバーで同じものを適用します。 詳細については、監査に関するページを参照してください。

関連するコンテンツ

詳細については、次を参照してください。

• 継続性のシナリオ。
• 自動バックアップ
• サービスによって開始されたバックアップからデータベースを復元します。
• より迅速な復旧オプションについては、アクティブ geo レプリケーションとフェールオーバー グループに関する記事を参照してください。
• 「ディザスター リカバリー ガイダンス」と「高可用性とディザスター リカバリーのチェックリスト」をご覧ください。