アクティブ geo レプリケーションの作成と使用Creating and using active geo-replication

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

注意

アクティブ geo レプリケーションは、マネージド インスタンスではサポートされていません。Active geo-replication is not supported by managed instance. マネージド インスタンスの地理的なフェールオーバーについては、自動フェールオーバー グループを使用します。For geographic failover of managed instances, use Auto-failover groups.

アクティブ geo レプリケーションはビジネス継続性ソリューションとして設計されています。このソリューションを使用すれば、地域災害または大規模な機能停止が発生した場合にディザスター リカバリーをアプリケーションで迅速に実行することができます。Active geo-replication is designed as a business continuity solution that allows the application to perform quick disaster recovery of individual databases in case of a regional disaster or large 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 レプリケーションを使用して行われる geo 冗長クラウド アプリケーションの一般的な構成を示します。The following diagram illustrates a typical configuration of a geo-redundant cloud application using Active geo-replication.

アクティブ geo レプリケーション

重要

SQL Database でも自動フェールオーバー グループがサポートされています。SQL Database also supports auto-failover groups. 詳細については、自動フェールオーバー グループの使用に関するページを参照してください。For more information, see using auto-failover groups. また、アクティブ geo レプリケーションは、Managed Instance 内で作成されたデータベースに対してはサポートされていません。Also, active geo-replication is not supported for databases created within a Managed Instance. マネージド インスタンスでのフェールオーバー グループの使用を検討してください。Consider using failover groups with Managed Instances.

何らかの理由でご利用のプライマリ データベースにエラーが発生したか、または単にそのプライマリ データベースをオフラインにする必要がある場合、ご利用のセカンダリ データベースのいずれかへのフェールオーバーを開始することができます。If 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.

サーバー上またはエラスティック プール内の個々のデータベースまたはデータベースのセットのレプリケーションとフェールオーバーは、アクティブ 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:

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

注意

2 つのリージョン間でネットワーク障害が発生すると、接続を再確立するために 10 秒ごとに再試行します。If there is a network failure between two regions, we retry every 10 seconds to re-establish connections.

重要

プライマリ データベースでの重要な変更が、フェールオーバー前にセカンダリに確実にレプリケートされるようにするには、強制同期を実行して、重要な変更 (パスワードの更新など) のレプリケーションを確実に行わせることができます。To guarantee that a critical change on the primary database is replicated to a secondary before you failover, you can force synchronization to ensure the replication of critical changes (for example, password updates). 強制同期を実行すると、コミットされたトランザクションがすべてレプリケートされるまで呼び出しスレッドがブロックされるため、パフォーマンスに影響します。Forced synchronization impacts performance because it blocks the calling thread until all committed transactions are replicated. 詳細については、sp_wait_for_database_copy_sync に関するページをご覧ください。For details, see sp_wait_for_database_copy_sync. プライマリ データベースと geo セカンダリの間のレプリケーションの遅延を監視するには、「sys.dm_geo_replication_link_status」を参照してください。To monitor the replication lag between the primary database and geo-secondary, see sys.dm_geo_replication_link_status.

次の図は、プライマリが米国中北部リージョン、セカンダリが米国中南部リージョンに構成されたアクティブ 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 terminology and 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.

重要

geo レプリケーションを使用して、同じリージョンにプライマリとしてセカンダリ データベースを作成できます。You can use geo-replication to create a secondary database in the same region as the primary. このセカンダリを使用して、同じリージョン内の読み取り専用ワークロードの負荷分散を行います。You can use this secondary to load-balance a read-only workloads in the same region. ただし、同じリージョン内のセカンダリ データベースは、障害からの回復性を提供しないため、ディザスター リカバリーの適切なフェールオーバー ターゲットではありません。However, a secondary database in the same region does not provide additional fault resilience and therefore is not a suitable failover target for disaster recovery. また、可用性ゾーンの分離も保証されません。It will also not guarantee availability zone isolation. ゾーン冗長の構成を持つ Business Critical レベルまたは Premium サービス レベルを使用して、可用性ゾーンの分離を行ってください。Use Business critical or Premium service tier with zone redundant configuration to achieve availability zone isolation.

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

    計画されたフェールオーバーは、完全同期が完了した後に、プライマリ データベースとセカンダリ データベースのロールを切り替えます。Planned failover switches the roles of primary and secondary databases after the full synchronization is completed. これはデータの損失を発生させないオンライン操作です。It is an online operation that does not result in data loss. 操作の時間は、同期が必要なプライマリ上のトランザクション ログのサイズによって異なります。The time of the operation depends on the size of the transaction log on the primary that needs to be synchronized. 計画されたフェールオーバーは次のシナリオ向けに設計されています。(a) データの損失が許容されない場合に、運用環境で DR ドリルを実行する (b) 異なるリージョンにデータベースを再配置する、(c) 機能停止に対処した後でプライマリ リージョンにデータベースを戻す (フェールバック)。Planned failover is designed for following scenarios: (a) to perform DR drills in production when the data loss is not acceptable; (b) to relocate the database to a different region; and (c) to return the database 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. プライマリにコミットされていてもセカンダリにレプリケートされていないトランザクションは失われます。Any transactions committed to the primary but not replicated to the secondary will be lost. この操作は、停止中、プライマリにアクセスできないがデータベースの可用性を早急に回復しなければならない場合の復旧方法として設計されています。This operation is designed as a recovery method during outages when the primary is not accessible, but the database availability must be quickly restored. 元のプライマリは、オンラインに戻ると、自動的に再接続され、新しいセカンダリとなります。When the original primary is back online it will automatically re-connect and become a new secondary. フェールオーバー前の同期されていないトランザクションはすべてバックアップ ファイルに保持されますが、競合を避けるために新しいプライマリとは同期されません。All unsynchronized transactions before the failover will be preserved in the backup file but will not be synchronized with the new primary to avoid conflicts. これらのトランザクションは、プライマリ データベースの最新バージョンに手動でマージする必要があります。These transactions will have to be manually merged with the most recent version of the primary database.

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

    プライマリごとに、最大で 4 つのセカンダリ データベースを作成できます。Up to 4 secondary databases can be created for each primary. セカンダリ データベースが 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. セカンダリ データベースが複数存在する場合、セカンダリ データベースのいずれかに障害が発生しても、アプリケーションは保護された状態が維持されます。If multiple secondary databases exist, the application remains protected even if one of the secondary databases fails. 読み取り専用のワークロードをスケール アウトするために、追加のセカンダリを使用することもできます。The additional secondaries can also be used to scale out the read-only workloads

    注意

    グローバルに分散されたアプリケーションの構築にアクティブ 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.

  • エラスティック プール内のデータベースの geo レプリケーションGeo-replication of databases in an elastic pool

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

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

フェールオーバー用セカンダリ データベースの準備Preparing secondary database for failover

フェールオーバー後にアプリケーションが新しいプライマリにすぐアクセスできることが確実になるよう、セカンダリ サーバーとデータベースの認証要件が正しく構成されていることを確認してください。To ensure that your application can immediately access the new primary after failover, ensure the authentication requirements for your secondary server and database are properly configured. 詳細については、 障害復旧後の SQL Database のセキュリティに関するページを参照してください。For details, see SQL Database security after disaster recovery. フェールオーバー後のコンプライアンスを保証するために、セカンダリ データベースでのバックアップ保持ポリシーがプライマリのそれと一致していることを確認してください。To guarantee compliance after failover, make sure that the backup retention policy on the secondary database matches that of the primary. これらの設定はデータベースの一部ではなく、レプリケートされません。These settings are not part of the database and are not replicated. 既定では、セカンダリは 7 日間の既定の PITR 保持期間で構成されます。By default, the secondary will be configured with a default PITR retention period of seven days. 詳細については、「 SQL Database 自動バックアップ」を参照してください。For details, see SQL Database automated backups.

重要

ご使用のデータベースがフェールオーバー グループのメンバーである場合、geo レプリケーション フェールオーバー コマンドを使用して、そのフェールオーバーを開始することはできません。If your database is a member of a failover group, you cannot initiate its failover using the geo-replication faiover command. グループのフェールオーバー コマンドを使用することを検討してください。Consider using failover command for the group. 個々のデータベースをフェールオーバーする必要がある場合、最初にそれをフェールオーバー グループから削除する必要があります。If you need to failover an individual database, you must remove it from the failover group first. 詳細については、フェールオーバー グループに関する記事をご覧ください。See failover groups for details.

セカンダリ データベースの構成Configuring 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. プライマリ データベースで書き込みワークロードの負荷が高くなっている場合、コンピューティング サイズがより小さなセカンダリはそのワークロードを維持できない可能性があります。If the primary database is experiencing a heavy write workload, a secondary with lower compute size may not be able to keep up with it. これにより、セカンダリで再実行ラグが発生し、利用不能となる可能性があります。It will cause the redo lag on the secondary and potential unavailability. プライマリ データベースより処理速度が遅いセカンダリ データベースでは、フェールオーバーを強制的に実施する必要がある場合に、大きなデータ損失が発生するリスクもあります。A secondary database that is lagging behind the primary also risks a large data loss should a forced failover be required. このようなリスクを軽減するために、効果的なアクティブ geo レプリケーションは、プライマリのログ レートをスロットルしてセカンダリが追い付けるようにします。To mitigate these risks, effective active geo-replication will throttle the primary's log rate to allow its secondaries to catch up. バランスがとれていないセカンダリ構成の他の影響として、フェールオーバーの後、新しいプライマリのコンピューティング容量の不足のためにアプリケーションのパフォーマンスが低下することが挙げられます。The other consequence of an imbalanced secondary configuration is that after failover the application’s performance will suffer due to insufficient compute capacity of the new primary. より大きなコンピューティング容量に、必要なレベルまでアップグレードすることが必要になりますが、それは停止が緩和されるまで不可能です。It will be required to upgrade to a higher compute to the necessary level, which will not be possible until the outage is mitigated.

重要

セカンダリ データベースがプライマリと同じコンピューティング サイズで構成されていない場合、公表されている 5 秒の RPO は保証できません。The published RPO = 5 sec cannot be guaranteed unless the secondary database is configured with the same compute size as the primary.

小さいコンピューティング サイズでセカンダリを作成する場合は、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. スロットルは、sys.dm_exec_requests および sys.dm_os_wait_stats の各データベース ビューで HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO 待機状態として報告されます。The throttling is reported as a HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO wait state in the sys.dm_exec_requests and sys.dm_os_wait_stats database views.

SQL Database のコンピューティング サイズの詳細については、SQL Database サービス レベルに関するページをご覧ください。For more information on the SQL Database compute sizes, see What are SQL Database Service Tiers.

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

geo レプリケートされたデータベースには、データベース レベルのファイアウォール規則の使用をお勧めします。この規則は、データベースと共にレプリケートされ、すべてのセカンダリ データベースの IP ファイアウォール規則がプライマリと同じになります。We recommend using database-level IP firewall rules for geo-replicated databases so these rules can be replicated with the database to ensure all secondary databases have the same IP 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.

プライマリ データベースのアップグレードまたはダウングレードUpgrading or downgrading 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 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.

重要

フェールオーバー グループのプライマリ データベースを上位のレベルにスケーリングするには、最初にセカンダリ データベースを上位のレベルにスケーリングする必要があります。The primary database in a failover group can't scale to a higher tier unless the secondary database is first scaled to the higher tier. セカンダリ データベースがスケーリングされる前にプライマリ データベースをスケーリングしようとすると、次のエラーが表示される可能性があります。If you try to scale the primary database before the secondary database is scaled, you might receive the following error:

Error message: The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.

重要なデータの損失の防止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 レプリケーションの遅延の監視Monitoring geo-replication lag

RPO に関する遅延を監視するには、プライマリ データベースの sys.dm_geo_replication_link_statusreplication_lag_sec 列を使用します。To monitor lag with respect to RPO, use replication_lag_sec column of sys.dm_geo_replication_link_status on the primary database. ここには、プライマリでコミットされたトランザクションと、セカンダリで保持されているトランザクションとの間の遅延が秒単位で表示されます。It shows lag in seconds between the transactions committed on the primary and persisted on the secondary. 例:E.g. 遅延の値が 1 秒である場合は、この瞬間にプライマリが停止の影響を受け、フェールオーバーが開始されると、最新の移行の 1 秒間が保存されないことを示します。if the value of the lag is 1 second, it means if the primary is impacted by an outage at this moment and failover is initiated, 1 second of the most recent transitions will not be saved.

セカンダリに適用済みの (つまり、セカンダリから読み取り可能な) プライマリ データベースに対する変更に関する遅延を測定するには、セカンダリ データベースの last_commit 時間を、プライマリ データベースの同じ値と比較します。To measure lag with respect to changes on the primary database that have been applied on the secondary, i.e. available to read from the secondary, compare last_commit time on the secondary database with the same value on the primary database.

注意

プライマリ データベースの replication_lag_sec の値が NULL になっていることがありますが、これは、現時点でプライマリとセカンダリとの間の遅延時間が不明であることを意味します。Sometimes replication_lag_sec on the primary database has a NULL value, which means that the primary does not currently know how far the secondary is. これは、プロセスが再起動した後に発生する一時的な状態であることがほとんどです。This typically happens after process restarts and should be a transient condition. replication_lag_sec から長時間にわたって NULL が返される場合は、アプリケーションにアラートを送ることを検討してください。Consider alerting the application if the replication_lag_sec returns NULL for an extended period of time. 永続的な接続エラーにより、セカンダリ データベースがプライマリと通信できないことを示していると考えられます。It would indicate that the secondary database cannot communicate with the primary due to a permanent connectivity failure. セカンダリとプライマリ データベース間の last_commit 時間に大きな差が生じる可能性のある状況は他にもあります。There are also conditions that could cause the difference between last_commit time on the secondary and on the primary database to become large. 例:E.g. 長時間変更がなかったプライマリでコミットが行われた場合、差異は非常に大きくなりますが、すぐに 0 に戻ります。if a commit is made on the primary after a long period of no changes, the difference will jump up to a large value before quickly returning to 0. これらの 2 つの値の差が大きい状況が長時間続く場合は、エラーの状態にあると考えられます。Consider it an error condition when the difference between these two values remains large for a long time.

アクティブ geo レプリケーションのプログラムでの管理Programmatically managing active geo-replication

前に説明したように、アクティブ geo レプリケーションは、Azure PowerShell および REST API を使用してプログラムによって管理することもできます。As discussed previously, 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.

T-SQL: 単一データベースおよびプールされたデータベースのフェールオーバーを管理します。T-SQL: Manage failover of single and pooled databases

重要

これらの Transact-SQL コマンドは、アクティブ geo レプリケーションにのみ適用され、フェールオーバー グループには適用されません。These Transact-SQL commands only apply to active geo-replication and do not apply to failover groups. そのため、それらのコマンドは、フェールオーバー グループしかサポートしていない Managed Instance にも適用されません。As such, they also do not apply to Managed Instances, as they only support failover groups.

commandCommand 説明Description
ALTER DATABASEALTER 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 DATABASEALTER 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 DATABASEALTER 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_linkssys.geo_replication_links Azure SQL Database サーバー上の各データベースの、既存のレプリケーション リンクの情報をすべて返します。Returns information about all existing replication links for each database on the Azure SQL Database server.
sys.dm_geo_replication_link_statussys.dm_geo_replication_link_status 最新のレプリケーション時刻、最後のレプリケーションの遅延、および指定された SQL データベースのレプリケーション リンクに関する他の情報を取得します。Gets the last replication time, last replication lag, and other information about the replication link for a given SQL database.
sys.dm_operation_statussys.dm_operation_status レプリケーション リンクの状態を含むすべてのデータベース操作の状態が表示されます。Shows the status for all database operations including the status of the replication links.
sp_wait_for_database_copy_syncsp_wait_for_database_copy_sync コミットされたすべてのトランザクションがレプリケートされ、アクティブ セカンダリ データベースによって認識されるまで、アプリケーションが待機状態になります。causes the application to wait until all committed transactions are replicated and acknowledged by the active secondary database.

PowerShell:単一データベースおよびプールされたデータベースのフェールオーバーを管理します。PowerShell: Manage failover of single and pooled databases

注意

この記事は、新しい Azure PowerShell Az モジュールを使用するために更新されました。This article has been updated to use the new Azure PowerShell Az module. AzureRM モジュールはまだ使用でき、少なくとも 2020 年 12 月までは引き続きバグ修正が行われます。You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Az モジュールと AzureRM の互換性の詳細については、「Introducing the new Azure PowerShell Az module (新しい Azure PowerShell Az モジュールの概要)」を参照してください。To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Az モジュールのインストール手順については、Azure PowerShell のインストールを参照してください。For Az module installation instructions, see Install Azure PowerShell.

重要

PowerShell Azure Resource Manager モジュールは Azure SQL Database で引き続きサポートされますが、今後の開発はすべて Az.Sql モジュールを対象に行われます。The PowerShell Azure Resource Manager module is still supported by Azure SQL Database, but all future development is for the Az.Sql module. これらのコマンドレットについては、「AzureRM.Sql」を参照してください。For these cmdlets, see AzureRM.Sql. Az モジュールと AzureRm モジュールのコマンドの引数は実質的に同じです。The arguments for the commands in the Az module and in the AzureRm modules are substantially identical.

コマンドレットCmdlet 説明Description
Get-AzSqlDatabaseGet-AzSqlDatabase 1 つまたは複数のデータベースを取得します。Gets one or more databases.
New-AzSqlDatabaseSecondaryNew-AzSqlDatabaseSecondary 既存のデータベースのセカンダリ データベースを作成し、データ レプリケーションを開始します。Creates a secondary database for an existing database and starts data replication.
Set-AzSqlDatabaseSecondarySet-AzSqlDatabaseSecondary セカンダリ データベースをプライマリに切り替えて、フェールオーバーを開始します。Switches a secondary database to be primary to initiate failover.
Remove-AzSqlDatabaseSecondaryRemove-AzSqlDatabaseSecondary SQL Database と指定されたセカンダリ データベース間でのデータ レプリケーションを終了します。Terminates data replication between a SQL Database and the specified secondary database.
Get-AzSqlDatabaseReplicationLinkGet-AzSqlDatabaseReplicationLink Azure SQL Database とリソース グループまたは SQL Server 間の geo レプリケーション リンクを取得します。Gets the geo-replication links between an Azure SQL Database and a resource group or SQL Server.

REST API:単一データベースおよびプールされたデータベースのフェールオーバーを管理します。REST API: Manage failover of single and pooled databases

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 secondary database is primary by failing over from the current primary database. このオプションは、Managed Instance に対してはサポートされていません。This option is not supported for Managed Instance.
Set Secondary Database as Primary (計画されていないフェールオーバー)Set Secondary Database as Primary (Unplanned Failover) 現在のプライマリ データベースからフェールオーバーして、どのセカンダリ データベースがプライマリかを設定します。Sets which secondary database is primary by failing over from the current primary database. この操作を行うとデータが失われる可能性があります。This operation might result in data loss. このオプションは、Managed Instance に対してはサポートされていません。This option is not supported for Managed Instance.
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. このオプションは、Managed Instance に対してはサポートされていません。This option is not supported for Managed Instance.
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.

次の手順Next steps