AlwaysOn 可用性グループの概要 (SQL Server)Overview of Always On Availability Groups (SQL Server)

適用対象: ○SQL Server XAzure SQL Database XAzure SQL Data Warehouse XParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

このトピックでは、 Always On 可用性グループAlways On availability groups の概念について説明します。これは、 SQL Server 2017SQL Server 2017での 1 つ以上の可用性グループの構成と管理において重要です。This topic introduces the Always On 可用性グループAlways On availability groups concepts that are central for configuring and managing one or more availability groups in SQL Server 2017SQL Server 2017. 可用性グループの利点の要約および Always On 可用性グループAlways On availability groups用語の概要については、「AlwaysOn 可用性グループ (SQL Server)」をご覧ください。For a summary of the benefits offered by availability groups and an overview of Always On 可用性グループAlways On availability groups terminology, see Always On Availability Groups (SQL Server).

可用性グループは、可用性データベースとして知られる、個別のユーザー データベース セットのための複製環境をサポートします。An availability group supports a replicated environment for a discrete set of user databases, known as availability databases. 高可用性 (HA) または読み取りスケールの可用性グループを作成できます。You can create an availability group for high availability (HA) or for read-scale. HA グループは、共にフェールオーバーするデータベースのグループです。An HA availability group is a group of databases that fail over together. 読み取りスケール可用性グループは、読み取り専用ワークロードのために、SQL Server の他のインスタンスにコピーされるデータベースのグループです。A read-scale availability group is a group of databases that are copied to other instances of SQL Server for read-only workload. 可用性グループは、プライマリ データベースの 1 セットをサポートし、1 ~ 8 セットの対応するセカンダリ データベースをサポートします。An availability group supports one set of primary databases and one to eight sets of corresponding secondary databases. セカンダリ データベースは、バックアップではありませんSecondary databases are not backups. 継続してデータベースおよびそのトランザクション ログを定期的にバックアップします。Continue to back up your databases and their transaction logs on a regular basis.

ヒント

プライマリ データベースのバックアップの種類を作成できます。You can create any type of backup of a primary database. または、セカンダリ データベースのログ バックアップとコピーのみの完全バックアップを作成できます。Alternatively, you can create log backups and copy-only full backups of secondary databases. 詳細については、「アクティブなセカンダリ:セカンダリ レプリカでのバックアップ (Always On 可用性グループ)」を参照してください。For more information, see Active Secondaries: Backup on Secondary Replicas (Always On Availability Groups).

可用性データベースの各セットは、 可用性レプリカによりホストされます。Each set of availability database is hosted by an availability replica. 可用性レプリカには、2 つの種類があります。1 つは、単一の プライマリ レプリカで、Two types of availability replicas exist: a single primary replica. プライマリ データベースをホストします。もう 1 種類は、1 ~ 8 つの セカンダリ レプリカで、それぞれがセカンダリ データベースのセットをホストし、可用性グループの潜在的なフェールオーバー ターゲットとして機能します。which hosts the primary databases, and one to eight secondary replicas, each of which hosts a set of secondary databases and serves as a potential failover targets for the availability group. 可用性グループは、可用性レプリカのレベルでフェールオーバーします。An availability group fails over at the level of an availability replica. 可用性レプリカでは、データセット レベル (1 つの可用性グループのデータベースのセット) でのみ冗長性が提供されます。An availability replica provides redundancy only at the database level-for the set of databases in one availability group. データベースの問題 (たとえば、データ ファイルの損失やトランザクション ログの破損による障害が疑われる場合など) が発生してもフェールオーバーは行われません。Failovers are not caused by database issues such as a database becoming suspect due to a loss of a data file or corruption of a transaction log.

プライマリ レプリカは、クライアントからプライマリ データベースへの読み取り/書き込み接続を可能にします。The primary replica makes the primary databases available for read-write connections from clients. プライマリ レプリカは、各プライマリ データベースのトランザクション ログ レコードをすべてのセカンダリ データベースに送信します。The primary replica sends transaction log records of each primary database to every secondary database. データの同期と呼ばれているこのプロセスはデータベース レベルで行われます。This process - known as data synchronization - occurs at the database level. すべてのセカンダリ レプリカは、トランザクション ログ レコードをキャッシュし (ログの書き込み )、それを対応するセカンダリ データベースに適用します。Every secondary replica caches the transaction log records (hardens the log) and then applies them to its corresponding secondary database. データの同期は、プライマリ データベースと接続されているそれぞれのセカンダリ データベースとの間で、他のデータベースとは無関係に発生します。Data synchronization occurs between the primary database and each connected secondary database, independently of the other databases. したがって、セカンダリ データベースの中断や障害が発生した場合でも他のセカンダリ データベースはその影響を受けません。また、プライマリ データベースの中断や障害が発生した場合でも他のプライマリ データベースはその影響を受けません。Therefore, a secondary database can be suspended or fail without affecting other secondary databases, and a primary database can be suspended or fail without affecting other primary databases.

必要に応じて、1 つ以上のセカンダリ レプリカでセカンダリ データベースへの読み取り専用アクセスをサポートするように構成できます。また、任意のセカンダリ レプリカでセカンダリ データベースのバックアップを許容するように構成できます。Optionally, you can configure one or more secondary replicas to support read-only access to secondary databases, and you can configure any secondary replica to permit backups on secondary databases.

SQL Server 2017 では、可用性グループのために 2 つの異なるアーキテクチャが導入されています。SQL Server 2017 introduces two different architectures for availability groups. Always On 可用性グループは、高可用性、ディザスター リカバリー、読み取りスケール分散を提供します。Always On availability groups provide high availability, disaster recovery, and read-scale balancing. これらの可用性グループでは、クラスター マネージャーが必要です。These availability groups require a cluster manager. Windows では、フェールオーバー クラスタリングがクラスター マネージャーを提供します。In Windows, failover clustering provides the cluster manager. Linux では、Pacemaker を使用できます。In Linux, you can use Pacemaker. その他のアーキテクチャは読み取りスケール可用性グループです。The other architecture is a read-scale availability group. 読み取りスケール可用性グループは、読み取り専用ワークロードのためのレプリカを提供しますが、高可用性は提供しません。A read scale availability group provides replicas for read-only workloads but not high availability. 読み取りスケール可用性グループには、クラスター マネージャーがありません。In a read-scale availability group there is no cluster manager.

Windows の HA のために Always On 可用性グループAlways On availability groups を配置するには、Windows Server フェールオーバー クラスター (WSFC) が必要です。Deploying Always On 可用性グループAlways On availability groups for HA on Windows requires a Windows Server Failover Cluster(WSFC). 指定された可用性グループの各可用性レプリカは、同一の WSFC の異なるノード上に存在する必要があります。Each availability replica of a given availability group must reside on a different node of the same WSFC. 唯一の例外は、別の WSFC クラスターに移行するときに、可用性グループは一時的に 2 つのクラスターにまたがることができるという点です。The only exception is that while being migrated to another WSFC cluster, an availability group can temporarily straddle two clusters.

注意

Linux の可用性グループについては、SQL Server on Linux の Always On 可用性グループに関するページを参照してください。For information about availability groups on Linux, see Always On availability group for SQL Server on Linux.

HA 構成では、作成されたすべての可用性グループに対してクラスター ロールが作成されます。In an HA configuration, a cluster role is created for every availability group that you create. WSFC クラスターは、このロールを監視し、プライマリ レプリカの正常性を評価します。The WSFC cluster monitors this role to evaluate the health of the primary replica. Always On 可用性グループAlways On availability groups のクォーラムは、クラスター ノードが可用性レプリカをホストしているかどうかに関係なく、WSFC クラスター内のすべてのノードに基づきます。The quorum for Always On 可用性グループAlways On availability groups is based on all nodes in the WSFC cluster regardless of whether a given cluster node hosts any availability replicas. データベース ミラーリングとは異なり、 Always On 可用性グループAlways On availability groupsには監視ロールはありません。In contrast to database mirroring, there is no witness role in Always On 可用性グループAlways On availability groups.

注意

SQL Server AlwaysOn コンポーネントと WSFC クラスターとの関係については、「Windows Server フェールオーバー クラスタリング (WSFC) と SQL Server」をご覧ください。For information about the relationship of SQL Server Always On components to the WSFC cluster, see Windows Server Failover Clustering (WSFC) with SQL Server.

次の図は、1 つのプライマリ レプリカと 4 つのセカンダリ レプリカを含む可用性グループを示しています。The following illustration shows an availability group that contains one primary replica and four secondary replicas. 最大 8 つのセカンダリ レプリカ (1 つのプライマリ レプリカと 2 つの同期コミット セカンダリ レプリカ) がサポートされています。Up to eight secondary replicas are supported, including one primary replica and two synchronous-commit secondary replicas.

5 つのレプリカを使用する可用性グループAvailability group with five replicas

Availability DatabasesAvailability Databases

可用性グループに追加するデータベースは、オンラインの読み取り/書き込みデータベースであることが必要であり、プライマリ レプリカをホストするサーバー インスタンスに置かれている必要があります。To add a database to an availability group, the database must be an online, read-write database that exists on the server instance that hosts the primary replica. 追加されたデータベースは、プライマリ データベースとして可用性グループに参加しますが、引き続きクライアントから使用できます。When you add a database, it joins the availability group as a primary database, while remaining available to clients. 新しいプライマリ データベースのバックアップが、セカンダリ レプリカをホストするサーバー インスタンスに復元されない限り (RESTORE WITH NORECOVERY を使用します)、対応するセカンダリ データベースは存在しません。No corresponding secondary database exists until backups of the new primary database are restored to the server instance that hosts the secondary replica (using RESTORE WITH NORECOVERY). 新しいセカンダリ データベースは、可用性グループに参加するまでは RESTORING 状態です。The new secondary database is in the RESTORING state until it is joined to the availability group. 詳細については、「 AlwaysOn セカンダリ データベース上のデータ移動の開始 (SQL Server)」を参照してください。For more information, see Start Data Movement on an Always On Secondary Database (SQL Server).

可用性グループに参加すると、セカンダリ データベースは ONLINE 状態になり、対応するプライマリ データベースとのデータ同期が開始されます。Joining places the secondary database into the ONLINE state and initiates data synchronization with the corresponding primary database. データ同期 は、プライマリ データベースへの変更をセカンダリ データベースに再現するプロセスです。Data synchronization is the process by which changes to a primary database are reproduced on a secondary database. データ同期では、プライマリ データベースがトランザクション ログ レコードをセカンダリ データベースに送信します。Data synchronization involves the primary database sending transaction log records to the secondary database.

重要

可用性データベースは、 、PowerShell、および SQL Server 管理オブジェクト (SMO) の名前では、 データベース レプリカ Transact-SQLTransact-SQLと呼ばれることがあります。An availability database is sometimes called a database replica in Transact-SQLTransact-SQL, PowerShell, and SQL Server Management Objects (SMO) names. たとえば、可用性データベースに関する情報を返す AlwaysOn 動的管理ビューの名前では、 sys.dm_hadr_database_replica_statessys.dm_hadr_database_replica_cluster_statesのように、"データベース レプリカ (database replica)" という語が使用されています。For example, the term "database replica" is used in the names of the Always On dynamic management views that return information about availability databases: sys.dm_hadr_database_replica_states and sys.dm_hadr_database_replica_cluster_states. ただし、SQL Server オンライン ブックでは、"レプリカ" という用語は一般に可用性レプリカを指します。However, in SQL Server Books Online, the term "replica" typically refers to availability replicas. たとえば、"プライマリ レプリカ" と "セカンダリ レプリカ" は、常に可用性レプリカを指します。For example, "primary replica" and "secondary replica" always refer to availability replicas.

可用性レプリカAvailability Replicas

各可用性グループは、可用性レプリカと呼ばれる 2 つ以上のフェールオーバー パートナーを定義します。Each availability group defines a set of two or more failover partners known as availability replicas. 可用性レプリカ は、可用性グループのコンポーネントです。Availability replicas are components of the availability group. 各可用性レプリカは、可用性グループ内の可用性データベースのコピーをホストします。Each availability replica hosts a copy of the availability databases in the availability group. 各可用性グループで、個々の可用性レプリカは、1 つの WSFC クラスターの別々のノード上に存在する SQL ServerSQL Server の個々のインスタンスによってホストされる必要があります。For a given availability group, the availability replicas must be hosted by separate instances of SQL ServerSQL Server residing on different nodes of a WSFC cluster. これらのサーバー インスタンスそれぞれで、AlwaysOn を有効にする必要があります。Each of these server instances must be enabled for Always On.

指定したインスタンスで、1 つの可用性グループにつき 1 つだけ可用性レプリカをホストすることができます。A given instance can host only one availability replica per availability group. ただし、各インスタンスを多数の可用性グループに使用することはできます。However, each instance can be used for many availability groups. 指定したインスタンスは、スタンドアロン インスタンスまたは SQL ServerSQL Server フェールオーバー クラスター インスタンス (FCI) として使用できます。A given instance can be either a stand-alone instance or a SQL ServerSQL Server failover cluster instance (FCI). サーバー レベルの冗長性が必要な場合は、フェールオーバー クラスター インスタンスを使用します。If you require server-level redundancy, use Failover Cluster Instances.

すべての可用性レプリカには、初期ロールとして、プライマリ ロールまたはセカンダリ ロールが割り当てられています。これが、レプリカの可用性データベースによって継承されます。Every availability replica is assigned an initial role-either the primary role or the secondary role, which is inherited by the availability databases of that replica. 指定されたレプリカのロールにより、読み取り/書き込みデータベースと読み取り専用のデータベースのどちらがホストされるかが決定されます。The role of a given replica determines whether it hosts read-write databases or read-only databases. プライマリ レプリカと呼ばれる 1 つのレプリカには、プライマリ ロールが割り当てられ、 プライマリ データベースと呼ばれる読み取り/書き込みデータベースをホストします。One replica, known as the primary replica, is assigned the primary role and hosts read-write databases, which are known as primary databases. それ以外の 1 つ以上のレプリカは セカンダリ レプリカと呼ばれ、セカンダリ ロールが割り当てられます。At least one other replica, known as a secondary replica, is assigned the secondary role. セカンダリ レプリカは、セカンダリ データベースと呼ばれる読み取り専用のデータベースをホストします。A secondary replica hosts read-only databases, known as secondary databases.

注意

フェールオーバー中など、可用性レプリカのロールが不確定である場合、そのデータベースは一時的に NOT SYNCHRONIZING 状態になります。When the role of an availability replica is indeterminate, such as during a failover, its databases are temporarily in a NOT SYNCHRONIZING state. 可用性レプリカのロールが解決されるまで、それらのロールは RESOLVING に設定されます。Their role is set to RESOLVING until the role of the availability replica has resolved. 可用性レプリカがプライマリ ロールに解決された場合、そのデータベースはプライマリ データベースになります。If an availability replica resolves to the primary role, its databases become the primary databases. 可用性レプリカがセカンダリ ロールに解決された場合、そのデータベースはセカンダリ データベースになります。If an availability replica resolves to the secondary role, its databases become secondary databases.

可用性モードAvailability Modes

可用性モードは、各可用性レプリカのプロパティです。The availability mode is a property of each availability replica. 可用性モードによって、特定のセカンダリ レプリカがディスクにトランザクション ログ レコードを書き込む (ログ書き込み) まで、プライマリ レプリカによるデータベースへのトランザクションのコミットを待機するかどうかが決定されます。The availability mode determines whether the primary replica waits to commit transactions on a database until a given secondary replica has written the transaction log records to disk (hardened the log). Always On 可用性グループAlways On availability groups は、非同期コミット モード同期コミット モードという 2 種類の可用性モードをサポートします。supports two availability modes-asynchronous-commit mode and synchronous-commit mode.

  • Asynchronous-commit modeAsynchronous-commit mode

    この可用性モードを使用する可用性レプリカは、非同期コミット レプリカと呼ばれます。An availability replica that uses this availability mode is known as an asynchronous-commit replica. 非同期コミット モードでは、非同期コミット セカンダリ レプリカによりログが書き込まれことが確認されるまで待機せずに、プライマリ レプリカがトランザクションをコミットします。Under asynchronous-commit mode, the primary replica commits transactions without waiting for acknowledgement that an asynchronous-commit secondary replica has hardened the log. 非同期コミット モードでは、セカンダリ データベースでのトランザクションの遅延が最小になりますが、セカンダリ データベースがプライマリ データベースよりも遅延する場合があるため、一部のデータが失われる可能性があります。Asynchronous-commit mode minimizes transaction latency on the secondary databases but allows them to lag behind the primary databases, making some data loss possible.

  • Synchronous-commit modeSynchronous-commit mode

    この可用性モードを使用する可用性レプリカは、 同期コミット レプリカと呼ばれます。An availability replica that uses this availability mode is known as a synchronous-commit replica. 同期コミット モードの場合、同期コミット プライマリ レプリカは、同期コミット セカンダリ レプリカによるログ書き込みが確認されるまで待機した後で、トランザクションをコミットします。Under synchronous-commit mode, before committing transactions, a synchronous-commit primary replica waits for a synchronous-commit secondary replica to acknowledge that it has finished hardening the log. 同期コミット モードでは、特定のセカンダリ データベースがプライマリ データベースに 1 回同期されれば、コミットされたトランザクションが完全に保護されることが保証されます。Synchronous-commit mode ensures that once a given secondary database is synchronized with the primary database, committed transactions are fully protected. この保護の欠点は、トランザクションの遅延が増加することです。This protection comes at the cost of increased transaction latency.

詳細については、「 可用性モード (AlwaysOn 可用性グループ)での 1 つ以上の可用性グループの構成と管理において重要です。For more information, see Availability Modes (Always On Availability Groups).

フェールオーバーの種類Types of Failover

プライマリ レプリカとセカンダリ レプリカとのセッションのコンテキスト内で、プライマリ ロールとセカンダリ ロールが フェールオーバーと呼ばれるプロセスで交換されることがあります。Within the context of a session between the primary replica and a secondary replica, the primary and secondary roles are potentially interchangeable in a process known as failover. フェールオーバー中に、対象のセカンダリ レプリカがプライマリ ロールに移行し、新しいプライマリ レプリカになります。During a failover the target secondary replica transitions to the primary role, becoming the new primary replica. 新しいプライマリ レプリカのデータベースがプライマリ データベースとしてオンラインになります。クライアント アプリケーションから、これらのデータベースに接続できるようになります。The new primary replica brings its databases online as the primary databases, and client applications can connect to them. 元のプライマリ レプリカは使用可能になるとセカンダリ ロールに移行し、セカンダリ レプリカになりますWhen the former primary replica is available, it transitions to the secondary role, becoming a secondary replica. 元のプライマリ データベースはセカンダリ データベースになり、データ同期が再開されます。The former primary databases become secondary databases and data synchronization resumes.

フェールオーバーには、自動、手動、および強制 (データ損失の可能性あり) という 3 つの形式があります。Three forms of failover exist-automatic, manual, and forced (with possible data loss). 特定のセカンダリ レプリカでサポートされるフェールオーバーの形式は、可用性モードによって決まります。同期コミット モードでは、プライマリ レプリカのフェールオーバー モードおよび対象のセカンダリ レプリカによって決まります。次に例を示します。The form or forms of failover supported by a given secondary replica depends on its availability mode, and, for synchronous-commit mode, on the failover mode on the primary replica and target secondary replica, as follows.

  • 同期コミット モードでは、対象のセカンダリ レプリカが現在 avt1 と同期されている場合、計画的な手動フェールオーバー自動フェールオーバーという 2 種類のフェールオーバーがサポートされます。Synchronous-commit mode supports two forms of failover-planned manual failover and automatic failover, if the target secondary replica is currently synchronized with the avt1. これらのフェールオーバーの形式のサポートは、フェールオーバー パートナーの フェールオーバー モード プロパティ の設定によって決まります。The support for these forms of failover depends on the setting of the failover mode property on the failover partners. プライマリ レプリカとセカンダリ レプリカのどちらかのフェールオーバー モードが "手動" に設定されている場合、そのセカンダリ レプリカに対しては手動フェールオーバーのみがサポートされます。If failover mode is set to "manual" on either the primary or secondary replica, only manual failover is supported for that secondary replica. プライマリ レプリカとセカンダリ レプリカのどちらのフェールオーバー モードも "自動" に設定されている場合、そのセカンダリ レプリカでは自動フェールオーバーと手動フェールオーバーの両方がサポートされます。If failover mode is set to "automatic" on both the primary and secondary replicas, both automatic and manual failover are supported on that secondary replica.

    • 計画的な手動フェールオーバー (データ損失なし)Planned manual failover (without data loss)

      データベース管理者がフェールオーバー コマンドを発行した後に手動フェールオーバーが開始され、同期されたセカンダリ レプリカがプライマリ ロールに移行し (データ保護の保証あり)、プライマリ レプリカはセカンダリ ロールに移行します。A manual failover occurs after a database administrator issues a failover command and causes a synchronized secondary replica to transition to the primary role (with guaranteed data protection) and the primary replica to transition to the secondary role. 手動フェールオーバーには、プライマリ レプリカと対象のセカンダリ レプリカの両方が同期コミット モードで実行されていることが必要です。また、セカンダリ レプリカが既に同期されている必要があります。A manual failover requires that both the primary replica and the target secondary replica are running under synchronous-commit mode, and the secondary replica must already be synchronized.

    • 自動フェールオーバー (データ損失なし)Automatic failover (without data loss)

      エラーが発生すると、自動フェールオーバーが開始されて、同期されたセカンダリ レプリカがプライマリ ロールに移行します (データ保護が保証されます)。An automatic failover occurs in response to a failure that causes a synchronized secondary replica to transition to the primary role (with guaranteed data protection). 元のプライマリ レプリカは、使用可能になるとセカンダリ ロールに移行します。When the former primary replica becomes available, it transitions to the secondary role. 自動フェールオーバーでは、プライマリ レプリカと対象のセカンダリ レプリカの両方が同期コミット モードで実行されていることが必要です。また、フェールオーバー モードが "自動" に設定されている必要があります。Automatic failover requires that both the primary replica and the target secondary replica are running under synchronous-commit mode with the failover mode set to "Automatic". さらに、セカンダリ レプリカが既に同期され、WSFC クォーラムを持ち、可用性グループの 柔軟なフェールオーバー ポリシーで指定された条件を満たしている必要があります。In addition, the secondary replica must already be synchronized, have WSFC quorum, and meet the conditions specified by the flexible failover policyof the availability group.

      重要

      SQL Server フェールオーバー クラスター インスタンス (FCI) は可用性グループによる自動フェールオーバーをサポートしないため、FCI によってホストされる可用性レプリカは手動フェールオーバー用にのみ構成できます。SQL Server Failover Cluster Instances (FCIs) do not support automatic failover by availability groups, so any availability replica that is hosted by an FCI can only be configured for manual failover.

    注意

    同期されたセカンダリ レプリカ上で強制フェールオーバー コマンドを発行した場合、セカンダリ レプリカは計画された手動フェールオーバーの場合と同様に動作します。Note that if you issue a forced failover command on a synchronized secondary replica, the secondary replica behaves the same as for a planned manual failover.

  • 非同期コミット モードで使用されるフェールオーバーは、 強制フェールオーバーと通常呼ばれる強制手動フェールオーバーのみです (データ損失の可能性あり)。Under asynchronous-commit mode, the only form of failover is forced manual failover (with possible data loss), typically called forced failover. 強制フェールオーバーは手動のみで開始できるため、手動フェールオーバーの一種と見なされます。Forced failover is considered a form of manual failover because it can only be initiated manually. 強制フェールオーバーは、障害復旧オプションです。Forced failover is a disaster recovery option. 対象のセカンダリ レプリカがプライマリ レプリカに同期されない場合に使用できる唯一のフェールオーバー形式です。It is the only form of failover that is possible when the target secondary replica is not synchronized with the primary replica.

詳細については、「 フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)での 1 つ以上の可用性グループの構成と管理において重要です。For more information, see Failover and Failover Modes (Always On Availability Groups).

クライアント接続Client Connections

可用性グループ リスナーを作成することによって、特定の可用性グループのプライマリ レプリカへのクライアント接続を提供できます。You can provide client connectivity to the primary replica of a given availability group by creating an availability group listener. 可用性グループ リスナー には、クライアント接続を適切な可用性レプリカに送るために特定の可用性グループにアタッチされる一連のリソースが用意されています。An availability group listener provides a set of resources that is attached to a given availability group to direct client connections to the appropriate availability replica.

可用性グループ リスナーは、仮想ネットワーク名 (VNN) として機能する一意の DNS 名、1 つ以上の仮想 IP アドレス (VIP)、および TCP ポート番号に関連付けられています。An availability group listener is associated with a unique DNS name that serves as a virtual network name (VNN), one or more virtual IP addresses (VIPs), and a TCP port number. 詳細については、「 可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)での 1 つ以上の可用性グループの構成と管理において重要です。For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

ヒント

可用性グループに 2 つしか可用性レプリカが存在せず、なおかつ、その可用性グループが、セカンダリ レプリカへの読み取りアクセスを許可する設定になっていない場合、クライアントは、 データベース ミラーリングの接続文字列を使用してプライマリ レプリカに接続できます。If an availability group possesses only two availability replicas and is not configured to allow read-access to the secondary replica, clients can connect to the primary replica by using a database mirroring connection string. この方法は、データベースをデータベース ミラーリングから Always On 可用性グループAlways On availability groupsに移行した後で、一時的に役に立つ場合があります。This approach can be useful temporarily after you migrate a database from database mirroring to Always On 可用性グループAlways On availability groups. 他のセカンダリ レプリカを追加する前に、可用性グループの可用性グループ リスナーを作成し、そのリスナーのネットワーク名を使用するようにアプリケーションを更新する必要があります。Before you add additional secondary replicas, you will need to create an availability group listener the availability group and update your applications to use the network name of the listener.

アクティブなセカンダリ レプリカActive Secondary Replicas

Always On 可用性グループAlways On availability groups は、アクティブなセカンダリ レプリカをサポートします。supports active secondary replicas. アクティブなセカンダリ機能では以下をサポートしています。Active secondary capabilities include support for:

  • セカンダリ レプリカでのバックアップ操作の実行Performing backup operations on secondary replicas

    セカンダリ レプリカでは、ログ バックアップと、データベース全体、ファイル、またはファイル グループの コピーのみの バックアップを実行できます。The secondary replicas support performing log backups and copy-only backups of a full database, file, or filegroup. 可用性グループを構成して、バックアップを実行する優先順位を指定できます。You can configure the availability group to specify a preference for where backups should be performed. 優先順位は SQL Server によって適用されるものではないので、アドホック バックアップには影響がないことを理解しておくことが重要です。It is important to understand that the preference is not enforced by SQL Server, so it has no impact on ad-hoc backups. この優先順位の解釈は、特定の可用性グループの各データベースに対するバックアップ ジョブのスクリプトでのロジックに依存します (ある場合)。The interpretation of this preference depends on the logic, if any, that you script into your back jobs for each of the databases in a given availability group. 同じ可用性グループ内の個々の可用性レプリカで実行されるバックアップの優先順位を指定できます。For an individual availability replica, you can specify your priority for performing backups on this replica relative to the other replicas in the same availability group. 詳細については、「アクティブなセカンダリ:セカンダリ レプリカでのバックアップ (Always On 可用性グループ)」を参照してください。For more information, see Active Secondaries: Backup on Secondary Replicas (Always On Availability Groups).

  • 1 つ以上のセカンダリ レプリカへの読み取り専用アクセス (読み取り可能なセカンダリ レプリカ)Read-only access to one or more secondary replicas (readable secondary replicas)

    セカンダリ ロールを実行するときに、ローカル データベースへの読み取り専用アクセスを許可するように可用性レプリカを構成できます (ただし、一部の操作は完全にはサポートされていません)。Any availability replica can be configured to allow read-only access to its local databases when performing the secondary role, though some operations are not fully supported. また、読み取り専用ワークロードがプライマリ レプリカで実行されないようにする場合は、プライマリ ロールで実行されているときに読み取り/書き込みアクセスのみを許可するようにレプリカを構成できます。Also, if you would like to prevent read-only workloads from running on the primary replica, you can configure the replicas to allow only read-write access when running under the primary role. 詳細については、「アクティブなセカンダリ:読み取り可能なセカンダリ レプリカ (Always On 可用性グループ)」を参照してください。For more information, see Active Secondaries: Readable Secondary Replicas (Always On Availability Groups).

    可用性グループに、現在、可用性グループ リスナーと 1 つ以上の読み取り可能なセカンダリ レプリカが存在する場合、 SQL ServerSQL Server は読み取りを目的とした接続要求をそれらのいずれかにルーティングできます (読み取り専用ルーティング)。If an availability group currently possesses an availability group listener and one or more readable secondary replicas, SQL ServerSQL Server can route read-intent connection requests to one of them (read-only routing). 詳細については、「 可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)での 1 つ以上の可用性グループの構成と管理において重要です。For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).

セッション タイムアウト期間Session-Timeout Period

セッション タイムアウト期間は、可用性レプリカのプロパティで、他の可用性レプリカとの接続を閉じるまでに非アクティブに保持できる時間を決定します。The session-timeout period is an availability-replica property that determines how long connection with another availability replica can remain inactive before the connection is closed. プライマリ レプリカとセカンダリ レプリカは、アクティブであることを通知するために互いに ping を実行します。The primary and secondary replicas ping each other to signal that they are still active. 他のレプリカからタイムアウト期間内に ping を受信した場合は、その接続がまだ開いており、サーバー インスタンスが通信していることを示します。Receiving a ping from the other replica during the timeout period indicates that the connection is still open and that the server instances are communicating. 可用性レプリカは、ping を受信すると、接続のセッション タイムアウト カウンターをリセットします。On receiving a ping, an availability replica resets its session-timeout counter on that connection.

セッション タイムアウト期間を設定することにより、相手レプリカからの ping を受信するまで無期限に待機することがなくなります。The session-timeout period prevents either replica from waiting indefinitely to receive a ping from the other replica. セッション タイムアウト期間中に相手のレプリカから ping を受信しなかった場合、レプリカはタイムアウトします。レプリカの接続は閉じられ、タイムアウトしたレプリカは DISCONNECTED 状態になります。If no ping is received from the other replica within the session-timeout period, the replica times out. Its connection is closed, and the timed-out replica enters the DISCONNECTED state. 切断されたレプリカが同期コミット モード用に構成されている場合でも、トランザクションは、そのレプリカが再接続および再同期するのを待機しません。Even if a disconnected replica is configured for synchronous-commit mode, transactions will not wait for that replica to reconnect and resynchronize.

各可用性レプリカの既定のセッション タイムアウト期間は 10 秒です。The default session-timeout period for each availability replica is 10 seconds. この値はユーザーが構成でき、最小値は 5 秒です。This value is user-configurable, with a minimum of 5 seconds. 通常は、タイムアウト期間を 10 秒以上にしておくことをお勧めします。Generally, we recommend that you keep the time-out period at 10 seconds or greater. 値を 10 秒未満に設定すると、負荷の高いシステムで誤認エラーが示される可能性があります。Setting the value to less than 10 seconds creates the possibility of a heavily loaded system declaring a false failure.

注意

解決中のロールでは、ping が発生しないため、セッション タイムアウト期間は適用されません。In the resolving role, the session-timeout period does not apply because pinging does not occur.

ページの自動修復Automatic Page Repair

各可用性レプリカでは、ローカル データベースに破損ページがあると、データ ページの読み取りを妨げるエラーを解決して自動的に復旧しようとします。Each availability replica tries to automatically recover from corrupted pages on a local database by resolving certain types of errors that prevent reading a data page. セカンダリ レプリカがページを読み取ることができない場合、プライマリ レプリカに対してページの新しいコピーを要求します。If a secondary replica cannot read a page, the replica requests a fresh copy of the page from the primary replica. プライマリ レプリカがページを読み取ることができない場合、すべてのセカンダリ レプリカに新しいコピーの要求をブロードキャストし、最初に応答したレプリカからページを取得します。If the primary replica cannot read a page, the replica broadcasts a request for a fresh copy to all the secondary replicas and gets the page from the first to respond. 要求が受け入れられ、新しいコピーを取得できた場合は、読み取り不可能なページがそのコピーに置き換えられます。通常、これによりエラーは解決します。If this request succeeds, the unreadable page is replaced by the copy, which usually resolves the error.

詳細については、「ページの自動修復 (可用性グループ:データベース ミラーリング)」を参照してください。For more information, see Automatic Page Repair (Availability Groups: Database Mirroring).

関連タスクRelated Tasks

関連コンテンツRelated Content

参照See Also

可用性モード (AlwaysOn 可用性グループ) Availability Modes (Always On Availability Groups)
フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ) Failover and Failover Modes (Always On Availability Groups)
Always On 可用性グループの Transact-SQL ステートメントの概要 (SQL Server) Overview of Transact-SQL Statements for Always On Availability Groups (SQL Server)
Always On 可用性グループの PowerShell コマンドレットの概要 (SQL Server) Overview of PowerShell Cmdlets for Always On Availability Groups (SQL Server)
インメモリ OLTP データベースにおける高可用性のサポート High Availability Support for In-Memory OLTP databases
AlwaysOn 可用性グループの前提条件、制限事項、および推奨事項 (SQL Server) Prerequisites, Restrictions, and Recommendations for Always On Availability Groups (SQL Server)
可用性グループの作成と構成 (SQL Server) Creation and Configuration of Availability Groups (SQL Server)
アクティブなセカンダリ:読み取り可能なセカンダリ レプリカ (Always On 可用性グループ) Active Secondaries: Readable Secondary Replicas (Always On Availability Groups)
アクティブなセカンダリ:セカンダリ レプリカでのバックアップ (Always On 可用性グループ) Active Secondaries: Backup on Secondary Replicas (Always On Availability Groups)
可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server)