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

Azure SQL Database の機能であるアクティブ geo レプリケーションを使用すると、同じデータ センターまたは異なるデータ センター (リージョン) に、データベースの読み取り可能レプリカを作成することができます。Active geo-replication is Azure SQL Database feature that allows you to create readable replicas of your database in the same or different data center (region).

geo レプリケーション

アクティブ geo レプリケーションは、データ センター規模の機能停止が発生した場合にディザスター リカバリーをアプリケーションで迅速に実行できるようするためのビジネス継続性ソリューションとして設計されています。Active geo-replication is designed as a business continuity solution that allows the application to perform quick disaster recovery in case of a data center scale outage. geo レプリケーションを有効にすると、アプリケーションは別の Azure リージョンにあるセカンダリ データベースへのフェールオーバーを開始できます。If geo-replication is enabled, the application can initiate failover to a secondary database in a different Azure region. 同じリージョン内または異なるリージョン内で最大 4 つのセカンダリがサポートされています。また、セカンダリを使用して読み取り専用アクセスのクエリを行うこともできます。Up to four secondaries are supported in the same or different regions, and the secondaries can also be used for read-only access queries. フェールオーバーはアプリケーションまたはユーザーによって手動で開始される必要があります。The failover must be initiated manually by the application or 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. アクティブ geo レプリケーションは、Managed Instance では利用できません。Active Geo-replication is not available in Managed Instance.

自動フェールオーバー グループは、アクティブ geo レプリケーションの拡張機能です。Auto-failover groups is an extension of active geo-replication. これは、複数の geo レプリケーション データベースのフェールオーバーを同時に管理するように設計されたものであり、アプリケーションによって開始されるフェールオーバーを使用するか、またはユーザー定義の条件に基づいて SQL Database サービスが実行されるようにフェールオーバーを委任します。It is designed to manage the failover of multiple geo-replicated databases simultaneously using an application initiated failover or by delegating failover to be done by the SQL Database service based on a user defined criteria. 後者の場合、ユーザーはプライマリ リージョンで発生した致命的な障害やその他計画外のイベントにより SQL Database サービスの可用性がすべてまたは一部失われたときに、セカンダリ リージョンの複数の関連データベースを自動的に復元できます。The latter allows you to automatically recover multiple related databases in a secondary region after a catastrophic failure or other unplanned event that results in full or partial loss of the SQL Database service’s availability in the primary region. さらに、読み取り可能なセカンダリ データベースを使用して、読み取り専用クエリ ワークロードをオフロードできます。Additionally, you can use the readable secondary databases to offload read-only query workloads. 自動フェールオーバー グループには複数のデータベースが関与するため、これらのデータベースをプライマリ サーバーに構成する必要があります。Because auto-failover groups involve multiple databases, these databases must be configured on the primary server. フェールオーバー グループ内にあるデータベース用のプライマリ サーバーとセカンダリ サーバーは両方とも、同一のサブスクリプションである必要があります。Both primary and secondary servers for the databases in the failover group 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 レプリケーションを使用します。Use active geo-replication if multiple secondaries are required.

アクティブ 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 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 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.

アクティブ geo レプリケーションは SQL Server の Always On テクノロジーを活用し、スナップショット分離を使用してプライマリ データベース上のコミットされたトランザクションを非同期的にレプリケートします。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 snapshot isolation. 自動フェールオーバー グループにはアクティブ 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, 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.

  • 複数のセカンダリ データベースMultiple readable secondaries

    2 つ以上のセカンダリ データベースを使用すると、プライマリ データベースとアプリケーションの冗長性が向上し、保護レベルが強化されます。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 regions, 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.

  • エラスティック プール データベースのサポートSupport of elastic pool databases

    各レプリカは、個別にエラスティック プールに参加しても、どのエラスティック プールにもまったく参加しなくてもかまいません。Each replica can separately participate in an Elastic Pool or not be in any elastic pool at all. レプリカごとのプールの選択は独立しており、他のレプリカの構成には依存しません (プライマリでもセカンダリでも)。The pool choice for each replica is separate and does not depend upon the configuration of any other replica (whether Primary or Secondary). 各エラスティック プールは 1 つのリージョンにのみ含まれるので、同じトポロジ内の複数のレプリカがエラスティック プールを共有することはできません。Each Elastic Pool is contained within a single region, therefore multiple replicas in the same topology can never share an Elastic Pool.

  • セカンダリ データベースの構成可能なコンピューティング サイズConfigurable compute size of the secondary database

    プライマリとセカンダリ、両方のデータベースが同じサービス階層を持つ必要があります。Both primary and secondary databases are required to have the same service tier. また、セカンダリ データベースは、プライマリと同じコンピューティング サイズ (DTU または仮想コア) で作成することを強くお勧めします。It is also strongly recommended that secondary database is created with the same compute size (DTUs or vCores) as the primary. セカンダリのコンピューティング サイズが小さいと、レプリケーション遅延が大きくなる、セカンダリが利用きない、といったリスクが発生し、その結果、フェールオーバー後に重大なデータ損失が発生するリスクが高くなります。A secondary with lower compute size is at risk of an increased replication lag, potential unavailability of the secondary, and consequently at risk of substantial data loss after a failover. 結果として、公開済み RPO = 5 秒を保証できなくなります。As a result, the published RPO = 5 sec cannot be guaranteed. また、より大きいコンピューティング サイズにアップグレードされるまで、フェールオーバー後、アプリケーションのパフォーマンスが、新しいプライマリのコンピューティング容量不足の影響を受けるリスクもあります。The other risk is that after failover the application’s performance will be impacted due to insufficient compute capacity of the new primary until it is upgraded to a higher compute size. アップグレードの時間はデータベースのサイズよって異なります。The time of the upgrade depends on the database size. また、現在このようなアップグレードでは、プライマリとセカンダリの両方のデータベースがオンラインである必要があるため、機能停止に対処するまで完了できません。In addition, currently such upgrade requires that both primary and secondary databases are online and, therefore, cannot be completed until the outage is mitigated. 小さいコンピューティング サイズでセカンダリを作成する場合は、Azure portal 上のログ IO の割合グラフを使用すると、レプリケーションの負荷を維持するために必要なセカンダリの最小コンピューティング サイズを適切に見積もることができます。If you decide to create the secondary with lower compute size, the log IO percentage chart on Azure portal provides a good way to estimate the minimal compute size 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 compute sizes, see What are SQL Database Service Tiers.

  • ユーザー制御のフェールオーバーとフェールバック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.

  • 資格情報とファイアウォール規則の同期を保つKeeping credentials and firewall rules in sync

    geo レプリケートされたデータベースには、データベースのファイアウォール規則の使用をお勧めします。この規則は、データベースと共にレプリケートされ、すべてのセカンダリ データベースのファイアウォールの規則がプライマリと同じになります。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.

注意

Managed Instance では、自動フェールオーバーは利用できません。Auto-failover is not available in Managed Instance.

  • フェールオーバー グループFailover group

    1 つまたは複数のフェールオーバー グループを異なるリージョンの 2 つのサーバー (プライマリおよびセカンダリ サーバー) 間に作成できます。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.

  • フェールオーバー グループへのデータベースの追加Adding databases to failover group

    1 つのサーバー内または 1 つのエラスティック プール内の複数のデータベースを同じフェールオーバー グループに置くことができます。You can put several databases within a server or within an elastic pool into the same failover group. グループに単一データベースを追加すると、同じエディションとコンピューティング サイズを使用してセカンダリ データベースが自動的に作成されます。If you add a single database to the group, it automatically creates a secondary database using the same edition and compute size. プライマリ データベースがエラスティック プール内にある場合、セカンダリは同じ名前のエラスティック プールに自動的に作成されます。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.

  • フェールオーバー グループの読み取り/書き込みリスナーFailover group read-write listener

    現プライマリ サーバーの URL を示す <failover-group-name>.database.windows.net という形式の DNS の CNAME レコードです。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.

  • フェールオーバー グループの読み取り専用リスナーFailover group read-only listener

    セカンダリ サーバーの URL を示す <failover-group-name>.secondary.database.windows.net という形式の DNS の CNAME レコードです。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.

  • 自動フェールオーバー ポリシーAutomatic failover policy

    既定では、フェールオーバー グループは自動フェールオーバー ポリシーを使用して構成されます。By default, the failover group is configured with an automatic failover policy. システムはエラーが検出され、猶予期間が終了すると、フェールオーバーをトリガーします。The system triggers failover after the failure is detected and the grace period has expired. システムでは、影響の規模が原因で SQL Database サービスの組み込み高可用性インフラストラクチャによって機能停止を軽減することが不可能かどうかを確認する必要があります。The system must verify that the outage cannot be mitigated by the built-in high availability infrastructure of the SQL Database service due the scale of the impact. アプリケーションからフェールオーバー ワークフローを制御するには、自動フェールオーバーをオフにします。If you want to control the failover workflow from the application, you can turn off automatic failover.

  • 読み取り専用フェールオーバー ポリシーRead-only failover policy

    既定では、読み取り専用リスナーのフェールオーバーは無効になっています。By default, the failover of the read-only listener is disabled. セカンダリがオフラインのとき、プライマリのパフォーマンスに影響が出ないようにします。It ensures that the performance of the primary is not impacted when the secondary is offline. ただし、セカンダリが回復するまで、読み取り専用セッションは接続できません。However, it also means the read-only sessions will not be able to connect until the secondary is recovered. 読み取り専用セッションのダウンタイムを許容できず、プライマリのパフォーマンスが下がる可能性があっても、読み取り専用と読み取り/書き込みの両方のトラフィックに一時的にプライマリを使用しても良ければ、読み取り専用リスナーのフェールオーバーを有効にできます。If you cannot tolerate downtime for the readonly sessions and are OK to temporarily use the primary for both read-only and read-write traffic at the expense of the potential performance degradation of the primary, you can enable failover for the read-only listener. その場合、セカンダリ サーバーが利用できないと、読み取り専用トラフィックがプライマリ サーバーにリダイレクトされます。In that case the read-only traffic will be automatically redirected to the primary server if the secondary server is not available.

  • 手動フェールオーバー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 using failover groups for business continuity

ビジネス継続性を考慮してサービスを設計する場合は、次のガイドラインに従う必要があります。When designing a service with business continuity in mind, you should follow these guidelines:

  • 1 つまたは複数のフェールオーバー グループを使用して複数のデータベースのフェールオーバーを管理するUse one or several failover groups to manage failover of multiple databases

    1 つまたは複数のフェールオーバー グループを異なるリージョンの 2 つのサーバー (プライマリおよびセカンダリ サーバー) 間に作成できます。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 tier and compute size as the primary.

  • OLTP ワークロードに読み取り/書き込みのリスナーを使用するUse read-write listener for OLTP workload

    OLTP 操作を実行するときにサーバーの URL として <failover-group-name>.database.windows.net を使用すると、自動的にプライマリに接続されます。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.

  • パフォーマンスの低下に備えるBe prepared for perf degradation

    SQL のフェールオーバーの決定は、アプリケーションの他の領域や、使用されている他のサービスとは無関係に行われます。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.

  • データの損失に備えるPrepare for data loss

    機能停止が検出された場合、経験的にデータの損失がゼロであれば、読み取り/書き込みのフェールオーバーが SQL によって自動的にトリガーされます。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 fewer 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.

フェールオーバー グループとネットワーク セキュリティFailover groups and network security

一部のアプリケーションについてセキュリティ規則では、データ層へのネットワーク アクセスを、VM や Web サービスなど、特定の 1 つまたは複数のコンポーネントに限定する必要があります。ビジネス継続性の設計と、フェールオーバー グループの使用において、この要件は課題となっています。For some applications the security rules require that the network access to the data tier is restricted to a specific component or components such as a VM, web service etc. This requirement presents some challenges for business continuity design and the use of the failover groups. このような制限付きアクセスを実装する場合は、次のオプションを検討してください。You should consider the following options when implementing such restricted access.

フェールオーバー グループと仮想ネットワーク規則を使用するUsing failover groups and virtual network rules

Virtual Network サービス エンドポイントおよび規則を使用して SQL データベースへのアクセスを制限する場合、各 Virtual Network サービス エンドポイントは 1 つの Azure リージョンだけにしか適用されないことに注意してください。If you are using Virtual Network service endpoints and rules to restrict access to your SQL database, be aware that Each Virtual Network service endpoint applies to only one Azure region. エンドポイントが他のリージョンを有効にして、サブネットからの通信を許可することはありません。The endpoint does not enable other regions to accept communication from the subnet. そのため、同じリージョンにデプロイされているクライアント アプリケーションのみが、プライマリ データベースに接続できます。Therefore, only the client applications deployed in the same region can connect to the primary database. フェールオーバーの結果として SQL クライアント セッションは別の (セカンダリ) リージョン内のサーバーに再ルーティングされるので、それらのセッションをセカンダリ リージョンの外部にあるクライアントから実行した場合は失敗します。Since the failover results in the SQL client sessions being rerouted to a server in a different (secondary) region, these sessions will fail if originated from a client outside of that region. そのため、参加するサーバーが Virtual Network 規則に含まれている場合、自動フェールオーバー ポリシーを有効にすることはできません。For that reason, the automatic failover policy cannot be enabled if the participating servers are included in the Virtual Network rules. 手動フェールオーバーをサポートするには、次の手順を行います。To support manual failover, follow these steps:

  1. セカンダリ リージョンでアプリケーション (Web サービス、仮想マシンなど) のフロント エンド コンポーネントの冗長コピーをプロビジョニングするProvision the redundant copies of the front end components of your application (web service, virtual machines etc.) in the secondary region
  2. プライマリ サーバーとセカンダリ サーバーに対して別々にVirtual Network 規則を構成するConfigure the virtual network rules individually for primary and secondary server
  3. Traffic Manager の構成を使用したフロント エンド フェールオーバーを有効にするEnable the front-end failover using a Traffic manager configuration
  4. 機能停止が検出されたときに手動フェールオーバーを開始するInitiate manual failover when the outage is detected

このオプションは、フロント エンドとデータ層の間で一貫した待機時間を必要とするアプリケーションに対して最適化されており、フロント エンド、データ層、またはこの両方が機能停止の影響を受ける場合に回復をサポートします。This option is optimized for the applications that require consistent latency between the front-end and the data tier and supports recovery when either front end, data tier or both are impacted by the outage.

注意

読み取り専用リスナーを使用して読み取り専用ワークロードを負荷分散する場合は、このワークロードを必ずセカンダリ リージョン内の VM などのリソースで実行することで、セカンダリ データベースに接続できるようにします。If you are using the read-only listener to load-balance a read-only workload, make sure that this workload is executed in a VM or other resorce in the secondary region so it can connect to the secondary database.

フェールオーバー グループおよび SQL データベース ファイアウォール規則を使用するUsing failover groups and SQL database firewall rules

ビジネス継続性計画でグループを使用するフェールオーバーと自動フェールオーバーが必要な場合は、従来のファイアウォール規則を使用して、SQL データベースへのアクセスを制限することができます。If your business continuity plan requires failover using groups with automatic failover, you can restrict access to your SQL database using the traditional firewall rules. 自動フェールオーバーをサポートするには、次の手順を行います。To support automatic failover, follow these steps:

  1. パブリック IP を作成しますCreate a public IP
  2. パブリック ロード バランサーを作成し、パブリック IP を割り当てます。Create a public load balancer and assign the public IP to it.
  3. フロント エンド コンポーネントに対して仮想ネットワークと仮想マシンを作成します。Create a virtual network and the virtual machines for your front-end components
  4. ネットワーク セキュリティ グループを作成し、受信接続を構成します。Create network security group and configure inbound connections.
  5. ‘Sql’ サービス タグを使用して Azure SQL Database への送信接続が開いていることを確認します。Ensure that the outbound connections are open to Azure SQL database by using ‘Sql’ service tag.
  6. SQL データベース ファイアウォール規則を作成して、手順 1 で作成したパブリック IP アドレスからの受信トラフィックを許可します。Create a SQL database firewall rule to allow inbound traffic from the public IP address you create in step 1.

送信アクセスを構成する方法と、ファイアウォール規則で使用する IP の詳細については、ロード バランサー送信接続に関するページを参照してください。For more information about on how to configure outbound access and what IP to use in the firewall rules, see Load balancer outbound connections.

上記の構成では、自動フェールオーバーによって、フロント エンド コンポーネントからの接続がブロックされることはありません。また、フロント エンドとデータ層の間の長い待機時間がアプリケーションで許容されることを前提としています。The above configuration will ensure that the automatic failover will not block connections from the front-end components and assumes that the application can tolerate the longer latency between the front end and the data tier.

重要

リージョンの機能停止に対してビジネス継続性を保証するためには、フロント エンド コンポーネントとデータベースの両方に対して地理的な冗長性を確保する必要があります。To guarantee business continuity for regional outages you must ensure geographic redundancy for both front-end components and the databases.

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

セカンダリ データベースの接続を解除することなく、プライマリ データベースを (同じサービス レベル内の) 異なるコンピューティング サイズにアップグレードまたはダウングレードできます。You can upgrade or downgrade a primary database to a different compute size (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 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. アクティブ geo レプリケーションには、管理のための Azure Resource Manager API 一式 (Azure SQL Database REST APIAzure PowerShell コマンドレットなど) が含まれています。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 説明Description
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 説明Description
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