Azure SQL Database を復元する、またはセカンダリにフェールオーバーするRestore an Azure SQL Database or failover to a secondary

Azure SQL Database は、障害から回復するために次の機能を備えています。Azure SQL Database offers the following capabilities for recovering from an outage:

ビジネス継続性のシナリオと、こうしたシナリオをサポートする機能の詳細については、 ビジネス継続性に関するページをご覧ください。To learn about business continuity scenarios and the features supporting these scenarios, see Business continuity.

障害に備えるPrepare for the event of an outage

アクティブ geo レプリケーションまたは geo 冗長バックアップのいずれかを使用して、他のデータ リージョンに適切に復旧するには、必要な場合に備えて、サーバーを、他のデータ センターが停止したときに新しいプライマリ サーバーとして使用できるように準備する必要があります。また、スムーズに復旧できるように、明確に定義された手順を文書化およびテストする必要もあります。For success with recovery to another data region using either active geo-replication or geo-redundant backups, you need to prepare a server in another data center outage to become the new primary server should the need arise as well as have well-defined steps documented and tested to ensure a smooth recovery. この準備手順を次に示します。These preparation steps include:

  • 他のリージョンで、新しいプライマリ サーバーとして使用する論理サーバーを特定します。Identify the logical server in another region to become the new primary server. アクティブ geo レプリケーションを使用する場合、これは少なくとも 1 台のサーバーであり、ほとんどの場合はセカンダリ サーバーになります。With active geo-replication, this will be at least one and perhaps each of the secondary servers. geo リストアの場合は、通常、データベースが配置されているリージョンの ペア リージョン にあるサーバーです。For geo-restore, this will generally be a server in the paired region for the region in which your database is located.
  • ユーザーが新しいプライマリ データベースにアクセスするのに必要なサーバー レベルのファイアウォール規則を特定し、必要に応じて定義します。Identify, and optionally define, the server-level firewall rules needed on for users to access the new primary database.
  • 新しいプライマリ サーバーにユーザーをリダイレクトする方法を決めます。たとえば、接続文字列を変更したり、DNS エントリを変更したりすることでリダイレクトできます。Determine how you are going to redirect users to the new primary server, such as by changing connection strings or by changing DNS entries.
  • 新しいプライマリ サーバーのマスター データベースに必要なログインを特定し、必要に応じて作成します。また、マスター データベースにあるこれらのログインに、適切なアクセス許可が付与されていることを確認します (ある場合)。Identify, and optionally create, the logins that must be present in the master database on the new primary server, and ensure these logins have appropriate permissions in the master database, if any. 詳細については、障害復旧後の SQL Database のセキュリティに関するページをご覧ください。For more information, see SQL Database security after disaster recovery
  • 更新して新しいプライマリ データベースにマップする必要があるアラート ルールを特定します。Identify alert rules that will need to be updated to map to the new primary database.
  • 現在のプライマリ データベースで監査の構成を文書化しますDocument the auditing configuration on the current primary database
  • 障害復旧の訓練を実行します。Perform a disaster recovery drill. geo リストアの障害をシミュレートするには、ソース データベースを削除するか、名前を変更します。これにより、アプリケーションの接続エラーが発生します。To simulate an outage for geo-restore, you can delete or rename the source database to cause application connectivity failure. アクティブ geo レプリケーションの障害をシミュレートするには、データベースに接続されている Web アプリケーションまたは仮想マシンを無効にするか、データベースをフェールオーバーして、アプリケーションの接続エラーを発生させます。To simulate an outage for active geo-replication, you can disable the web application or virtual machine connected to the database or failover the database to cause application connectivity failures.

復旧を開始するタイミングWhen to initiate recovery

復旧操作はアプリケーションに影響します。The recovery operation impacts the application. SQL 接続文字列の変更または DNS によるリダイレクトが必要で、永続的にデータが失われる可能性があります。It requires changing the SQL connection string or redirection using DNS and could result in permanent data loss. そのため、アプリケーションの目標復旧時間が経過しても、障害が解決されない可能性が高い場合にのみ行ってください。Therefore, it should be done only when the outage is likely to last longer than your application's recovery time objective. アプリケーションが実稼働環境にデプロイされている場合は、アプリケーションの健全性の定期的な監視を実行し、次のデータ ポイントを使用して、復旧が保証されていることをアサートします。When the application is deployed to production you should perform regular monitoring of the application health and use the following data points to assert that the recovery is warranted:

  1. 接続の永続的な障害は、アプリケーション層からデータベースに渡ります。Permanent connectivity failure from the application tier to the database.
  2. Azure ポータルには、影響が広範囲に及ぶリージョンのインシデントに関するアラートが示されます。The Azure portal shows an alert about an incident in the region with broad impact.
  3. Azure SQL Database サーバーは機能低下としてマークされます。The Azure SQL Database server is marked as degraded.

ダウンタイムに対するアプリケーションの許容度およびビジネス責任に応じて、次の回復オプションを検討することができます。Depending on your application tolerance to downtime and possible business liability you can consider the following recovery options.

Get Recoverable Database (LastAvailableBackupDate) を使用して、geo レプリケートされた最新の復元ポイントを取得します。Use the Get Recoverable Database (LastAvailableBackupDate) to get the latest Geo-replicated restore point.

サービスの回復を待機するWait for service recovery

Azure チームはできるだけ早くサービスが利用できるようになるように作業しますが、根本原因によっては数時間から数日かかることがあります。The Azure teams work diligently to restore service availability as quickly as possible but depending on the root cause it can take hours or days. アプリケーションが長いダウンタイムを許容できる場合は、回復の完了を待つだけで済みます。If your application can tolerate significant downtime you can simply wait for the recovery to complete. この場合、ユーザーによる操作は必要ありません。In this case, no action on your part is required. 現在のサービスの状態は、 Azure サービス正常性ダッシュボードで確認できます。You can see the current service status on our Azure Service Health Dashboard. リージョンの回復後に、アプリケーションの可用性が復元されます。After the recovery of the region your application’s availability will be restored.

Geo レプリケートのセカンダリ データベースにフェールオーバーするFail over to geo-replicated secondary database

アプリケーションのダウンタイムによってビジネス責任が発生する場合は、アプリケーションで geo レプリケートされたデータベースを使用する必要があります。If your application’s downtime can result in business liability you should be using geo-replicated database(s) in your application. そうすれば、障害が発生した場合でも異なるリージョンでアプリケーションの可用性を迅速に復元できます。It will enable the application to quickly restore availability in a different region in case of an outage. geo レプリケーションを構成する方法をご覧ください。Learn how to configure geo-replication.

データベースの可用性を復元するには、サポートされているいずれかの方法を使用して、geo レプリケートされたセカンダリ データベースへのフェールオーバーを開始する必要があります。To restore availability of the database(s) you need to initiate the failover to the geo-replicated secondary using one of the supported methods.

geo レプリケートされたセカンダリ データベースへのフェールオーバーについては、次のいずれかを参照してください。Use one of the following guides to fail over to a geo-replicated secondary database:

geo リストアを使用した復旧Recover using geo-restore

アプリケーションのダウンタイムがビジネス責任にならない場合は、アプリケーション データベースを回復する方法として geo リストアを使用できます。If your application’s downtime does not result in business liability you can use geo-restore as a method to recover your application database(s). geo リストアは、最新の geo 冗長バックアップからデータベースのコピーを作成します。It creates a copy of the database from its latest geo-redundant backup.

復旧後のデータベースの構成Configure your database after recovery

geo レプリケーション フェールオーバーまたは geo リストアを使用して障害から復旧する場合は、通常のアプリケーション機能を再開できるように新しいデータベースへの接続が正しく構成されていることを確認する必要があります。If you are using either geo-replication failover or geo-restore to recover from an outage, you must make sure that the connectivity to the new databases is properly configured so that the normal application function can be resumed. 復旧後のデータベースをすぐ運用できるようにするためのタスクのチェックリストを次に示します。This is a checklist of tasks to get your recovered database production ready.

接続文字列を更新するUpdate connection strings

復旧後のデータベースは別のサーバーに存在するため、そのサーバーを示すようにアプリケーションの接続文字列を更新する必要があります。Because your recovered database will reside in a different server, you need to update your application’s connection string to point to that server.

接続文字列の変更の詳細については、 接続ライブラリの適切な開発言語を参照してください。For more information about changing connection strings, see the appropriate development language for your connection library.

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

サーバーおよびデータベースで構成されているファイアウォール規則が、プライマリ サーバーとプライマリ データベースで構成されている規則と一致することを確認する必要があります。You need to make sure that the firewall rules configured on server and on the database match those that were configured on the primary server and primary database. 詳細については、「 方法: ファイアウォール設定を構成する (Azure SQL Database)」を参照してください。For more information, see How to: Configure Firewall Settings (Azure SQL Database).

ログインとデータベース ユーザーを構成するConfigure logins and database users

アプリケーションで使用するすべてのログインが、復旧されたデータベースをホストしているサーバー上に存在することを確認する必要があります。You need to make sure that all the logins used by your application exist on the server which is hosting your recovered database. 詳細については、geo レプリケーションのセキュリティ構成に関するページをご覧ください。For more information, see Security Configuration for geo-replication.

注意

障害復旧の訓練中に、サーバーのファイアウォール規則とログイン (およびそのアクセス許可) を構成してテストする必要があります。You should configure and test your server firewall rules and logins (and their permissions) during a disaster recovery drill. 障害の間は、これらのサーバー レベル オブジェクトとその構成を使用できない場合があります。These server-level objects and their configuration may not be available during the outage.

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

既存のアラート ルールの設定を更新し、復旧されたデータベースおよび異なるサーバーにマップされるようにする必要があります。You need to make sure your existing alert rule settings are updated to map to the recovered database and the different server.

データベースのアラート ルールの詳細については、「アラート通知の受信」および「サービス正常性を追跡する」を参照してください。For more information about database alert rules, see Receive Alert Notifications and Track Service Health.

監査を有効にするEnable auditing

データベースにアクセスするために監査が必要な場合は、データベースの復旧後に監査を有効にする必要があります。If auditing is required to access your database, you need to enable Auditing after the database recovery. 詳しくは、「SQL Database の監査」をご覧ください。For more information, see Database auditing.

次のステップNext steps