概要: フェールオーバー グループとアクティブ geo レプリケーションOverview: Failover groups and active geo-replication

アクティブ geo レプリケーションにより、同じまたは異なるデータ センターの場所 (リージョン) に最大 4 つの読み取り可能なセカンダリ データベースを構成できます。Active geo-replication enables you to configure up to four readable secondary databases in the same or different data center locations (regions). セカンダリ データベースは、データ センターで障害が発生した場合やプライマリ データベースに接続できない場合のクエリとフェールオーバーに使用できます。Secondary databases are available for querying and for failover if there is a data center outage or the inability to connect to the primary database. フェールオーバーはユーザーのアプリケーションによって手動で開始する必要があります。The failover must be initiated manually by the application of the user. フェールオーバー後、新しいプライマリには別の接続エンドポイントが設定されます。After failover, the new primary has a different connection end-point.

注意

全リージョンのすべてのサービス レベルのすべてのデータベースでアクティブ geo レプリケーションを使用できるようになりました。Active geo-replication is available for all databases in all service tiers in all regions.

Azure SQL Database の自動フェールオーバー グループ (プレビュー段階) は、大規模な geo レプリケーションのリレーションシップ、接続、およびフェールオーバーを自動的に管理するように設計された、SQL Database の機能です。Azure SQL Database auto-failover groups (in-preview) is a SQL Database feature designed to automatically manage geo-replication relationship, connectivity, and failover at scale. これにより、ユーザーはプライマリ リージョンで発生した致命的な障害やその他計画外のイベントにより SQL Database サービスの可用性がすべてまたは一部失われたときに、セカンダリ リージョンの複数の関連データベースを自動的に復元できます。With it, the customers gain the ability to automatically recover multiple related databases in the secondary region after catastrophic regional failures or other unplanned events that result in full or partial loss of the SQL Database service’s availability in the primary region. さらに、読み取り可能なセカンダリ データベースを使用して、読み取り専用ワークロードをオフロードできます。Additionally, they can use the readable secondary databases to offload read-only workloads. 自動フェールオーバー グループには複数のデータベースが関与するため、プライマリ サーバーに構成する必要があります。Because auto-failover groups involve multiple databases, they must be configured on the primary server. プライマリとセカンダリの両方のサーバーは、同一のサブスクリプションである必要があります。Both primary and secondary servers must be in the same subscription. 自動フェールオーバー グループでは、グループ内のすべてのデータベースを別のリージョンの 1 つのセカンダリ サーバーにのみレプリケートできます。Auto-failover groups support replication of all databases in the group to only one secondary server in a different region. 自動フェールオーバー グループのないアクティブ geo レプリケーションは、任意のリージョンの最大 4 つのセカンダリを使用できます。Active geo-replication, without auto-failover groups, allows up to four secondaries in any region.

アクティブ geo レプリケーションを使用しており、何らかの理由でプライマリ データベースにエラーが発生したか、単にプライマリ データベースをオフラインにする必要がある場合、任意のセカンダリ データベースでフェールオーバーを開始できます。If you are using active geo-replication and for any reason your primary database fails, or simply needs to be taken offline, you can initiate failover to any of your secondary databases. セカンダリ データベースの 1 つに対してフェールオーバーがアクティブな場合、その他すべてのセカンダリ データベースは新しいプライマリ データベースに自動的にリンクします。When failover is activated to one of the secondary databases, all other secondaries are automatically linked to the new primary. データベースの復旧に自動フェールオーバー グループ (プレビュー段階) を使用しており、グループ内で 1 つ以上のデータベースに影響を及ぼす機能停止が発生すると、自動フェールオーバーが発生します。If you are using auto-failover groups (in-preview) to manage database recovery and any outage that impacts one or several of the databases in the group results in automatic failover. アプリケーションのニーズに最適な自動フェールオーバー ポリシーを構成するか、オプトアウトして手動でのアクティブ化を使用できます。You can configure the auto-failover policy that best meets your application needs, or you can opt out and use manual activation. さらに、自動フェールオーバー グループ (プレビュー段階) には、フェールオーバー中にそのまま残る読み取り/書き込みリスナー エンドポイントと読み取り専用リスナー エンドポイントが用意されています。In addition, auto-failover groups (in-preview) provide read-write and read-only listener end-points that remain unchanged during failovers. 手動または自動フェールオーバーのどちらをアクティブ化するにしても、フェールオーバーはグループ内のすべてのデータベースをプライマリに切り替えます。Whether you use manual or automatic failover activation, failover switches all secondary databases in the group to primary. データベースのフェールオーバーが完了すると、DNS レコードが自動的に更新され、エンドポイントが新しいリージョンにリダイレクトされます。After the database failover is completed, the DNS record is automatically updated to redirect the end-points to the new region.

サーバー上またはエラスティック プール内の個々のデータベースまたはデータベースのセットのレプリケーションとフェールオーバーは、アクティブ geo レプリケーションを使用して管理できます。You can manage replication and failover of an individual database or a set of databases on a server or in an elastic pool using active geo-replication. そのためには以下のものを使うことができます。You can do that using

フェールオーバー後は、サーバーおよびデータベースの認証要件が新しいプライマリで構成されていることを確認してください。After failover, ensure the authentication requirements for your server and database are configured on the new primary. 詳細については、 障害復旧後の SQL Database のセキュリティに関するページを参照してください。For details, see SQL Database security after disaster recovery. これは、アクティブ geo レプリケーションと自動フェールオーバー グループ (プレビュー段階) の両方に該当します。This applies both to active geo-replication and auto-failover groups (in-preview).

アクティブ geo レプリケーションは SQL サーバーの AlwaysOn テクノロジーを活用し、Read Committed スナップショット分離 (RCSI) を使用してプライマリ データベース上のコミットされたトランザクションを非同期的にレプリケートします。Active geo-replication leverages the Always On technology of SQL Server to asynchronously replicate committed transactions on the primary database to a secondary database using read committed snapshot isolation (RCSI). 自動フェールオーバー グループにはアクティブ geo レプリケーションに加えてグループ セマンティックが用意されていますが、同じ非同期レプリケーション メカニズムを使用します。Auto-failover groups provide the group semantics on top of active geo-replication but the same asynchronous replication mechanism is used. 特定の時点におけるセカンダリ データベースは、プライマリ データベースよりもわずかに古い可能性がありますが、セカンダリ データには部分トランザクションが含まれないことが保証されます。While at any given point, the secondary database might be slightly behind the primary database, the secondary data is guaranteed to never have partial transactions. リージョン間で冗長性が確保されるため、自然災害、致命的なヒューマン エラー、または悪意のある行為によってデータセンター全体またはその一部の機能が完全に失われた場合でも、アプリケーションをすばやく復旧できます。Cross-region redundancy enables applications to quickly recover from a permanent loss of an entire datacenter or parts of a datacenter caused by natural disasters, catastrophic human errors, or malicious acts. 特定の RPO データについては、 ビジネス継続性の概要に関するページをご覧ください。The specific RPO data can be found at Overview of Business Continuity.

次の図は、プライマリが米国中北部リージョン、セカンダリが米国中南部リージョンに構成されたアクティブ Geo レプリケーションの例を示しています。The following figure shows an example of active geo-replication configured with a primary in the North Central US region and secondary in the South Central US region.

geo レプリケーションのリレーションシップ

セカンダリ データベースは読み取り可能であるため、ジョブを報告するなどの読み取り専用ワークロードの負荷を軽減するために使用できます。Because the secondary databases are readable, they can be used to offload read-only workloads such as reporting jobs. アクティブ geo レプリケーションを使用している場合、セカンダリ データベースをプライマリと同じリージョンに作成できますが、致命的な障害に対するアプリケーションの復元力は改善されません。If you are using active geo-replication, it is possible to create the secondary database in the same region with the primary, but it does not increase the application's resilience to catastrophic failures. 自動フェールオーバー グループ (プレビュー段階) を使用している場合、セカンダリ データベースは常に異なるリージョンに作成されます。If you are using auto-failover groups (in-preview), your secondary database is always created in a different region.

アクティブ geo レプリケーションは、ディザスター リカバリーに加えて次のシナリオで使用できます。In addition to disaster recovery active geo-replication can be used in the following scenarios:

  • データベースの移行: アクティブ geo レプリケーションを使用して、最小限のダウンタイムでデータベースをあるサーバーから別のサーバーにオンラインで移行できます。Database migration: You can use active geo-replication to migrate a database from one server to another online with minimum downtime.
  • アプリケーションのアップグレード: アプリケーションのアップグレード時に、セカンダリをフェールバック コピーとして余分に作成することができます。Application upgrades: You can create an extra secondary as a fail back copy during application upgrades.

ビジネスの継続性を実現するにあたって、データセンター間のデータベース冗長性を追加することは、ソリューションのほんの一部です。To achieve real business continuity, adding database redundancy between datacenters is only part of the solution. 致命的な障害の後にアプリケーション (サービス) をエンド ツー エンドで復旧するには、そのサービスと依存しているサービスを構成するすべてのコンポーネントを復旧する必要があります。Recovering an application (service) end-to-end after a catastrophic failure requires recovery of all components that constitute the service and any dependent services. このようなコンポーネントの例には、クライアント ソフトウェア (カスタム JavaScript が設定されたブラウザーなど)、Web フロント エンド、ストレージ、DNS などがあります。Examples of these components include the client software (for example, a browser with a custom JavaScript), web front ends, storage, and DNS. すべてのコンポーネントが同じ障害に対する復元性を備えており、アプリケーションの目標復旧時間 (RTO) 以内に利用可能になることが重要です。It is critical that all components are resilient to the same failures and become available within the recovery time objective (RTO) of your application. そのため、依存するサービスをすべて特定し、これらのサービスが提供する保証と機能について把握しておく必要があります。Therefore, you need to identify all dependent services and understand the guarantees and capabilities they provide. そのうえで、依存するサービスのフェールオーバー中もサービスが確実に機能するように対策を講じる必要があります。Then, you must take adequate steps to ensure that your service functions during the failover of the services on which it depends. ディザスター リカバリーのソリューション設計の詳細については、アクティブ geo レプリケーションを使用したディザスター リカバリー用のクラウド ソリューションの設計に関するページを参照してください。For more information about designing solutions for disaster recovery, see Designing Cloud Solutions for Disaster Recovery Using active geo-replication.

アクティブ geo レプリケーションの機能Active geo-replication capabilities

アクティブ geo レプリケーションには、次の重要な機能が用意されています。The active geo-replication feature provides the following essential capabilities:

  • 自動非同期レプリケーション: セカンダリ データベースは、既存のデータベースに追加することによってのみ作成できます。Automatic Asynchronous Replication: You can only create a secondary database by adding to an existing database. セカンダリは任意の Azure SQL Database サーバーに作成できます。The secondary can be created in any Azure SQL Database server. 作成した後、プライマリ データベースからコピーしたデータをセカンダリ データベースに設定できます。Once created, the secondary database is populated with the data copied from the primary database. このプロセスはシード処理と呼ばれます。This process is known as seeding. オンライン セカンダリ データベースが作成およびシードされた後、プライマリ データベースの更新がセカンダリ データベースに非同期で自動的にレプリケートされます。After secondary database has been created and seeded, updates to the primary database are asynchronously replicated to the secondary database automatically. 非同期レプリケーションでは、トランザクションはプライマリ データベースでコミットされた後に、セカンダリ データベースにレプリケートされます。Asynchronous replication means that transactions are committed on the primary database before they are replicated to the secondary database.
  • 読み取り可能なセカンダリ データベース: アプリケーションは、プライマリ データベースへのアクセスに使用されているのと同じ、または異なるセキュリティ プリンシパルを使用して、セカンダリ データベースにアクセスして読み取り専用操作を実行できます。Readable secondary databases: An application can access a secondary database for read-only operations using the same or different security principals used for accessing the primary database. セカンダリ データベースは、セカンダリ上で実行されるクエリによってプライマリ (ログの再生) の更新プログラムのレプリケーションが遅延しないように、スナップショット分離モードで動作します。The secondary databases operate in snapshot isolation mode to ensure replication of the updates of the primary (log replay) is not delayed by queries executed on the secondary.

    注意

    プライマリ データベースでスキーマの更新がある場合、セカンダリ データベースのログ再生は遅延します。The log replay is delayed on the secondary database if there are schema updates on the Primary. 後者の場合は、セカンダリ データベースでスキーマ ロックが必要です。The latter requires a schema lock on the secondary database.

  • 複数の読み取り可能なセカンダリ: 2 つ以上のセカンダリ データベースを使用すると、プライマリ データベースとアプリケーションの冗長性が向上し、保護レベルが強化されます。Multiple readable secondaries: Two or more secondary databases increase redundancy and level of protection for the primary database and application. セカンダリ データベースが複数存在する場合、セカンダリ データベースのいずれかに障害が発生しても、アプリケーションは保護された状態が維持されます。If multiple secondary databases exist, the application remains protected even if one of the secondary databases fails. セカンダリ データベースが 1 つしか存在しない場合に障害が発生すると、新しいセカンダリ データベースが作成されるまで、アプリケーションは高いリスクにさらされます。If there is only one secondary database, and it fails, the application is exposed to higher risk until a new secondary database is created.

    注意

    グローバルに分散されたアプリケーションの構築にアクティブ geo レプリケーションを使用し、4 つを超えるリージョンにデータへの読み取り専用アクセスを提供する必要がある場合は、セカンダリのセカンダリ (チェーンと呼ばれるプロセス) を作成できます。If you are using active geo-replication to build a globally distributed application and need to provide read-only access to data in more than four segions, you can create secondary of a secondary (a process known as chaining). この方法により、データベースのレプリケーションを事実上無制限に拡張できます。This way you can achieve virtually unlimited scale of database replication. さらに、チェーンによりプライマリ データベースからのレプリケーションのオーバーヘッドが軽減されます。In addition, chaining reduces the overhead of replication from the primary database. トレードオフは、リーフの多いセカンダリ データベースでレプリケーションのラグが増えることです。The trade-off is the increased replication lag on the leaf-most secondary databases.

  • エラスティック プール データベースのサポート: エラスティック プールでは、任意のデータベースに対して、アクティブ geo レプリケーションを構成することができます。Support of elastic pool databases: Active geo-replication can be configured for any database in any elastic pool. セカンダリ データベースは、別のエラスティック プールに属していてもかまいません。The secondary database can be in another elastic pool. 通常のデータベースの場合、サービス階層が同じであれば、セカンダリがエラスティック プールになったり、その逆になったりすることができます。For regular databases, the secondary can be an elastic pool and vice versa as long as the service tiers are the same.

  • セカンダリ データベースの構成可能なパフォーマンス レベル: プライマリ データベースとセカンダリ データベースはどちらも、同じサービス レベル (Basic、Standard、Premium) である必要があります。Configurable performance level of the secondary database: Both primary and secondary databases are required to have the same service tier (Basic, Standard, Premium). セカンダリ データベースは、プライマリより低いパフォーマンス レベル (DTU) で作成できます。A secondary database can be created with lower performance level (DTUs) than the primary. このオプションは、データベース書き込みアクティビティが高いアプリケーションにはお勧めできません。レプリケーション遅延が増大する可能性があり、フェールオーバー後に深刻なデータ損失のリスクが高くなるためです。This option is not recommended for applications with high database write activity because the increased replication lag increases the risk of substantial data loss after a failover. さらに、フェールオーバー後に、新しいプライマリがより高いパフォーマンス レベルにアップグレードされるまで、アプリケーションのパフォーマンスに影響が生じます。In addition, after failover the application’s performance is impacted until the new primary is upgraded to a higher performance level. Azure Portal 上のログ IO の割合グラフを使用すると、レプリケーションの負荷を維持するために必要なセカンダリの最小パフォーマンス レベルを適切に見積もることができます。The log IO percentage chart on Azure portal provides a good way to estimate the minimal performance level of the secondary that is required to sustain the replication load. たとえば、プライマリ データベースが P6 (1000 DTU) で、ログ IO の割合が 50% の場合、セカンダリは P4 (500 DTU) 以上である必要があります。For example, if your Primary database is P6 (1000 DTU) and its log IO percent is 50% the secondary needs to be at least P4 (500 DTU). ログ IO データは、sys.resource_stats または sys.dm_db_resource_stats データベース ビューを使用しても取得できます。You can also retrieve the log IO data using sys.resource_stats or sys.dm_db_resource_stats database views. SQL Database のパフォーマンス レベルの詳細については、SQL Database のオプションとパフォーマンスに関するページをご覧ください。For more information on the SQL Database performance levels, see SQL Database options and performance.
  • ユーザー制御のフェールオーバーとフェールバック: アプリケーションまたはユーザーによって、セカンダリ データベースをプライマリ ロールにいつでも明示的に切り替えることができます。User-controlled failover and failback: A secondary database can explicitly be switched to the primary role at any time by the application or the user. 実際のシステム停止時には、"計画されていない" オプションを使用して、セカンダリをプライマリにすぐに昇格させる必要があります。During a real outage the “unplanned” option should be used, which immediately promotes a secondary to be the primary. 障害が発生したプライマリが回復して、再び使用可能になると、回復したプライマリは自動的にセカンダリとしてマークされ、新しいプライマリによって最新の状態になります。When the failed primary recovers and is available again, the system automatically marks the recovered primary as a secondary and bring it up-to-date with the new primary. レプリケーションは非同期であるため、最新の変更をセカンダリにレプリケートする前に、プライマリに障害が発生した場合、計画されていないフェールオーバー時に少量のデータの失われる可能性があります。Due to the asynchronous nature of replication, a small amount of data can be lost during unplanned failovers if a primary fails before it replicates the most recent changes to the secondary. 複数のセカンダリを持つプライマリがフェールオーバーすると、システムは自動的にレプリケーション関係を再構成して、いかなるユーザー介入も必要とすることなく、残りのセカンダリを新しく昇格されたプライマリにリンクします。When a primary with multiple secondaries fails over, the system automatically reconfigures the replication relationships and links the remaining secondaries to the newly promoted primary without requiring any user intervention. フェールオーバーの原因となった障害が解決されたら、アプリケーションをプライマリ リージョンに復帰させることが望ましい場合があります。After the outage that caused the failover is mitigated, it may be desirable to return the application to the primary region. そうするには、"計画" オプションを使用してフェールオーバー コマンドを呼び出す必要があります。To do that, the failover command should be invoked with the “planned” option.
  • 資格情報とファイアウォール規則の同期を保つ: geo レプリケートされたデータベースには、データベースのファイアウォール規則の使用をお勧めします。この規則は、データベースと共にレプリケートされ、すべてのセカンダリ データベースのファイアウォールの規則がプライマリと同じになります。Keeping credentials and firewall rules in sync: We recommend using database firewall rules for geo-replicated databases so these rules can be replicated with the database to ensure all secondary databases have the same firewall rules as the primary. このアプローチにより、プライマリとセカンダリ データベースの両方をホストするサーバー上で、顧客がファイアウォール規則を手動で構成、管理する必要性がなくなります。This approach eliminates the need for customers to manually configure and maintain firewall rules on servers hosting both the primary and secondary databases. 同様に、データのアクセスに包含データベース ユーザーを使用することにより、プライマリとセカンダリの両方のデータベースが、確実かつ常に同じユーザー資格情報を持つようにして、フェールオーバー時に、ログインとパスワードの不一致による中断を防ぐことができます。Similarly, using contained database users for data access ensures both primary and secondary databases always have the same user credentials so during a failover, there is no disruptions due to mismatches with logins and passwords. Azure Active Directory の顧客を追加すると、プライマリおよびセカンダリ データベースへのユーザー アクセスを管理でき、データベース内で資格情報を管理する必要が完全になくなります。With the addition of Azure Active Directory, customers can manage user access to both primary and secondary databases and eliminating the need for managing credentials in databases altogether.

自動フェールオーバー グループの機能Auto-failover group capabilities

自動フェールオーバー グループの機能は、グループ レベルのレプリケーションと自動フェールオーバーをサポートすることで、アクティブ geo レプリケーションの強力な抽象化を提供します。Auto-failover groups feature provides a powerful abstraction of active geo-replication by supporting group level replication and automatic failover. さらに、追加のリスナー エンドポイントを提供することにより、フェールオーバー後に SQL 接続文字列を変更する手間を省きます。In addition, it removes the necessity to change the SQL connection string after failover by providing the additional listener end-points.

  • フェールオーバー グループ: 1 つまたは複数のフェールオーバー グループを異なるリージョンの 2 つのサーバー (プライマリおよびセカンダリ サーバー) 間に作成できます。Failover group: One or many failover groups can be created between two servers in different regions (primary and secondary servers). 各グループには、プライマリ リージョンに発生した機能停止によりすべてまたは一部のプライマリ データベースが使用できなくなった際にユニットとして復元できる、1 つまたは複数のデータベースを含めることができます。Each group can include one or several databases that are recovered as a unit in case all or some primary databases become unavailable due to an outage in the primary region.
  • プライマリ サーバー: フェールオーバー グループのプライマリ データベースのホストとなるサーバー。Primary server: A server that hosts the primary databases in the failover group.
  • セカンダリ サーバー: フェールオーバー グループのセカンダリ データベースのホストとなるサーバー。Secondary server: A server that hosts the secondary databases in the failover group. セカンダリ サーバーをプライマリ サーバーと同じリージョンに配置することはできません。The secondary server cannot be in the same region as the primary server.
  • フェールオーバー グループへのデータベースの追加: 1 つのサーバー内または 1 つのエラスティック プール内の複数のデータベースを同じフェールオーバー グループに置くことができます。Adding databases to failover group: You can put several databases within a server or within an elastic pool into the same failover group. グループにスタンドアロン データベースを追加すると、同じエディションとパフォーマンス レベルを使用してセカンダリ データベースが自動的に作成されます。If you add a standalone database to the group, it automatically creates a secondary database using the same edition and performance level. プライマリ データベースがエラスティック プール内にある場合、セカンダリは同じ名前のエラスティック プールに自動的に作成されます。If the primary database is in an elastic pool, the secondary is automatically created in the elastic pool with the same name. セカンダリ サーバーにセカンダリ データベースが既に存在するデータベースを追加する場合、その geo レプリケーションがグループに継承されます。If you add a database that already has a secondary database in the secondary server, that geo-replication is inherited by the group.

    注意

    フェールオーバー グループの一部でないサーバーにセカンダリ データベースが既に存在するデータベースを追加すると、セカンダリ サーバーに新しいセカンダリが作成されます。When adding a database that already has a secondary database in a server that is not part of the failover group, a new secondary is created in the secondary server.

  • フェールオーバー グループの読み取り/書き込みリスナー: 現在のプライマリ サーバーの URL を示す <failover-group-name>.database.windows.net という形式の DNS の CNAME レコードです。Failover group read-write listener: A DNS CNAME record formed as <failover-group-name>.database.windows.net that points to the current primary server URL. これにより、フェールオーバー後にプライマリが変更されたときに、読み取り/書き込み SQL アプリケーションがプライマリ データベースに透過的に再接続できます。It allows the read-write SQL applications to transparently reconnect to the primary database when the primary changes after failover.

  • フェールオーバー グループの読み取り/書き込みリスナー: セカンダリ サーバーの URL を示す <failover-group-name>.secondary.database.windows.net という形式の DNS の CNAME レコードです。Failover group read-only listener: A DNS CNAME record formed as <failover-group-name>.secondary.database.windows.net that points to the secondary server’s URL. これにより、指定した負荷分散規則を使用して、読み取り専用 SQL アプリケーションがセカンダリ データベースに等価的に接続できます。It allows the read-only SQL applications to transparently connect to the secondary database using the specified load-balancing rules. 必要に応じて、セカンダリ サーバーが利用できないときに、読み取り専用トラフィックをプライマリ サーバーに自動的にリダイレクトするように指定できます。Optionally you can specify if you want the read-only traffic to be automatically redirected to the primary server when the secondary server is not available.
  • 自動フェールオーバー ポリシー: 既定では、フェールオーバー グループは自動フェールオーバー ポリシーを使用して構成されます。Automatic failover policy: By default, the failover group is configured with an automatic failover policy. システムは、エラーが検出されるとすぐにフェールオーバーをトリガーします。The system triggers failover as soon as the failure is detected. アプリケーションからフェールオーバー ワークフローを制御するには、自動フェールオーバーをオフにします。If you want to control the failover workflow from the application, you can turn off automatic failover.
  • 手動フェールオーバー: 自動フェールオーバー構成に関係なくいつでも手動でフェールオーバーを開始することができます。Manual failover: You can initiate failover manually at any time regardless of the automatic failover configuration. 自動フェールオーバー ポリシーが構成されていない場合、フェールオーバー グループ内のデータベースの復元には手動フェールオーバーが必要です。If automatic failover policy is not configured, manual failover is required to recover databases in the failover group. 強制フェールオーバーまたはフレンドリ フェールオーバーを開始できます (データは完全に同期されます)。You can initiate forced or friendly failover (with full data synchronization). 後者は、アクティブ サーバーをプライマリ リージョンに再配置する場合に使用できます。The latter could be used to relocate the active server to the primary region. フェールオーバーが完了すると、正しいサーバーに接続されるように DNS レコードが自動的に更新されます。When failover is completed, the DNS records are automatically updated to ensure connectivity to the correct server.
  • データ消失の猶予期間: プライマリ データベースとセカンダリ データベースは非同期レプリケーションを使用して同期されるため、フェールオーバーによりデータが消失する場合があります。Grace period with data loss: Because the primary and secondary databases are synchronized using asynchronous replication, the failover may result in data loss. アプリケーションのデータ消失の許容範囲を反映するように、自動フェールオーバー ポリシーをカスタマイズできます。You can customize the automatic failover policy to reflect your application’s tolerance to data loss. GracePeriodWithDataLossHours を構成することで、データ消失につながる可能性があるフェールオーバーの開始までにシステムが待機する時間を制御できます。By configuring GracePeriodWithDataLossHours, you can control how long the system waits before initiating the failover that is likely to result data loss.

    注意

    (機能停止がサービス制御面のみに影響するなど) グループ内のデータベースがまだオンラインであることをシステムが検出すると、GracePeriodWithDataLossHours に設定した値に関係なく、フェールオーバーを即時にアクティブ化されてデータが完全に同期されます (フレンドリ フェールオーバー)。When system detects that the databases in the group are still online (for example, the outage only impacted the service control plane), it immediately activates the failover with full data synchronization (friendly failover) regardless of the value set by GracePeriodWithDataLossHours. この動作によって、復元中のデータ消失が確実に防止されます。This behavior ensures that there is no data loss during the recovery. 猶予期間はフレンドリ フェールオーバーが使用できない場合にのみ有効になります。The grace period takes effect only when a friendly failover is not possible. 猶予期間が経過する前に機能停止が対処された場合、フェールオーバーはアクティブ化されません。If the outage is mitigated before the grace period expires, the failover is not activated.

  • 複数のフェールオーバー グループ: サーバーの同じペアに対して複数のフェールオーバー グループを構成して、フェールオーバーのスケールを制御できます。Multiple failover groups: You can configure multiple failover groups for the same pair of servers to control the scale of failovers. 各グループは独立してフェールオーバーします。Each group fails over independently. マルチテナント アプリケーションがエラスティック プールを使用する場合、この機能を使用して各プールのプライマリ データベースとセカンダリ プライマリを混在させることができます。If your multi-tenant application uses elastic pools, you can use this capability to mix primary and secondary databases in each pool. こうすることで、機能停止の影響をテナントの半分に抑えることができます。This way you can reduce the impact of an outage to only half of the tenants.

高可用性サービスを構築するうえでのベスト プラクティスBest practices of building highly available service

Azure SQL データベースを使った高可用性サービスを構築するには、以下のガイドラインに従う必要があります。To build a highly available service that uses Azure SQL database, you should follow these guidelines:

  • フェールオーバー グループの使用: 1 つまたは複数のフェールオーバー グループを異なるリージョンの 2 つのサーバー (プライマリおよびセカンダリ サーバー) 間に作成できます。Use failover group: One or many failover groups can be created between two servers in different regions (primary and secondary servers). 各グループには、プライマリ リージョンに発生した機能停止によりすべてまたは一部のプライマリ データベースが使用できなくなった際にユニットとして復元できる、1 つまたは複数のデータベースを含めることができます。Each group can include one or several databases that are recovered as a unit in case all or some primary databases become unavailable due to an outage in the primary region. フェールオーバー グループは、プライマリと同じサービスの目的を共有する geo セカンダリ データベースを作成します。The failover group creates geo-secondary database with the same service objective as the primary. 既にある geo レプリケーションのリレーションシップをこのフェールオーバー グループに追加する場合は、その geo セカンダリが、プライマリと同じサービス レベル目標で構成されていることを確認してください。If you add an existing geo-replication relationship to the failover group, make sure the geo-secondary is configured with the same service level objective as the primary.
  • OLTP ワークロードに読み取り/書き込みのリスナーを使用する: OLTP 操作を実行するときにサーバーの URL として <failover-group-name>.database.windows.net を使用すると、自動的にプライマリに接続されます。Use read-write listener for OLTP workload: When performing OLTP operations, use <failover-group-name>.database.windows.net as the server URL and the connections are automatically directed to the primary. この URL はフェールオーバー後にも変更されません。This URL does not change after the failover.
    フェールオーバーでは DNS レコードの更新が行われるため、クライアントの接続は、クライアント DNS キャッシュが最新の情報に更新された後にのみ新しいプライマリにリダイレクトされます。Note the failover involves updating the DNS record so the client connections are redirected to the new primary only after the client DNS cache is refreshed.
  • 読み取り専用ワークロードには読み取り専用リスナーを使用する: データがある程度古くても構わない、論理的に分離された読み取り専用ワークロードがある場合、アプリケーションでセカンダリ データベースを使用できます。Use read-only listener for read-only workload: If you have a logically isolated read-only workload that is tolerant to certain staleness of data, you can use the secondary database in the application. 読み取り専用セッションでは、サーバーの URL として <failover-group-name>.secondary.database.windows.net を使用すると、自動的にセカンダリに接続されます。For read-only sessions, use <failover-group-name>.secondary.database.windows.net as the server URL and the connection is automatically directed to the secondary. 接続文字列に ApplicationIntent=ReadOnly を使用して、読み取りの意図を示すこともお勧めします。It is also recommended that you indicate in connection string read intent by using ApplicationIntent=ReadOnly.
  • パフォーマンスの低下に備える: SQL のフェールオーバーの決定は、アプリケーションの他の領域や、使用されている他のサービスとは無関係に行われます。Be prepared for perf degradation: SQL failover decision is independent from the rest of the application or other services used. アプリケーションが、同じリージョン内のコンポーネントや別のリージョン内のコンポーネントと "混在" する場合があります。The application may be “mixed” with some components in one region and some in another. パフォーマンスの低下を防ぐために、DR リージョンでアプリケーションのデプロイを冗長化し、この記事のガイドラインに従うようにしてください。To avoid the degradation, ensure the redundant application deployment in the DR region and follow the guidelines in this article.
    DR リージョン内のアプリケーションで使う接続文字列を変更する必要はありません。Note the application in the DR region does not have to use a different connection string.
  • データの損失に備える: 機能停止が検出された場合、経験的にデータの損失がゼロであれば、読み取り/書き込みのフェールオーバーが SQL によって自動的にトリガーされます。Prepare for data loss: If an outage is detected, SQL automatically triggers read-write failover if there is zero data loss to the best of our knowledge. それ以外の場合、GracePeriodWithDataLossHours に指定された期間、待機状態となります。Otherwise, it waits for the period you specified by GracePeriodWithDataLossHours. GracePeriodWithDataLossHours を指定した場合は、データの損失に備えてください。If you specified GracePeriodWithDataLossHours, be prepared for data loss. 一般に、機能の停止中、Azure では可用性が重視されます。In general, during outages, Azure favors availability. データの損失が許容できない場合は、GracePeriodWithDataLossHours に設定する値を十分大きく確保してください (24 時間など)。If you cannot afford data loss, make sure to set GracePeriodWithDataLossHours to a sufficiently large number, such as 24 hours.

重要

800 以下の DTU と 250 を超えるデータベースを持ち、geo レプリケーションを使用するエラスティック プールでは、計画されたフェールオーバーに時間がかかったりパフォーマンスが低下したりする問題が発生することがあります。Elastic pools with 800 or less DTUs and more than 250 databases using geo-replication may encounter issues including longer planned failovers and degraded performance. こうした問題は、geo レプリケーション エンドポイントが地理的に広く分散している場合や、各データベースで複数のセカンダリ エンドポイントが使用されている場合に、書き込みの負荷が高いワークロードで発生しやすくなります。These issues are more likely to occur for write intensive workloads, when geo-replication endpoints are widely separated by geography, or when multiple secondary endpoints are used for each database. このような症状は、geo レプリケーションのラグが時間の経過と共に増加するときに見られます。Symptoms of these issues are indicated when the geo-replication lag increases over time. このラグは、sys.dm_geo_replication_link_status を使用して監視できます。This lag can be monitored using sys.dm_geo_replication_link_status. この問題が発生する場合は、プール DTU の数を増やしたり、同じプール内で geo レプリケーションされるデータベースの数を減らしたりするなどの緩和策があります。If these issues occur, then mitigations include increasing the number of pool DTUs, or reducing the number of geo-replicated databases in the same pool.

プライマリ データベースのアップグレードまたはダウングレードUpgrading or downgrading a primary database

セカンダリ データベースの接続を解除することなく、プライマリ データベースを (同じサービス レベル内の) 異なるパフォーマンス レベルにアップグレードまたはダウングレードできます。You can upgrade or downgrade a primary database to a different performance level (within the same service tier) without disconnecting any secondary databases. アップグレードの場合は、最初にセカンダリ データベースをアップグレードしてからプライマリをアップグレードすることをお勧めします。When upgrading, we recommend that you upgrade the secondary database first, and then upgrade the primary. ダウングレードは逆の順序で行います。つまり、最初にプライマリをダウングレードしてからセカンダリをダウングレードします。When downgrading, reverse the order: downgrade the primary first, and then downgrade the secondary. データベースを異なるサービス レベルにアップグレードまたはダウングレードすると、この推奨事項が強制されます。When you upgrade or downgrade the database to a different service tier, this recommendation is enforced.

注意

セカンダリ データベースをフェールオーバー グループ構成の一部として作成した場合、セカンダリ データベースをダウングレードすることは推奨されません。If you created secondary database as part of the failover group configuration it is not recommended to downgrade the secondary database. これは、フェールオーバーがアクティブ化された後にデータ層に通常のワークロードを処理するのに十分な容量を確保するためです。This is to ensure your data tier has sufficient capacity to process your regular workload after failover is activated.

重要なデータの損失の防止Preventing the loss of critical data

ワイド エリア ネットワークの遅延は大きいため、連続コピーでは非同期のレプリケーション メカニズムが使用されます。Due to the high latency of wide area networks, continuous copy uses an asynchronous replication mechanism. 非同期レプリケーションでは、障害が発生した場合に部分的なデータ損失が避けられません。Asynchronous replication makes some data loss unavoidable if a failure occurs. しかし、データ損失が許されないアプリケーションもあります。However, some applications may require no data loss. 重要な更新情報を保護するには、アプリケーション開発者は、トランザクションがコミットされた直後に sp_wait_for_database_copy_sync ステム プロシージャを呼び出すことができます。To protect these critical updates, an application developer can call the sp_wait_for_database_copy_sync system procedure immediately after committing the transaction. sp_wait_for_database_copy_sync を呼び出すと、最後にコミットされたトランザクションがセカンダリ データベースに転送されるまで、呼び出しスレッドがブロックされます。Calling sp_wait_for_database_copy_sync blocks the calling thread until the last committed transaction has been transmitted to the secondary database. ただし、転送されたトランザクションがセカンダリで再生およびコミットされるのを待つことはありません。However, it does not wait for the transmitted transactions to be replayed and committed on the secondary. sp_wait_for_database_copy_sync の対象は、特定の連続コピー リンクです。sp_wait_for_database_copy_sync is scoped to a specific continuous copy link. プライマリ データベースへの接続権限を持つユーザーが、このプロシージャを呼び出すことができます。Any user with the connection rights to the primary database can call this procedure.

注意

sp_wait_for_database_copy_sync は、フェールオーバー後のデータの損失を防ぎますが、読み取りアクセスに対して完全な同期を保証することはありません。sp_wait_for_database_copy_sync prevents data loss after failover, but does not guarantee full synchronization for read access. sp_wait_for_database_copy_sync プロシージャ呼び出しによる遅延は、長くなる場合があり、呼び出し時のトランザクション ログのサイズによって異なります。The delay caused by a sp_wait_for_database_copy_sync procedure call can be significant and depends on the size of the transaction log at the time of the call.

フェールオーバー グループおよびアクティブ geo レプリケーションのプログラムでの管理Programmatically managing failover groups and active geo-replication

前に説明したように、自動フェールオーバー グループ (プレビュー段階) とアクティブ geo レプリケーションは、Azure PowerShell および REST API を使用してプログラムによって管理することもできます。As discussed previously, auto-failover groups (in-preview) and active geo-replication can also be managed programmatically using Azure PowerShell and the REST API. 次の表では、使用できるコマンド セットについて説明します。The following tables describe the set of commands available.

Azure Resource Manager API とロール ベース セキュリティ: アクティブ geo レプリケーションには、管理のための Azure Resource Manager API 一式 (Azure SQL Database REST APIAzure PowerShell コマンドレットなど) が含まれています。Azure Resource Manager API and role-based security: Active geo-replication includes a set of Azure Resource Manager APIs for management, including the Azure SQL Database REST API and Azure PowerShell cmdlets. これらの API は、リソース グループの使用を必要とし、ロール ベース セキュリティ (RBAC) をサポートします。These APIs require the use of resource groups and support role-based security (RBAC). アクセス ロールの実装方法の詳細については、Azure のロール ベースのアクセス制御に関するページをご覧ください。For more information on how to implement access roles, see Azure Role-Based Access Control.

Transact-SQL を使用して SQL データベース フェールオーバーを管理するManage SQL database failover using Transact-SQL

コマンドCommand DescriptionDescription
ALTER DATABASE (Azure SQL Database)ALTER DATABASE (Azure SQL Database) ADD SECONDARY ON SERVER 引数を使用して、既存のデータベースのセカンダリ データベースを作成し、データ レプリケーションを開始します。Use ADD SECONDARY ON SERVER argument to create a secondary database for an existing database and starts data replication
ALTER DATABASE (Azure SQL Database)ALTER DATABASE (Azure SQL Database) FAILOVER または FORCE_FAILOVER_ALLOW_DATA_LOSS を使用して、セカンダリ データベースをプライマリに切り替え、フェールオーバーを開始しますUse FAILOVER or FORCE_FAILOVER_ALLOW_DATA_LOSS to switch a secondary database to be primary to initiate failover
ALTER DATABASE (Azure SQL Database)ALTER DATABASE (Azure SQL Database) REMOVE SECONDARY ON SERVER を使用して、SQL Database と指定されたセカンダリ データベース間でのデータ レプリケーションを終了します。Use REMOVE SECONDARY ON SERVER to terminate a data replication between a SQL Database and the specified secondary database.
sys.geo_replication_links (Azure SQL Database)sys.geo_replication_links (Azure SQL Database) Azure SQL Database 論理サーバーにある各データベースの、既存のレプリケーション リンクの情報をすべて返します。Returns information about all existing replication links for each database on the Azure SQL Database logical server.
sys.dm_geo_replication_link_status (Azure SQL Database)sys.dm_geo_replication_link_status (Azure SQL Database) 最新のレプリケーション時刻、最後のレプリケーションの遅延、および指定された SQL データベースのレプリケーション リンクに関する他の情報を取得します。Gets the last replication time, last replication lag, and other information about the replication link for a given SQL database.
sys.dm_operation_status (Azure SQL Database)sys.dm_operation_status (Azure SQL Database) レプリケーション リンクの状態を含むすべてのデータベース操作の状態が表示されます。Shows the status for all database operations including the status of the replication links.
sp_wait_for_database_copy_sync (Azure SQL Database)sp_wait_for_database_copy_sync (Azure SQL Database) コミットされたすべてのトランザクションがレプリケートされ、アクティブ セカンダリ データベースによって認識されるまで、アプリケーションが待機状態になります。causes the application to wait until all committed transactions are replicated and acknowledged by the active secondary database.

PowerShell を使用して SQL データベース フェールオーバーを管理するManage SQL database failover using PowerShell

コマンドレットCmdlet 説明Description
Get-AzureRmSqlDatabaseGet-AzureRmSqlDatabase 1 つまたは複数のデータベースを取得します。Gets one or more databases.
New-AzureRmSqlDatabaseSecondaryNew-AzureRmSqlDatabaseSecondary 既存のデータベースのセカンダリ データベースを作成し、データ レプリケーションを開始します。Creates a secondary database for an existing database and starts data replication.
Set-AzureRmSqlDatabaseSecondarySet-AzureRmSqlDatabaseSecondary セカンダリ データベースをプライマリに切り替えて、フェールオーバーを開始します。Switches a secondary database to be primary to initiate failover.
Remove-AzureRmSqlDatabaseSecondaryRemove-AzureRmSqlDatabaseSecondary SQL Database と指定されたセカンダリ データベース間でのデータ レプリケーションを終了します。Terminates data replication between a SQL Database and the specified secondary database.
Get-AzureRmSqlDatabaseReplicationLinkGet-AzureRmSqlDatabaseReplicationLink Azure SQL Database とリソース グループまたは SQL Server 間の geo レプリケーション リンクを取得します。Gets the geo-replication links between an Azure SQL Database and a resource group or SQL Server.
New-AzureRmSqlDatabaseFailoverGroupNew-AzureRmSqlDatabaseFailoverGroup このコマンドはフェールオーバー グループを作成し、それをプライマリとセカンダリの両方のサーバーに登録します。This command creates a failover group and registers it on both primary and secondary servers
Remove-AzureRmSqlDatabaseFailoverGroupRemove-AzureRmSqlDatabaseFailoverGroup サーバーからフェールオーバー グループを削除し、そのグループが含まれるすべてのセカンダリ データベースを削除します。Removes the failover group from the server and deletes all secondary databases included the group
Get-AzureRmSqlDatabaseFailoverGroupGet-AzureRmSqlDatabaseFailoverGroup フェールオーバー グループ構成を取得します。Retrieves the failover group configuration
Set-AzureRmSqlDatabaseFailoverGroupSet-AzureRmSqlDatabaseFailoverGroup フェールオーバー グループの構成を変更します。Modifies the configuration of the failover group
Switch-AzureRMSqlDatabaseFailoverGroupSwitch-AzureRMSqlDatabaseFailoverGroup フェールオーバー グループのセカンダリ サーバーに対するフェールオーバーをトリガーします。Triggers failover of the failover group to the secondary server

REST API を使用して SQL データベース フェールオーバーを管理するManage SQL database failover using the REST API

APIAPI DescriptionDescription
Create または Update Database (createMode=Restore)Create or Update Database (createMode=Restore) プライマリまたはセカンダリ データベースを作成、更新、または復元します。Creates, updates, or restores a primary or a secondary database.
Get Create or Update Database StatusGet Create or Update Database Status 復元操作中にステータスを返します。Returns the status during a create operation.
Set Secondary Database as Primary (Planned Failover) (セカンダリ データベースをプライマリとして設定する (計画されたフェールオーバー))Set Secondary Database as Primary (Planned Failover) 現在のプライマリ レプリカのデータベースからフェールオーバーして、どのレプリカのデータベースがプライマリかを設定します。Sets which replica database is primary by failing over from the current primary replica database.
Set Secondary Database as Primary (計画されていないフェールオーバー)Set Secondary Database as Primary (Unplanned Failover) 現在のプライマリ レプリカのデータベースからフェールオーバーして、どのレプリカのデータベースがプライマリかを設定します。Sets which replica database is primary by failing over from the current primary replica database. この操作を行うとデータが失われる可能性があります。This operation might result in data loss.
Get Replication LinkGet Replication Link geo レプリケーション パートナーシップで指定された SQL データベースの特定のレプリケーション リンクを取得します。Gets a specific replication link for a given SQL database in a geo-replication partnership. sys.geo_replication_links カタログ ビューで表示可能な情報を取得します。It retrieves the information visible in the sys.geo_replication_links catalog view.
Replication Links - List By DatabaseReplication Links - List By Database geo レプリケーション パートナーシップで指定された SQL データベースのすべてのレプリケーション リンクを取得します。Gets all replication links for a given SQL database in a geo-replication partnership. sys.geo_replication_links カタログ ビューで表示可能な情報を取得します。It retrieves the information visible in the sys.geo_replication_links catalog view.
Delete Replication LinkDelete Replication Link データベース レプリケーション リンクを削除します。Deletes a database replication link. フェールオーバー中には実行できません。Cannot be done during failover.
Create or Update Failover GroupCreate or Update Failover Group フェールオーバー グループを作成または更新しますCreates or updates a failover group
Delete Failover GroupDelete Failover Group フェールオーバー グループをサーバーから削除します。Removes the failover group from the server
Failover (計画されたフェールオーバー)Failover (Planned) 現在のプライマリ サーバーからこのサーバーにフェールオーバーします。Fails over from the current primary server to this server.
Force Failover Allow Data LossForce Failover Allow Data Loss 現在のプライマリ サーバーからこのサーバーにフェールオーバーします。ails over from the current primary server to this server. この操作を行うとデータが失われる可能性があります。This operation might result in data loss.
フェールオーバー グループの取得Get Failover Group フェールオーバー グループを取得します。Gets a failover group.
List Failover Groups By ServerList Failover Groups By Server サーバーにフェールオーバー グループが表示されます。Lists the failover groups in a server.
Update Failover GroupUpdate Failover Group フェールオーバー グループを更新します。Updates a failover group.

次のステップNext steps