自動フェールオーバー グループを使用して、複数のデータベースの透過的な調整されたフェールオーバーを有効にするUse auto-failover groups to enable transparent and coordinated failover of multiple databases

適用対象: Azure SQL Database Azure SQL Managed Instance

自動フェールオーバー グループ機能を使用すると、サーバー上のデータベースのグループ、またはマネージド インスタンス内のすべてのデータベースの別のリージョンへのレプリケーションやフェールオーバーを管理できます。The auto-failover groups feature allows you to manage the replication and failover of a group of databases on a server or all databases in a managed instance to another region. これは、既存のアクティブ geo レプリケーション機能に基づく宣言型の抽象化であり、geo レプリケーション対応データベースの大規模なデプロイと管理を簡素化するように設計されています。It is a declarative abstraction on top of the existing active geo-replication feature, designed to simplify deployment and management of geo-replicated databases at scale. フェールオーバーは、手動で開始することも、ユーザー定義ポリシーに基づいて Azure サービスに委任することもできます。You can initiate failover manually or you can delegate it to the Azure service based on a user-defined policy. 後者のオプションの場合、プライマリ リージョンで発生した致命的な障害やその他の計画外のイベントにより SQL Database や SQL Managed Instance の可用性がすべてまたは一部失われたときに、セカンダリ リージョンの複数の関連データベースを自動的に復元できます。The latter option 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 or SQL Managed Instance availability in the primary region. フェールオーバー グループには、通常同じアプリケーションによって使用される、1 つまたは複数のデータベースを含めることができます。A failover group can include one or multiple databases, typically used by the same application. さらに、読み取り可能なセカンダリ データベースを使用して、読み取り専用クエリ ワークロードをオフロードできます。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. 自動フェールオーバー グループでは、グループ内のすべてのデータベースを、別のリージョンの 1 つのセカンダリ サーバーまたはインスタンスのみへのレプリケートがサポートされます。Auto-failover groups support replication of all databases in the group to only one secondary server or instance in a different region.

注意

同じまたは異なるリージョンで複数の Azure SQL Database セカンダリが必要な場合は、アクティブ geo レプリケーションを使用してください。If you want multiple Azure SQL Database secondaries in the same or different regions, use active geo-replication.

自動フェールオーバー グループ ポリシーで自動フェールオーバー グループを使用しているときに、グループ内で 1 つ以上のデータベースに影響する機能停止が発生すると、自動フェールオーバーが行われます。When you are using auto-failover groups with automatic failover policy, any outage that impacts one or several of the databases in the group results in automatic failover. 通常、これらは、組み込みの自動高可用性操作では自己軽減できないインシデントです。Typically these are incidents that cannot be self-mitigated by the built-in automatic high availability operations. フェールオーバー トリガーの例には、複数のコンピューティング ノードでの OS カーネル メモリ リークによる SQL Database テナント リングまたは制御リングのダウンが原因で発生するインシデントや、所定のハードウェアの使用停止中に間違ったネットワーク ケーブルが切断されたことによる 1 つまたは複数のテナント リングのダウンが原因で発生するインシデントがあります。The examples of failover triggers include an incident caused by a SQL Database tenant ring or control ring being down due to an OS kernel memory leak on several compute nodes, or an incident caused by one or more tenant rings being down because a wrong network cable was cut during routine hardware decommissioning. 詳細については、SQL Database の高可用性に関する記事を参照してください。For more information, see SQL Database High Availability.

さらに、自動フェールオーバー グループには、フェールオーバー中にそのまま残る読み取り/書き込みリスナー エンドポイントと読み取り専用リスナー エンドポイントが用意されています。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 endpoints to the new region. 特定の RPO および RTO データについては、ビジネス継続性の概要に関するページを参照してください。For the specific RPO and RTO data, see Overview of Business Continuity.

自動フェールオーバー グループ ポリシーで自動フェールオーバー グループを使用しているときに、サーバーまたはマネージド インスタンスのデータベースに影響する機能停止が発生すると、自動フェールオーバーが行われます。When you are using auto-failover groups with automatic failover policy, any outage that impacts databases on a server or managed instance results in automatic failover. 自動フェールオーバー グループは、以下を使用して管理できます。You can manage auto-failover group using:

フェールオーバー後は、データベースおよびサーバー、またはインスタンスの認証要件が確実に新しいプライマリで構成されるようにしてください。After failover, ensure the authentication requirements for your database and server, or instance are configured on the new primary. 詳細については、 障害復旧後の SQL Database のセキュリティに関するページを参照してください。For details, see SQL Database security after disaster recovery.

ビジネスの継続性を実現するにあたって、データセンター間のデータベース冗長性を追加することは、ソリューションのほんの一部です。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.

用語と機能Terminology and capabilities

  • フェールオーバー グループ (FOG)Failover group (FOG)

    フェールオーバー グループは、プライマリ リージョンでの機能停止により、すべてまたは一部のプライマリ データベースが使用できなくなった場合に、1 つの単位として別のリージョンにフェールオーバーできるマネージド インスタンス内の、または単一サーバーによって管理されるデータベースの名前付きグループです。A failover group is a named group of databases managed by a single server or within a managed instance that can fail over as a unit to another region in case all or some primary databases become unavailable due to an outage in the primary region. SQL Managed Instance に対して作成された場合、フェールオーバー グループには、そのインスタンス内のすべてのユーザー データベースが含まれています。そのため、インスタンス上に構成できるフェールオーバー グループは 1 つのみとなります。When it's created for SQL Managed Instance, a failover group contains all user databases in the instance and therefore only one failover group can be configured on an instance.

    重要

    フェールオーバー グループの名前は、.database.windows.net ドメイン内でグローバルに一意である必要があります。The name of the failover group must be globally unique within the .database.windows.net domain.

  • サーバーServers

    サーバーでは、サーバー上の一部またはすべてのユーザー データベースをフェールオーバー グループに配置することができます。With servers, some or all of the user databases on a server can be placed in a failover group. また、サーバーでは、単一サーバー上の複数のフェールオーバー グループがサポートされます。Also, a server supports multiple failover groups on a single server.

  • プライマリPrimary

    フェールオーバー グループのプライマリ データベースをホストするサーバーまたはマネージド インスタンス。The server or managed instance that hosts the primary databases in the failover group.

  • セカンダリSecondary

    フェールオーバー グループのセカンダリ データベースをホストするサーバーまたはマネージド インスタンス。The server or managed instance that hosts the secondary databases in the failover group. セカンダリをプライマリと同じリージョンに配置することはできません。The secondary cannot be in the same region as the primary.

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

    同じサーバー上の複数の単一データベースを、同じフェールオーバー グループに配置することができます。You can put several single databases on the same server into the same failover group. フェールオーバー グループに単一データベースを追加すると、セカンダリ サーバー上の同じエディションとコンピューティング サイズを使用してセカンダリ データベースが自動的に作成されます。If you add a single database to the failover group, it automatically creates a secondary database using the same edition and compute size on secondary server. フェールオーバー グループを作成したときに、そのサーバーを指定しています。You specified that server when the failover group was created. セカンダリ サーバーにセカンダリ データベースが既に存在するデータベースを追加する場合、その geo レプリケーション リンクがグループに継承されます。If you add a database that already has a secondary database in the secondary server, that geo-replication link is inherited by the group. フェールオーバー グループの一部でないサーバーにセカンダリ データベースが既に存在するデータベースを追加すると、セカンダリ サーバーに新しいセカンダリが作成されます。When you add 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.

    重要

    既存のセカンダリ データベースである場合を除き、セカンダリ サーバーに同じ名前のデータベースがないことを確認してください。Make sure that the secondary server doesn't have a database with the same name unless it is an existing secondary database. SQL Managed Instance のフェールオーバー グループでは、すべてのユーザー データベースがレプリケートされます。In failover groups for SQL Managed Instance, all user databases are replicated. フェールオーバー グループで、レプリケーション対象としてユーザー データベースのサブセットを選択することはできません。You cannot pick a subset of user databases for replication in the failover group.

  • エラスティック プール内のデータベースをフェールオーバー グループに追加するAdding databases in elastic pool to failover group

    1 つのエラスティック プール内のすべてまたは複数のデータベースを同じフェールオーバー グループに置くことができます。You can put all or several databases within an elastic pool into the same failover group. プライマリ データベースがエラスティック プール内にある場合、セカンダリは同じ名前のエラスティック プール (セカンダリ プール) に自動的に作成されます。If the primary database is in an elastic pool, the secondary is automatically created in the elastic pool with the same name (secondary pool). セカンダリ サーバーに全く同じ名前のエラスティック プールが含まれており、フェールオーバー グループによって作成されるセカンダリ データベースをホストするのに十分な空き容量があることを確認する必要があります。You must ensure that the secondary server contains an elastic pool with the same exact name and enough free capacity to host the secondary databases that will be created by the failover group. セカンダリ プールにセカンダリ データベースが既に存在するプールにデータベースを追加する場合、その geo レプリケーション リンクがグループに継承されます。If you add a database in the pool that already has a secondary database in the secondary pool, that geo-replication link is inherited by the group. フェールオーバー グループの一部でないサーバーにセカンダリ データベースが既に存在するデータベースを追加すると、セカンダリ プールに新しいセカンダリが作成されます。When you add 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 pool.

  • 初期シード処理Initial Seeding

    データベース、エラスティック プール、またはマネージド インスタンスをフェールオーバー グループに追加する場合、データ レプリケーションが開始される前に、初期シード処理フェーズがあります。When adding databases, elastic pools, or managed instances to a failover group, there is an initial seeding phase before data replication starts. 初期シード処理フェーズは、最も時間がかかり、最も負荷の高い操作です。The initial seeding phase is the longest and most expensive operation. 初期シード処理が完了すると、データは同期され、その後はそれ以降のデータ変更のみがレプリケートされます。Once initial seeding completes, data is synchronized, and then only subsequent data changes are replicated. 初期シード処理が完了するまでにかかる時間は、データのサイズ、レプリケートされたデータベースの数、およびフェールオーバー グループ内のエンティティ間のリンクの速度によって異なります。The time it takes for the initial seed to complete depends on the size of your data, number of replicated databases, and the speed of the link between the entities in the failover group. 通常の環境において可能なシード処理の速度は、SQL Database では最大 500 GB/時、SQL Managed Instance では最大 360 GB/時になります。Under normal circumstances, possible seeding speed is up to 500 GB an hour for SQL Database, and up to 360 GB an hour for SQL Managed Instance. シード処理は、すべてのデータベースに対して並列で実行されます。Seeding is performed for all databases in parallel.

    SQL Managed Instance の場合は、初期シード処理フェーズの時間を見積もるときに、2 つのインスタンス間の Express Route リンクの速度を考慮してください。For SQL Managed Instance, consider the speed of the Express Route link between the two instances when estimating the time of the initial seeding phase. 2 つのインスタンス間のリンクの速度が、必要なものより遅い場合、シード処理の時間が特に影響を受ける可能性があります。If the speed of the link between the two instances is slower than what is necessary, the time to seed is likely be notably impacted. 提示したシード処理速度、データベースの数、データの合計サイズ、およびリンク速度を使用して、データ レプリケーションが開始される前に初期シード処理フェーズにかかる時間を見積もることができます。You can use the stated seeding speed, number of databases, total size of data, and the link speed to estimate how long the initial seeding phase will take before data replication starts. たとえば、100 GB のデータベースが 1 つの場合、リンクで 1 時間あたり 84 GB をプッシュでき、他のデータベースにシードしていないのであれば、初期シード処理フェーズにかかる時間は約 1.2 時間になります。For example, for a single 100 GB database, the initial seed phase would take about 1.2 hours if the link is capable of pushing 84 GB per hour, and if there are no other databases being seeded. リンクが転送できるのが 1 時間あたり 10 GB のみの場合、100 GB のデータベースのシード処理には約 10 時間かかります。If the link can only transfer 10 GB per hour, then seeding a 100 GB database will take about 10 hours. レプリケートするデータベースが複数ある場合、シード処理は並列で実行されます。そして、低速リンク速度と組み合わせると、すべてのデータベースからのデータの並列シード処理が使用可能なリンク帯域幅を超えている場合は、初期シード処理の時間が大幅に長くなることがあります。If there are multiple databases to replicate, seeding will be executed in parallel, and, when combined with a slow link speed, the initial seeding phase may take considerably longer, especially if the parallel seeding of data from all databases exceeds the available link bandwidth. 2 つのインスタンス間のネットワーク帯域幅が制限されていて、複数のマネージド インスタンスをフェールオーバー グループに追加する場合は、複数のマネージド インスタンスを 1 つずつ順番にフェールオーバー グループに追加することを検討してください。If the network bandwidth between two instances is limited and you are adding multiple managed instances to a failover group, consider adding multiple managed instances to the failover group sequentially, one by one. 2 つのマネージド インスタンスの間に適切なサイズのゲートウェイ SKU があり、企業ネットワークの帯域幅で許される場合は、最大 360 GB/時の速度を実現できます。Given an appropriately sized gateway SKU between the two managed instances, and if corporate network bandwidth allows it, it's possible to achieve speeds as high as 360 GB an hour.

  • DNS ゾーンDNS zone

    新しい SQL Managed Instance の作成時に自動的に生成される一意の ID。A unique ID that is automatically generated when a new SQL Managed Instance is created. このインスタンスのマルチドメイン (SAN) は、同じ DNS ゾーンのインスタンスに対するクライアント接続を認証する目的でプロビジョニングされます。A multi-domain (SAN) certificate for this instance is provisioned to authenticate the client connections to any instance in the same DNS zone. 同じフェールオーバー グループに属する 2 つのマネージド インスタンスでは、DNS ゾーンが共有される必要があります。The two managed instances in the same failover group must share the DNS zone.

    注意

    SQL Database に対して作成されたフェールオーバー グループには、DNS ゾーン ID は必要ありません。A DNS zone ID is not required for failover groups created for SQL Database.

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

    現在のプライマリの URL を指す、DNS CNAME レコード。A DNS CNAME record that points to the current primary's URL. フェールオーバー グループの作成時に自動的に作成され、フェールオーバー後、プライマリ データベースの変更時に読み取り/書き込みワークロードが透過的にプライマリに再接続できるようにします。It is created automatically when the failover group is created and allows the read-write workload to transparently reconnect to the primary database when the primary changes after failover. サーバーでフェールオーバー グループが作成されたときに、リスナー URL の DNS CNAME レコードの形式は <fog-name>.database.windows.net になります。When the failover group is created on a server, the DNS CNAME record for the listener URL is formed as <fog-name>.database.windows.net. SQL Managed Instance でフェールオーバー グループが作成されたときに、リスナー URL の DNS CNAME レコードの形式は <fog-name>.<zone_id>.database.windows.net になります。When the failover group is created on a SQL Managed Instance, the DNS CNAME record for the listener URL is formed as <fog-name>.<zone_id>.database.windows.net.

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

    セカンダリの URL を指す読み取り専用リスナーを指す、形成された DNS CNAME レコード。A DNS CNAME record formed that points to the read-only listener that points to the secondary's URL. フェールオーバー グループの作成時に自動的に作成され、指定された負荷分散規則を使用して、読み取り専用 SQL ワークロードが透過的にセカンダリに接続できるようにします。It is created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary using the specified load-balancing rules. サーバーでフェールオーバー グループが作成されたときに、リスナー URL の DNS CNAME レコードの形式は <fog-name>.secondary.database.windows.net になります。When the failover group is created on a server, the DNS CNAME record for the listener URL is formed as <fog-name>.secondary.database.windows.net. SQL Managed Instance でフェールオーバー グループが作成されたときに、リスナー URL の DNS CNAME レコードの形式は <fog-name>.secondary.<zone_id>.database.windows.net になります。When the failover group is created on a SQL Managed Instance, the DNS CNAME record for the listener URL is formed as <fog-name>.secondary.<zone_id>.database.windows.net.

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

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

    注意

    障害の規模とその軽減にかかる時間の検証には、運用チームによる人間の行為が必要なため、猶予期間を 1 時間未満に設定することはできません。Because verification of the scale of the outage and how quickly it can be mitigated involves human actions by the operations team, the grace period cannot be set below one hour. この制約は、データの同期状態に関係なく、フェールオーバー グループ内のすべてのデータベースに適用されます。This limitation applies to all databases in the failover group regardless of their data synchronization state.

  • 読み取り専用フェールオーバー ポリシー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. 読み取り専用セッションのダウンタイムを許容できず、プライマリのパフォーマンスが下がる可能性があっても、読み取り専用と読み取り/書き込みの両方のトラフィックに一時的にプライマリを使用しても良ければ、AllowReadOnlyFailoverToPrimary プロパティを構成することによって、読み取り専用リスナーのフェールオーバーを有効にできます。If you cannot tolerate downtime for the read-only 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 by configuring the AllowReadOnlyFailoverToPrimary property. その場合、セカンダリが利用できないと、読み取り専用トラフィックがプライマリに自動的にリダイレクトされます。In that case, the read-only traffic will be automatically redirected to the primary if the secondary is not available.

  • 計画されたフェールオーバーPlanned failover

    計画されたフェールオーバーでは、セカンダリがプライマリ ロールに切り替わる前に、プライマリ データベースとセカンダリ データベース間の完全同期が行われます。Planned failover performs full synchronization between primary and secondary databases before the secondary switches to the primary role. これにより、データ損失が発生しないことが保証されます。This guarantees no data loss. 計画されたフェールオーバーは、次のシナリオで使用されます。Planned failover is used in the following scenarios:

    • データ損失が許容されない場合は、運用環境でディザスター リカバリー (DR) ドリルを行いますPerform disaster recovery (DR) drills in production when the data loss is not acceptable
    • データベースを別のリージョンに再配置しますRelocate the databases to a different region
    • 機能停止が軽減 (フェールバック) された後、データベースをプライマリ リージョンに返します。Return the databases to the primary region after the outage has been mitigated (failback).
  • 計画されていないフェールオーバーUnplanned failover

    計画されていないフェールオーバーや強制フェールオーバーでは、プライマリと同期せずに、セカンダリをすぐにプライマリ ロールに切り替えます。Unplanned or forced failover immediately switches the secondary to the primary role without any synchronization with the primary. この操作を行うとデータが失われます。This operation will result in data loss. 計画されていないフェールオーバーは、機能停止時においてプライマリにアクセスできない場合に回復手段として使用されます。Unplanned failover is used as a recovery method during outages when the primary is not accessible. 元のプライマリは、オンラインに戻ると、同期せずに自動的に再接続され、新しいセカンダリとなります。When the original primary is back online, it will automatically reconnect without synchronization and become a new secondary.

  • 手動フェールオーバー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 to the secondary. 強制フェールオーバーまたはフレンドリ フェールオーバーを開始できます (データは完全に同期されます)。You can initiate forced or friendly failover (with full data synchronization). 後者は、プライマリをセカンダリ リージョンに再配置する場合に使用できます。The latter could be used to relocate the primary to the secondary region. フェールオーバーが完了すると、確実に新しいプライマリに接続されるように、DNS レコードが自動的に更新されますWhen failover is completed, the DNS records are automatically updated to ensure connectivity to the new primary

  • データ消失の猶予期間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.

  • 複数のフェールオーバー グループ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.

    注意

    SQL Managed Instance では、複数のフェールオーバー グループはサポートされません。SQL Managed Instance does not support multiple failover groups.

アクセス許可Permissions

フェールオーバー グループに対するアクセス許可は、Azure ロールベースのアクセス制御 (Azure RBAC) によって管理されます。Permissions for a failover group are managed via Azure role-based access control (Azure RBAC). SQL Server 共同作成者ロールには、フェールオーバー グループを管理するために必要なすべてのアクセス許可があります。The SQL Server Contributor role has all the necessary permissions to manage failover groups.

フェールオーバー グループの作成Create failover group

フェールオーバー グループを作成するには、プライマリ サーバーとセカンダリ サーバーの両方、およびフェールオーバー グループ内のすべてのデータベースへの RBAC 書き込みアクセス権が必要です。To create a failover group, you need RBAC write access to both the primary and secondary servers, and to all databases in the failover group. SQL Managed Instance の場合、プライマリとセカンダリの両方の SQL Managed Instance への RBAC 書き込みアクセス権が必要です。しかし、個々の SQL Managed Instance データベースをフェールオーバー グループに対して追加や削除はできないため、個々のデータベースに対するアクセス許可は関係しません。For a SQL Managed Instance, you need RBAC write access to both the primary and secondary SQL Managed Instance, but permissions on individual databases are not relevant, because individual SQL Managed Instance databases cannot be added to or removed from a failover group.

フェールオーバー グループの更新Update a failover group

フェールオーバー グループを更新するには、そのフェールオーバー グループ、および現在のプライマ リ サーバーまたはマネージド インスタンス上のすべてのデータベースへの RBAC 書き込みアクセス権が必要です。To update a failover group, you need RBAC write access to the failover group, and all databases on the current primary server or managed instance.

フェールオーバー グループをフェールオーバーするFail over a failover group

フェールオーバー グループをフェールオーバーするには、新しいプライマリ サーバーまたはマネージド インスタンス上のフェールオーバー グループへの RBAC 書き込みアクセス権が必要です。To fail over a failover group, you need RBAC write access to the failover group on the new primary server or managed instance.

SQL Database のベスト プラクティスBest practices for SQL Database

自動フェールオーバー グループはプライマリ サーバーに構成する必要があり、それを別の Azure リージョンのセカンダリ サーバーに接続します。The auto-failover group must be configured on the primary server and will connect it to the secondary server in a different Azure region. グループには、これらのサーバーのすべてまたは一部のデータベースを含めることができます。The groups can include all or some databases in these servers. 次の図に、複数のデータベースと自動フェールオーバー グループを使用する、geo 冗長クラウド アプリケーションの一般的な構成を示します。The following diagram illustrates a typical configuration of a geo-redundant cloud application using multiple databases and auto-failover group.

図では、複数のデータベースと自動フェールオーバー グループを使用する、geo 冗長クラウド アプリケーションの一般的な構成が示されています。

注意

フェールオーバー グループに SQL Database のデータベースを追加する詳細なステップバイステップのチュートリアルについては、フェールオーバー グループへの SQL Database の追加に関するページを参照してください。See Add SQL Database to a failover group for a detailed step-by-step tutorial adding a database in SQL Database to a failover group.

ビジネス継続性を考慮してサービスを設計する場合は、次の一般的なガイドラインに従います。When designing a service with business continuity in mind, follow these general guidelines:

1 つまたは複数のフェールオーバー グループを使用して複数のデータベースのフェールオーバーを管理するUsing 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.

重要

異なるサブスクリプションにある 2 つのサーバー間でのフェールオーバー グループの作成は、現在、Azure SQL Database ではサポートされていません。Creating failover groups between two servers in different subscriptions is not currently supported for Azure SQL Database. フェールオーバー グループを作成した後で、プライマリ サーバーまたはセカンダリ サーバーを別のサブスクリプションに移動した場合、フェールオーバー要求やその他の操作が失敗する可能性があります。If you move the primary or secondary server to a different subscription after the failover group has been created, it could result in failures of the failover requests and other operations.

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

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

読み取り専用ワークロードに読み取り専用リスナーを使用するUsing 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 として <fog-name>.secondary.database.windows.net を使用すると、自動的にセカンダリに接続されます。For read-only sessions, use <fog-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. フェールオーバー後またはセカンダリ サーバーがオフラインになったときに読み取り専用ワークロードを再接続できるようにする場合、フェールオーバー ポリシーの AllowReadOnlyFailoverToPrimary プロパティを構成してください。If you want to ensure that the read-only workload can reconnect after failover or in case the secondary server goes offline, make sure to configure the AllowReadOnlyFailoverToPrimary property of the failover policy.

パフォーマンスの低下に対して準備するPreparing for performance degradation

一般的な Azure アプリケーションでは、複数の Azure サービスを使用し、複数のコンポーネントで構成されます。A typical Azure application uses multiple Azure services and consists of multiple components. フェールオーバー グループの自動フェールオーバーは、Azure SQL コンポーネントだけの状態に基づいてトリガーされます。The automated failover of the failover group is triggered based on the state the Azure SQL components alone. プライマリ リージョンのその他の Azure サービスは機能停止の影響を受けない場合があり、それらのコンポーネントを引き続きそのリージョンで利用できる可能性があります。Other Azure services in the primary region may not be affected by the outage and their components may still be available in that region. プライマリ データベースが DR リージョンに切り替えられると、依存コンポーネント間の待機時間が長くなる場合があります。Once the primary databases switch to the DR region, the latency between the dependent components may increase. 待機時間が長引くことがアプリケーションのパフォーマンスに影響しないように、DR リージョンにあるすべてのアプリケーションのコンポーネントの冗長性を確保し、これらのネットワーク セキュリティ ガイドラインに従ってください。To avoid the impact of higher latency on the application's performance, ensure the redundancy of all the application's components in the DR region and follow these network security guidelines.

データ損失に対して準備するPreparing for data loss

機能停止が検出された場合は、GracePeriodWithDataLossHours で指定した期間、Azure が待機状態となります。If an outage is detected, Azure waits for the period you specified by GracePeriodWithDataLossHours. 既定値は 1 時間です。The default value is 1 hour. データの損失が許容できない場合は、必ず、GracePeriodWithDataLossHours を十分大きい数値 (24 時間など) に設定してください。If you cannot afford data loss, make sure to set GracePeriodWithDataLossHours to a sufficiently large number, such as 24 hours. セカンダリからプライマリにフェールバックするには、手動のグループ フェールオーバーを使用します。Use manual group failover to fail back from the secondary to the primary.

重要

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.

フェールオーバー グループのセカンダリ リージョンを変更するChanging secondary region of the failover group

変更のシーケンスを説明するために、サーバー A はプライマリ サーバー、サーバー B は既存のセカンダリ サーバー、サーバー C は 3 番目のリージョンの新しいセカンダリであると仮定します。To illustrate the change sequence, we will assume that server A is the primary server, server B is the existing secondary server, and server C is the new secondary in the third region. 移行を行うには、次の手順を実行します。To make the transition, follow these steps:

  1. サーバー A の各データベースの追加のセカンダリを、アクティブ geo レプリケーションを使用してサーバー C に作成します。Create additional secondaries of each database on server A to server C using active geo-replication. サーバー A の各データベースには、2 つのセカンダリがあり、1 つはサーバー B に、もう 1 つはサーバー C にあります。これにより、移行中、プライマリ データベースが確実に保護された状態を維持できます。Each database on server A will have two secondaries, one on server B and one on server C. This will guarantee that the primary databases remain protected during the transition.
  2. フェールオーバー グループを削除します。Delete the failover group. この時点では、ログインは失敗します。At this point the logins will be failing. これは、フェールオーバー グループ リスナーの SQL エイリアスが削除されていて、ゲートウェイがフェールオーバー グループの名前を認識しないためです。This is because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name.
  3. サーバー A と C の間で同じ名前のフェールオーバー グループを再作成します。この時点で、ログインは失敗しなくなります。Re-create the failover group with the same name between servers A and C. At this point the logins will stop failing.
  4. サーバー A のすべてのプライマリ データベースを新しいフェールオーバー グループに追加します。Add all primary databases on server A to the new failover group.
  5. サーバー B を削除します。B のすべてのデータベースは自動的に削除されます。Drop server B. All databases on B will be deleted automatically.

フェールオーバー グループのプライマリ リージョンを変更するChanging primary region of the failover group

変更のシーケンスを説明するために、サーバー A はプライマリ サーバー、サーバー B は既存のセカンダリ サーバー、サーバー C は 3 番目のリージョンの新しいプライマリであると仮定します。To illustrate the change sequence, we will assume server A is the primary server, server B is the existing secondary server, and server C is the new primary in the third region. 移行を行うには、次の手順を実行します。To make the transition, follow these steps:

  1. 計画されたフェールオーバーを実行して、プライマリ サーバーを B に切り替えます。サーバー A が新しいセカンダリ サーバーになります。Perform a planned failover to switch the primary server to B. Server A will become the new secondary server. フェールオーバーによって、数分間のダウンタイムが発生する場合があります。The failover may result in several minutes of downtime. 実際の時間は、フェールオーバー グループのサイズによって異なります。The actual time will depend on the size of failover group.
  2. サーバー B の各データベースの追加のセカンダリを、アクティブ geo レプリケーションを使用してサーバー C に作成します。Create additional secondaries of each database on server B to server C using active geo-replication. サーバー B の各データベースには、2 つのセカンダリがあり、1 つはサーバー A に、もう 1 つはサーバー C にあります。これにより、移行中、プライマリ データベースが確実に保護された状態を維持できます。Each database on server B will have two secondaries, one on server A and one on server C. This will guarantee that the primary databases remain protected during the transition.
  3. フェールオーバー グループを削除します。Delete the failover group. この時点では、ログインは失敗します。At this point the logins will be failing. これは、フェールオーバー グループ リスナーの SQL エイリアスが削除されていて、ゲートウェイがフェールオーバー グループの名前を認識しないためです。This is because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name.
  4. サーバー B と C の間で同じ名前のフェールオーバー グループを再作成します。この時点で、ログインは失敗しなくなります。Re-create the failover group with the same name between servers B and C. At this point the logins will stop failing.
  5. B のすべてのプライマリ データベースを新しいフェールオーバー グループに追加します。Add all primary databases on B to the new failover group.
  6. フェールオーバー グループの計画されたフェールオーバーを実行して B と C を切り替えます。これで、サーバー C がプライマリになり、B がセカンダリになります。Perform a planned failover of the failover group to switch B and C. Now server C will become the primary and B - the secondary. サーバー A 上のすべてのセカンダリ データベースは、自動的に C のプライマリにリンクされます。手順 1 と同様に、フェールオーバーによって数分間のダウンタイムが発生する場合があります。All secondary databases on server A will be automatically linked to the primaries on C. As in step 1, the failover may result in several minutes of downtime.
  7. サーバー A を削除します。A のすべてのデータベースは自動的に削除されます。Drop the server A. All databases on A will be deleted automatically.

重要

フェールオーバー グループを削除すると、リスナー エンドポイントの DNS レコードも削除されます。When the failover group is deleted, the DNS records for the listener endpoints are also deleted. その時点では、他のユーザーが同じ名前のフェールオーバー グループまたはサーバー エイリアスを作成する可能性がゼロではなく、それが起こると、そのフェールオーバー グループやサーバー エイリアスは再び使用できなくなります。At that point, there is a non-zero probability of somebody else creating a failover group or server alias with the same name, which will prevent you from using it again. このリスクを最小限に抑えるために、一般的なフェールオーバー グループ名は使用しないでください。To minimize the risk, don't use generic failover group names.

SQL Managed Instance のベスト プラクティスBest practices for SQL Managed Instance

自動フェールオーバー グループはプライマリ インスタンスに構成する必要があり、それを別の Azure リージョンのセカンダリ インスタンスに接続します。The auto-failover group must be configured on the primary instance and will connect it to the secondary instance in a different Azure region. インスタンス内のすべてのデータベースは、セカンダリ インスタンスにレプリケートされます。All databases in the instance will be replicated to the secondary instance.

次の図に、マネージド インスタンスと自動フェールオーバー グループを使用する、geo 冗長クラウド アプリケーションの一般的な構成を示します。The following diagram illustrates a typical configuration of a geo-redundant cloud application using managed instance and auto-failover group.

自動フェールオーバーの図

注意

フェールオーバー グループを使用するための SQL Managed Instance の追加に関する詳細なステップバイステップのチュートリアルについては、フェールオーバー グループへのマネージド インスタンスの追加に関するページを参照してください。See Add managed instance to a failover group for a detailed step-by-step tutorial adding a SQL Managed Instance to use failover group.

アプリケーションでデータ層として SQL Managed Instance を使用する場合は、ビジネス継続性を考慮して設計する際にこれらの一般的なガイドラインに従います。If your application uses SQL Managed Instance as the data tier, follow these general guidelines when designing for business continuity:

セカンダリ インスタンスを作成するCreating the secondary instance

フェールオーバー後にプライマリ SQL Managed Instance に中断することなく確実に接続するには、プライマリとセカンダリの両方のインスタンスが同じ DNS ゾーンにある必要があります。To ensure non-interrupted connectivity to the primary SQL Managed Instance after failover both the primary and secondary instances must be in the same DNS zone. それにより、フェールオーバー グループに属する 2 つのインスタンスのいずれかに対してクライアント接続を認証する目的で同じマルチドメイン (SAN) 証明書を利用できます。It will guarantee that the same multi-domain (SAN) certificate can be used to authenticate the client connections to either of the two instances in the failover group. アプリケーションを運用環境にデプロイする準備ができたら、別のリージョンでセカンダリ SQL Managed Instance を作成し、プライマリ SQL Managed Instance と DNS ゾーンを共有していることを確認します。When your application is ready for production deployment, create a secondary SQL Managed Instance in a different region and make sure it shares the DNS zone with the primary SQL Managed Instance. これは、Azure portal、PowerShell、または REST API を使用して、省略可能な DNS Zone Partner パラメーターを指定することで実行できます。You can do it by specifying the optional DNS Zone Partner parameter using the Azure portal, PowerShell, or the REST API.

重要

サブネットに作成された最初のマネージド インスタンスにより、同じサブネット内のそれ以降のすべてのインスタンスに対する DNS ゾーンが決まります。The first managed instance created in the subnet determines DNS zone for all subsequent instances in the same subnet. つまり、同じサブネットの 2 つのインスタンスが異なる DNS ゾーンに属することはできません。This means that two instances from the same subnet cannot belong to different DNS zones.

プライマリ インスタンスと同じ DNS ゾーンでのセカンダリ SQL Managed Instance の作成の詳細については、「セカンダリ マネージド インスタンスを作成する」を参照してください。For more information about creating the secondary SQL Managed Instance in the same DNS zone as the primary instance, see Create a secondary managed instance.

geo ペア リージョンの使用Using geo-paired regions

パフォーマンス上の理由により、両方のマネージド インスタンスを、ペアになっているリージョンにデプロイします。Deploy both managed instances to paired regions for performance reasons. geo ペア リージョンに存在するマネージド インスタンスは、ペアになっていないリージョンと比較すると、パフォーマンスがはるかに優れています。Managed instances residing in geo-paired regions have much better performance compared to unpaired regions.

2 つのインスタンス間のレプリケーション トラフィックを有効にするEnabling replication traffic between two instances

各インスタンスは独自の VNet に分離されるため、これらの VNet 間の 2 方向トラフィックを許可する必要があります。Because each instance is isolated in its own VNet, two-directional traffic between these VNets must be allowed. Azure VPN ゲートウェイに関するページを参照してくださいSee Azure VPN gateway

異なるサブスクリプションのマネージド インスタンス間でフェールオーバー グループを作成するCreating a failover group between managed instances in different subscriptions

サブスクリプションが同じ Azure Active Directory テナントに関連付けられている限り、2 つの異なるサブスクリプションの SQL Managed Instances 間でフェールオーバー グループを作成することができます。You can create a failover group between SQL Managed Instances in two different subscriptions, as long as subscriptions are associated to the same Azure Active Directory Tenant. PowerShell API を使用する場合は、セカンダリ SQL Managed Instance の PartnerSubscriptionId パラメーターを指定することでこれを実行できます。When using PowerShell API, you can do it by specifying the PartnerSubscriptionId parameter for the secondary SQL Managed Instance. REST API を使用している場合、properties.managedInstancePairs パラメーターに含まれる各インスタンス ID は、独自のサブスクリプション ID を持つことができます。When using REST API, each instance ID included in the properties.managedInstancePairs parameter can have its own subscriptionID.

重要

Azure portal では、異なるサブスクリプション間でのフェールオーバー グループの作成はサポートされません。Azure portal does not support the creation of failover groups across different subscriptions. また、異なるサブスクリプションやリソース グループにまたがる既存のフェールオーバー グループについては、プライマリ SQL Managed Instance からポータルを使用して手動でフェールオーバーを開始することはできません。Also, for the existing failover groups across different subscriptions and/or resource groups, failover cannot be initiated manually via portal from the primary SQL Managed Instance. 代わりに、geo セカンダリ インスタンスから開始してください。Initiate it from the geo-secondary instance instead.

セカンダリ インスタンスへのフェールオーバーを管理するManaging failover to secondary instance

フェールオーバー グループでは、SQL Managed Instance 内のすべてのデータベースのフェールオーバーを管理します。The failover group will manage the failover of all the databases in the SQL Managed Instance. グループが作成されると、インスタンス内の各データベースはセカンダリ SQL Managed Instance に自動的に geo レプリケートされます。When a group is created, each database in the instance will be automatically geo-replicated to the secondary SQL Managed Instance. フェールオーバー グループを使用して、データベース サブセットの部分的なフェールオーバーを開始することはできません。You cannot use failover groups to initiate a partial failover of a subset of the databases.

重要

データベースは、プライマリ SQL Managed Instance から削除された場合、geo セカンダリ SQL Managed Instance でも自動的に削除されます。If a database is removed from the primary SQL Managed Instance, it will also be dropped automatically on the geo-secondary SQL Managed Instance.

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

OLTP 操作を実行するときに、サーバー URL として <fog-name>.zone_id.database.windows.net を使用すると、自動的にプライマリに接続されます。When performing OLTP operations, use <fog-name>.zone_id.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 キャッシュが最新の情報に更新された後にのみ新しいプライマリにリダイレクトされます。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. セカンダリ インスタンスでは DNS ゾーンをプライマリと共有するため、同じ SAN 証明書を使用してクライアント アプリケーションを再接続できます。Because the secondary instance shares the DNS zone with the primary, the client application will be able to reconnect to it using the same SAN certificate.

読み取り専用リスナーを使用してセカンダリ インスタンスに接続するUsing read-only listener to connect to the secondary instance

データがある程度古くても構わない、論理的に分離された読み取り専用ワークロードがある場合、アプリケーションでセカンダリ データベースを使用できます。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. geo レプリケートされたセカンダリに直接接続するには、<fog-name>.secondary.<zone_id>.database.windows.net をサーバー URL として使用します。これにより、geo レプリケートされたセカンダリに直接接続されます。To connect directly to the geo-replicated secondary, use <fog-name>.secondary.<zone_id>.database.windows.net as the server URL and the connection is made directly to the geo-replicated secondary.

注意

特定のサービス レベルでは、SQL Database で、1 つの読み取り専用レプリカの容量を使用し、また、接続文字列の ApplicationIntent=ReadOnly パラメーターを使用して、読み取り専用クエリ ワークロードの負荷を分散するための読み取り専用レプリカの使用がサポートされます。In certain service tiers, SQL Database supports the use of read-only replicas to load balance read-only query workloads using the capacity of one read-only replica and using the ApplicationIntent=ReadOnly parameter in the connection string. geo レプリケートされたセカンダリを構成した場合は、この機能を使用して、プライマリ ロケーション、または geo レプリケートされたロケーションの読み取り専用レプリカに接続できます。When you have configured a geo-replicated secondary, you can use this capability to connect to either a read-only replica in the primary location or in the geo-replicated location.

  • プライマリ ロケーションの読み取り専用レプリカに接続するには、<fog-name>.<zone_id>.database.windows.net を使用します。To connect to a read-only replica in the primary location, use <fog-name>.<zone_id>.database.windows.net.
  • セカンダリ ロケーションの読み取り専用レプリカに接続するには、<fog-name>.secondary.<zone_id>.database.windows.net を使用します。To connect to a read-only replica in the secondary location, use <fog-name>.secondary.<zone_id>.database.windows.net.

パフォーマンスの低下に対して準備するPreparing for performance degradation

一般的な Azure アプリケーションでは、複数の Azure サービスを使用し、複数のコンポーネントで構成されます。A typical Azure application uses multiple Azure services and consists of multiple components. フェールオーバー グループの自動フェールオーバーは、Azure SQL コンポーネントだけの状態に基づいてトリガーされます。The automated failover of the failover group is triggered based on the state the Azure SQL components alone. プライマリ リージョンのその他の Azure サービスは機能停止の影響を受けない場合があり、それらのコンポーネントを引き続きそのリージョンで利用できる可能性があります。Other Azure services in the primary region may not be affected by the outage and their components may still be available in that region. プライマリ データベースが DR リージョンに切り替えられると、依存コンポーネント間の待機時間が長くなる場合があります。Once the primary databases switch to the DR region, the latency between the dependent components may increase. 待機時間が長引くことがアプリケーションのパフォーマンスに影響しないように、DR リージョンにあるすべてのアプリケーションのコンポーネントの冗長性を確保し、これらのネットワーク セキュリティ ガイドラインに従ってください。To avoid the impact of higher latency on the application's performance, ensure the redundancy of all the application's components in the DR region and follow these network security guidelines.

データ損失に対して準備するPreparing for data loss

機能停止が検出された場合、経験的にデータの損失がゼロであれば、読み取り/書き込みのフェールオーバーがトリガーされます。If an outage is detected, a read-write failover is triggered if there is zero data loss, to the best of our knowledge. それ以外の場合は、指定した期間、待機状態となります。Otherwise there is a wait for the period you specified by. それ以外の場合、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.

読み取り/書き込みリスナーの DNS の更新は、フェールオーバーが開始された後すぐに行われます。The DNS update of the read-write listener will happen immediately after the failover is initiated. この操作でデータが失われることはありません。This operation will not result in data loss. しかし、データベース ロールの切り替えプロセスには、通常の状況で最大 5 分かかる場合があります。However, the process of switching database roles can take up to 5 minutes under normal conditions. これが完了するまで、新しいプライマリ インスタンスの一部のデータベースは引き続き読み取り専用となります。Until it is completed, some databases in the new primary instance will still be read-only. PowerShell を使用してフェールオーバーが開始された場合、操作全体が同期されます。If failover is initiated using PowerShell, the entire operation is synchronous. Azure ポータルを使用して開始された場合、UI で完了状態が示されます。If it is initiated using the Azure portal, the UI will indicate completion status. REST API を使用して開始された場合は、標準的な Azure リソース マネージャーのポーリング メカニズムを使用して、完了を監視します。If it is initiated using the REST API, use standard Azure Resource Manager’s polling mechanism to monitor for completion.

重要

プライマリを元の場所に戻すには、手動のグループ フェールオーバーを使用します。Use manual group failover to move primaries back to the original location. フェールオーバーの原因となった機能停止が軽減されたら、プライマリ データベースを元の場所に移動できます。When the outage that caused the failover is mitigated, you can move your primary databases to the original location. そのためには、グループの手動フェールオーバーを開始する必要があります。To do that you should initiate the manual failover of the group.

フェールオーバー グループのセカンダリ リージョンを変更するChanging secondary region of the failover group

インスタンス A がプライマリ インスタンス、インスタンス B が既存のセカンダリ インスタンス、インスタンス C が 3 番目のリージョン内の新しいセカンダリ インスタンスであるとします。Let's assume that instance A is the primary instance, instance B is the existing secondary instance, and instance C is the new secondary instance in the third region. 移行を行うには、次の手順を実行します。To make the transition, follow these steps:

  1. 同じ DNS ゾーン内で、A と同じサイズのインスタンス C を作成します。Create instance C with same size as A and in the same DNS zone.
  2. インスタンス A と B 間のフェールオーバー グループを削除します。この時点ではログインは失敗します。フェールオーバー グループ リスナーの SQL エイリアスが削除されていて、ゲートウェイがフェールオーバー グループ名を認識しないためです。Delete the failover group between instances A and B. At this point the logins will be failing because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name. セカンダリ データベースはプライマリから切断され、読み取り/書き込みデータベースになります。The secondary databases will be disconnected from the primaries and will become read-write databases.
  3. インスタンス A と C の間に同じ名前のフェールオーバー グループを作成します。SQL Managed Instance を含むフェールオーバー グループのチュートリアルに関するページの手順に従ってください。Create a failover group with the same name between instance A and C. Follow the instructions in failover group with SQL Managed Instance tutorial. これはデータ サイズに左右される操作であり、インスタンス A のすべてのデータベースがシード処理され、同期されると完了します。This is a size-of-data operation and will complete when all databases from instance A are seeded and synchronized.
  4. 不要な料金が発生しないように、インスタンス B が不要であれば削除してください。Delete instance B if not needed to avoid unnecessary charges.

注意

手順 2 の後、手順 3 が完了するまでは、インスタンス A のデータベースは、インスタンス A の致命的な障害から保護されないままになります。After step 2 and until step 3 is completed the databases in instance A will remain unprotected from a catastrophic failure of instance A.

フェールオーバー グループのプライマリ リージョンを変更するChanging primary region of the failover group

インスタンス A がプライマリ インスタンス、インスタンス B が既存のセカンダリ インスタンス、インスタンス C が 3 番目のリージョン内の新しいプライマリ インスタンスであるとします。Let's assume instance A is the primary instance, instance B is the existing secondary instance, and instance C is the new primary instance in the third region. 移行を行うには、次の手順を実行します。To make the transition, follow these steps:

  1. 同じ DNS ゾーン内で、B と同じサイズのインスタンス C を作成します。Create instance C with same size as B and in the same DNS zone.
  2. インスタンス B に接続し、手動でフェールオーバーしてプライマリ インスタンスを B に切り替えます。インスタンス A が自動的に新しいセカンダリ インスタンスになります。Connect to instance B and manually failover to switch the primary instance to B. Instance A will become the new secondary instance automatically.
  3. インスタンス A と B 間のフェールオーバー グループを削除します。この時点ではログインは失敗します。フェールオーバー グループ リスナーの SQL エイリアスが削除されていて、ゲートウェイがフェールオーバー グループ名を認識しないためです。Delete the failover group between instances A and B. At this point the logins will be failing because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name. セカンダリ データベースはプライマリから切断され、読み取り/書き込みデータベースになります。The secondary databases will be disconnected from the primaries and will become read-write databases.
  4. インスタンス A と C の間に同じ名前のフェールオーバー グループを作成します。マネージド インスタンスを含むフェールオーバー グループのチュートリアルに関する記事の手順に従ってください。Create a failover group with the same name between instance A and C. Follow the instructions in the failover group with managed instance tutorial. これはデータ サイズに左右される操作であり、インスタンス A のすべてのデータベースがシード処理され、同期されると完了します。This is a size-of-data operation and will complete when all databases from instance A are seeded and synchronized.
  5. 不要な料金が発生しないように、インスタンス A が不要であれば削除してください。Delete instance A if not needed to avoid unnecessary charges.

注意事項

手順 3 の後、手順 4 が完了するまでは、インスタンス A のデータベースは、インスタンス A の致命的な障害から保護されないままになります。After step 3 and until step 4 is completed the databases in instance A will remain unprotected from a catastrophic failure of instance A.

重要

フェールオーバー グループを削除すると、リスナー エンドポイントの DNS レコードも削除されます。When the failover group is deleted, the DNS records for the listener endpoints are also deleted. その時点では、他のユーザーが同じ名前のフェールオーバー グループまたはサーバー エイリアスを作成する可能性がゼロではなく、それが起こると、そのフェールオーバー グループやサーバー エイリアスは再び使用できなくなります。At that point, there is a non-zero probability of somebody else creating a failover group or server alias with the same name, which will prevent you from using it again. このリスクを最小限に抑えるために、一般的なフェールオーバー グループ名は使用しないでください。To minimize the risk, don't use generic failover group names.

システム データベースのオブジェクトに依存するシナリオを実現させるEnable scenarios dependent on objects from the system databases

システム データベースは、フェールオーバー グループのセカンダリ インスタンスにはレプリケートされません。System databases are not replicated to the secondary instance in a failover group. セカンダリ インスタンスで、システム データベースのオブジェクトに依存するシナリオを実現させるには、必ず、セカンダリに同じオブジェクトを作成してください。To enable scenarios that depend on objects from the system databases, on the secondary instance, make sure to create the same objects on the secondary. たとえば、セカンダリ インスタンスで同じログインを使用する予定の場合は、必ず、同じ SID でそれらを作成してください。For example, if you plan to use the same logins on the secondary instance, make sure to create them with the identical SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

フェールオーバー グループとネットワーク セキュリティ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. このような制限付きアクセスを実装する場合は、次のオプションを検討してください。Consider the following options when implementing such restricted access.

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

仮想ネットワーク サービス エンドポイントおよび規則を使用して、SQL Database または SQL Managed Instance のデータベースへのアクセスを制限する場合、各仮想ネットワーク サービス エンドポイントは 1 つの Azure リージョンにのみ適用されることに注意してください。If you are using Virtual Network service endpoints and rules to restrict access to your database in SQL Database or SQL Managed Instance, 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 Database クライアント セッションは別の (セカンダリ) リージョン内のサーバーに再ルーティングされるので、これらのセッションは、そのリージョンの外部にあるクライアントから発生した場合に失敗します。Since the failover results in the SQL Database 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. そのため、参加するサーバーまたはインスタンスが仮想ネットワーク規則に含まれている場合、自動フェールオーバー ポリシーを有効にすることはできません。For that reason, the automatic failover policy cannot be enabled if the participating servers or instances 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. プライマリ サーバーとセカンダリ サーバーに対して別々に仮想ネットワーク規則を構成する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 resource in the secondary region so it can connect to the secondary database.

フェールオーバー グループおよびファイアウォール規則を使用するUse failover groups and firewall rules

ビジネス継続性計画でグループを使用するフェールオーバーと自動フェールオーバーが必要な場合は、従来のファイアウォール規則を使用して、SQL Database 内のデータベースへのアクセスを制限することができます。If your business continuity plan requires failover using groups with automatic failover, you can restrict access to your database in SQL Database by 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 Database ファイアウォール規則を作成して、手順 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 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.

マネージド インスタンスとその VNet の間の geo レプリケーションを有効にするEnabling geo-replication between managed instances and their VNets

2 つの異なるリージョンのプライマリとセカンダリの SQL Managed Instance の間にフェールオーバー グループを設定すると、各インスタンスは独立した仮想ネットワークを使用して分離されます。When you set up a failover group between primary and secondary SQL Managed Instances in two different regions, each instance is isolated using an independent virtual network. これらの VNet 間のレプリケーション トラフィックを許可するには、以下の前提条件が満たされていることを確認します。To allow replication traffic between these VNets ensure these prerequisites are met:

  • SQL Managed Instance の 2 つのインスタンスは、異なる Azure リージョンにある必要があります。The two instances of SQL Managed Instance need to be in different Azure regions.

  • SQL Managed Instance の 2 つのインスタンスは同じサービス レベルである必要があり、ストレージ サイズも同じである必要があります。The two instances of SQL Managed Instance need to be the same service tier, and have the same storage size.

  • SQL Managed Instance のセカンダリ インスタンスは空 (ユーザー データベースなし) である必要があります。Your secondary instance of SQL Managed Instance must be empty (no user databases).

  • SQL Managed Instance のインスタンスによって使用される仮想ネットワークは、VPN Gateway または Express Route 経由で接続されている必要があります。The virtual networks used by the instances of SQL Managed Instance need to be connected through a VPN Gateway or Express Route. 2 つの仮想ネットワークがオンプレミスのネットワーク経由で接続されている場合、ポート 5022 および 11000-11999 をブロックするファイアウォール規則がないことを確認します。When two virtual networks connect through an on-premises network, ensure there is no firewall rule blocking ports 5022, and 11000-11999. グローバル VNet ピアリングはサポート対象ですが、次の注記で説明する制限事項があります。Global VNet Peering is supported with the limitation described in the note below.

    重要

    2020 年 9 月 22 日、Microsoft は、新しく作成された仮想クラスターのグローバル仮想ネットワーク ピアリングを発表しましたOn 9/22/2020 we announced global virtual network peering for newly created virtual clusters. これは、グローバル仮想ネットワーク ピアリングが、発表日以降に空のサブネットに作成された SQL Managed Instance に加え、それらのサブネットに作成された後続のすべてのマネージド インスタンスに対してサポートされることを意味します。That means that global virtual network peering is supported for SQL Managed Instances created in empty subnets after the announcement date, as well for all the subsequent managed instances created in those subnets. SQL Managed Instance のその他すべてのピアリングについては、グローバル仮想ネットワーク ピアリングの制約により、同じリージョン内のネットワークに制限されます。For all the other SQL Managed Instances peering support is limited to the networks in the same region due to the constraints of global virtual network peering. 詳細については、Azure Virtual Networks のよく寄せられる質問に関する記事の関連セクションも参照してください。See also the relevant section of the Azure Virtual Networks frequently asked questions article for more details.

  • 2 つの SQL Managed Instance VNet に、重複する IP アドレスを含めることはできません。The two SQL Managed Instance VNets cannot have overlapping IP addresses.

  • 他のマネージド インスタンスのサブネットからの接続では、インバウンドおよびアウトバウンドでポート 5022 およびその範囲の 11000 から 12000 を開くように、ネットワーク セキュリティ グループ (NSG) を設定する必要があります。You need to set up your Network Security Groups (NSG) such that ports 5022 and the range 11000~12000 are open inbound and outbound for connections from the subnet of the other managed instance. これで、インスタンス間のレプリケーション トラフィックを許可します。This is to allow replication traffic between the instances.

    重要

    NSG セキュリティ規則が正しく構成されていないと、データベースのコピー操作が停止します。Misconfigured NSG security rules leads to stuck database copy operations.

  • セカンダリ SQL Managed Instance は正しい DNS ゾーン ID で構成されます。The secondary SQL Managed Instance is configured with the correct DNS zone ID. DNS ゾーンは、SQL Managed Instance と基になる仮想クラスターのプロパティであり、ホスト名のアドレスにその ID が含まれます。DNS zone is a property of a SQL Managed Instance and underlying virtual cluster, and its ID is included in the host name address. ゾーン ID は、各 VNet で最初の SQL Managed Instance が作成されたときに、ランダムな文字列として生成され、同じ ID が同じサブネットの他のすべてのインスタンスに割り当てられます。The zone ID is generated as a random string when the first SQL Managed Instance is created in each VNet and the same ID is assigned to all other instances in the same subnet. 一度割り当てられると、DNS ゾーンは変更できません。Once assigned, the DNS zone cannot be modified. 同じフェールオーバー グループに含まれる SQL Managed Instance で、DNS ゾーンを共有する必要があります。SQL Managed Instances included in the same failover group must share the DNS zone. これは、セカンダリ インスタンスの作成時、プライマリ インスタンスのゾーン ID を DnsZonePartner パラメーターの値として渡すことで実行します。You accomplish this by passing the primary instance's zone ID as the value of DnsZonePartner parameter when creating the secondary instance.

    注意

    SQL Managed Instance を使用したフェールオーバー グループの構成の詳細なチュートリアルについては、フェールオーバー グループへの SQL Managed Instance の追加に関するページを参照してください。For a detailed tutorial on configuring failover groups with SQL Managed Instance, see add a SQL Managed Instance to a failover group.

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

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

より低い SKU のセカンダリが過負荷になり、アップグレードまたはダウングレー ドのプロセス中に再シードする必要があるという問題を回避するために、このシーケンスが特に推奨されます。This sequence is recommended specifically to avoid the problem where the secondary at a lower SKU gets overloaded and must be re-seeded during an upgrade or downgrade process. プライマリを読み取り専用にすることでこの問題を回避することもできます。その場合、プライマリへのすべての読み取り/書き込みワークロードに影響が出ることになります。You could also avoid the problem by making the primary read-only, at the expense of impacting all read-write workloads against the primary.

注意

セカンダリ データベースをフェールオーバー グループ構成の一部として作成した場合、セカンダリ データベースをダウングレードすることはお勧めできません。If you created a 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.

フェールオーバー グループとポイントインタイム リストアFailover groups and point-in-time restore

フェールオーバー グループでのポイントインタイム リストアの使用については、特定の時点への復元 (PITR) に関するページを参照してください。For information about using point-in-time restore with failover groups, see Point in Time Recovery (PITR).

フェールオーバー グループの制限Limitations of failover groups

次の制限事項に注意してください。Be aware of the following limitations:

  • 同じ Azure リージョン内の 2 つのサーバーまたはインスタンス間で、フェールオーバー グループを作成することはできません。Failover groups cannot be created between two servers or instances in the same Azure regions.
  • フェールオーバー グループの名前を変更することはできません。Failover groups cannot be renamed. グループを削除し、別の名前で再作成する必要があります。You will need to delete the group and re-create it with a different name.
  • データベース名の変更は、フェールオーバー グループ内のインスタンスに対してはサポートされていません。Database rename is not supported for instances in failover group. データベース名を変更するには、フェールオーバー グループを一時的に削除する必要があります。You will need to temporarily delete failover group to be able to rename a database.
  • システム データベースは、フェールオーバー グループのセカンダリ インスタンスにはレプリケートされません。System databases are not replicated to the secondary instance in a failover group. そのため、オブジェクトがセカンダリに手動で作成されていない限り、セカンダリ インスタンスではシステム データベースのオブジェクトに依存するシナリオは実現できません。Therefore, scenarios that depend on objects from the system databases will be impossible on the secondary instance unless the objects are manually created on the secondary.

フェールオーバー グループのプログラムによる管理Programmatically managing failover groups

前に説明したように、自動フェールオーバー グループとアクティブ 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 のロール ベースのアクセス制御 (Azure RBAC) に関するページをご覧ください。For more information on how to implement access roles, see Azure role-based access control (Azure RBAC).

SQL Database のフェールオーバーを管理するManage SQL Database failover

コマンドレットCmdlet 説明Description
New-AzSqlDatabaseFailoverGroupNew-AzSqlDatabaseFailoverGroup このコマンドはフェールオーバー グループを作成し、それをプライマリとセカンダリの両方のサーバーに登録します。This command creates a failover group and registers it on both primary and secondary servers
Remove-AzSqlDatabaseFailoverGroupRemove-AzSqlDatabaseFailoverGroup フェールオーバー グループをサーバーから削除します。Removes a failover group from the server
Get-AzSqlDatabaseFailoverGroupGet-AzSqlDatabaseFailoverGroup フェールオーバー グループの構成を取得します。Retrieves a failover group's configuration
Set-AzSqlDatabaseFailoverGroupSet-AzSqlDatabaseFailoverGroup フェールオーバー グループの構成を変更します。Modifies configuration of a failover group
Switch-AzSqlDatabaseFailoverGroupSwitch-AzSqlDatabaseFailoverGroup セカンダリ サーバーへのフェールオーバー グループのフェールオーバーをトリガーしますTriggers failover of a failover group to the secondary server
Add-AzSqlDatabaseToFailoverGroupAdd-AzSqlDatabaseToFailoverGroup 1 つまたは複数のデータベースをフェールオーバー グループに追加します。Adds one or more databases to a failover group

SQL Managed Instance のフェールオーバーを管理するManage SQL Managed Instance failover

コマンドレットCmdlet 説明Description
New-AzSqlDatabaseInstanceFailoverGroupNew-AzSqlDatabaseInstanceFailoverGroup このコマンドはフェールオーバー グループを作成し、それをプライマリとセカンダリの両方のインスタンスに登録します。This command creates a failover group and registers it on both primary and secondary instances
Set-AzSqlDatabaseInstanceFailoverGroupSet-AzSqlDatabaseInstanceFailoverGroup フェールオーバー グループの構成を変更します。Modifies configuration of a failover group
Get-AzSqlDatabaseInstanceFailoverGroupGet-AzSqlDatabaseInstanceFailoverGroup フェールオーバー グループの構成を取得します。Retrieves a failover group's configuration
Switch-AzSqlDatabaseInstanceFailoverGroupSwitch-AzSqlDatabaseInstanceFailoverGroup フェールオーバー グループのセカンダリ インスタンスに対するフェールオーバーをトリガーします。Triggers failover of a failover group to the secondary instance
Remove-AzSqlDatabaseInstanceFailoverGroupRemove-AzSqlDatabaseInstanceFailoverGroup フェールオーバー グループを削除しますRemoves a failover group

次のステップNext steps