Azure SQL Database を復元する、またはセカンダリにフェールオーバーする

Azure SQL Database は、障害から回復するために次の機能を備えています。

ビジネス継続性のシナリオと、こうしたシナリオをサポートする機能の詳細については、 ビジネス継続性に関するページをご覧ください。

障害に備える

アクティブ geo レプリケーションまたは geo 冗長バックアップのいずれかを使用して、他のデータリージョンに適切に復旧するには、必要な場合に備えて、サーバーを、他のデータ センターが停止したときに新しいプライマリ サーバーとして使用できるように準備する必要があります。また、スムーズに復旧できるように、明確に定義された手順を文書化およびテストする必要もあります。 この準備手順を次に示します。

  • 他のリージョンで、新しいプライマリ サーバーとして使用する論理サーバーを特定します。 アクティブ geo レプリケーションを使用する場合、これは少なくとも 1 つで、ほとんどの場合、各セカンダリ サーバーになります。 geo リストアの場合は、通常、データベースが配置されているリージョンの ペア リージョン にあるサーバーです。
  • ユーザーが新しいプライマリ データベースにアクセスするのに必要なサーバー レベルのファイアウォール規則を特定し、必要に応じて定義します。
  • 新しいプライマリ サーバーにユーザーをリダイレクトする方法を決めます。たとえば、接続文字列を変更したり、DNS エントリを変更したりすることでリダイレクトできます。
  • 新しいプライマリ サーバーのマスター データベースに必要なログインを特定し、必要に応じて作成します。また、マスター データベースにあるこれらのログインに、適切なアクセス許可が付与されていることを確認します (ある場合)。 詳細については、障害復旧後の SQL Database のセキュリティに関するページをご覧ください。
  • 更新して新しいプライマリ データベースにマップする必要があるアラート ルールを特定します。
  • 現在のプライマリ データベースで監査の構成を文書化します
  • 障害復旧の訓練を実行します。 geo リストアの障害をシミュレートするには、ソース データベースを削除するか、名前を変更します。これにより、アプリケーションの接続エラーが発生します。 アクティブ geo レプリケーションの障害をシミュレートするには、データベースに接続されている Web アプリケーションまたは仮想マシンを無効にするか、データベースをフェールオーバーして、アプリケーションの接続エラーを発生させます。

復旧を開始するタイミング

復旧操作はアプリケーションに影響します。 SQL 接続文字列の変更または DNS によるリダイレクトが必要で、永続的にデータが失われる可能性があります。 そのため、アプリケーションの目標復旧時間が経過しても、障害が解決されない可能性が高い場合にのみ行ってください。 アプリケーションが実稼働環境にデプロイされている場合は、アプリケーションの健全性の定期的な監視を実行し、次のデータ ポイントを使用して、復旧が保証されていることをアサートします。

  1. 接続の永続的な障害は、アプリケーション層からデータベースに渡ります。
  2. Azure ポータルには、影響が広範囲に及ぶリージョンのインシデントに関するアラートが示されます。
  3. Azure SQL Database サーバーは機能低下としてマークされます。

ダウンタイムに対するアプリケーションの許容度およびビジネス責任に応じて、次の回復オプションを検討することができます。

Get Recoverable Database (LastAvailableBackupDate) を使用して、geo レプリケートされた最新の復元ポイントを取得します。

サービスの回復を待機する

Azure チームはできるだけ早くサービスが利用できるようになるように作業しますが、根本原因によっては数時間から数日かかることがあります。 アプリケーションが長いダウンタイムを許容できる場合は、回復の完了を待つだけで済みます。 この場合、ユーザーによる操作は必要ありません。 現在のサービスの状態は、 Azure サービス正常性ダッシュボードで確認できます。 リージョンの回復後に、アプリケーションの可用性が復元されます。

Geo レプリケートのセカンダリ データベースへのフェールオーバー

アプリケーションのダウンタイムによってビジネス責任が発生する場合は、アプリケーションで geo レプリケートされたデータベースを使用する必要があります。 そうすれば、障害が発生した場合でも異なるリージョンでアプリケーションの可用性を迅速に復元できます。 geo レプリケーションを構成する方法をご覧ください。

データベースの可用性を復元するには、サポートされているいずれかの方法を使用して、geo レプリケートされたセカンダリ データベースへのフェールオーバーを開始する必要があります。

geo レプリケートされたセカンダリ データベースへのフェールオーバーについては、次のいずれかを参照してください。

geo リストアを使用した復旧

アプリケーションのダウンタイムがビジネス責任にならない場合は、アプリケーション データベースを回復する方法として geo リストアを使用できます。 geo リストアは、最新の geo 冗長バックアップからデータベースのコピーを作成します。

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

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

接続文字列を更新する

復旧後のデータベースは別のサーバーに存在するため、そのサーバーを示すようにアプリケーションの接続文字列を更新する必要があります。

接続文字列の変更の詳細については、 接続ライブラリの適切な開発言語を参照してください。

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

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

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

アプリケーションで使用するすべてのログインが、復旧されたデータベースをホストしているサーバー上に存在することを確認する必要があります。 詳細については、 geo レプリケーションのセキュリティ構成に関するページをご覧ください。

メモ

障害復旧の訓練中に、サーバーのファイアウォール規則とログイン (およびそのアクセス許可) を構成してテストする必要があります。 障害の間は、これらのサーバー レベル オブジェクトとその構成を使用できない場合があります。

製品利用統計情報アラートをセットアップする

既存のアラート ルールの設定を更新し、復旧されたデータベースおよび異なるサーバーにマップされるようにする必要があります。

データベースのアラート ルールの詳細については、「アラート通知の受信」および「サービス正常性を追跡する」を参照してください。

監査を有効にする

データベースにアクセスするために監査が必要な場合は、データベースの復旧後に監査を有効にする必要があります。 クライアント アプリケーションで *.database.secure.windows.net パターンのセキュリティで保護された接続文字列を使用している場合は、監査が必要であることを表しています。 詳しくは、「SQL Database の監査」をご覧ください。

次のステップ