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

適用対象:Azure SQL Database

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

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

障害復旧ガイダンス

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

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

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

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

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

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

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

geo リストア

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

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

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

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

接続文字列を更新する

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

ファイアウォール規則を構成する

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

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

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

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

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

監査を有効にする

データベースにアクセスするために監査が必要な場合は、データベースの復旧後に監査を有効にする必要があります。 詳細については、Azure SQL Database の Azure SQL 監査に関するページを参照してください。

次のステップ

• Azure SQL Database の SLA を確認する
• Azure SQL Database 自動バックアップの詳細については、「 SQL Database 自動バックアップ 」を参照してください。
• ビジネス継続性の設計および復旧シナリオについては、 継続性のシナリオ
• 自動バックアップを使用して復旧する方法については、サービス主導のバックアップからのデータベース復元を参照してください。
• アクティブ geo レプリケーションの詳細を確認する
• フェールオーバー グループの詳細を確認します。
• geo リストアについて確認します
• ゾーン冗長データベースの詳細を確認する