可用性モード (AlwaysOn 可用性グループ)Availability Modes (Always On Availability Groups)

適用対象:○SQL Server XAzure SQL DatabaseXAzure SQL Data Warehouse XParallel Data Warehouse THIS TOPIC APPLIES TO: yesSQL ServernoAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

Always On 可用性グループAlways On availability groups可用性モード は、可用性レプリカが同期コミット モードで動作できるかどうかを指定するレプリカのプロパティです。In Always On 可用性グループAlways On availability groups, the availability mode is a replica property that determines whether a given availability replica can run in synchronous-commit mode. 可用性レプリカごとに、可用性モードを同期コミット モード、非同期コミット モード、または構成のみモードとして構成する必要があります。For each availability replica, the availability mode must be configured for either synchronous-commit mode, asynchronous-commit, or configuration only mode. プライマリ レプリカが 非同期コミット モードで構成されている場合、プライマリ レプリカはセカンダリ レプリカによる受信トランザクション ログ レコードのディスクへの書き込みを ( ログ書き込み) 待機しません。If the primary replica is configured for asynchronous-commit mode, it does not wait for any secondary replica to write incoming transaction log records to disk (to harden the log). 特定のセカンダリ レプリカが非同期コミット モードで構成されている場合、プライマリ レプリカはそのセカンダリ レプリカによるログ書き込みを待機しません。If a given secondary replica is configured for asynchronous-commit mode, the primary replica does not wait for that secondary replica to harden the log. プライマリ レプリカとセカンダリ レプリカの両方が 同期コミット モードで構成されている場合、プライマリ レプリカはログが書き込まれたことをセカンダリ レプリカが確認するまで待機します (プライマリの セッション タイムアウト期間内に、セカンダリ レプリカがプライマリ レプリカに対する ping に失敗した場合を除きます)。If both the primary replica and a given secondary replica are both configured for synchronous-commit mode, the primary replica waits for the secondary replica to confirm that it has hardened the log (unless the secondary replica fails to ping the primary replica within the primary's session-timeout period).

注意

セカンダリ レプリカがプライマリのセッション タイムアウト期間を超えた場合、プライマリ レプリカはそのセカンダリ レプリカに対して一時的に非同期コミット モードに移行します。If primary's session-timeout period is exceeded by a secondary replica, the primary replica temporarily shifts into asynchronous-commit mode for that secondary replica. セカンダリ レプリカがプライマリ レプリカと再接続すると、同期コミット モードが再開されます。When the secondary replica reconnects with the primary replica, they resume synchronous-commit mode.

このトピックの内容In this Topic:

サポートされる可用性モードSupported Availability Modes

Always On 可用性グループAlways On availability groups は、次のように、非同期コミット モード、同期コミット モード、および構成のみモードの 3 種類の可用性モードをサポートします。 supports three availability modes—asynchronous-commit mode, synchronous-commit mode, and configuration only mode as follows:

  • 非同期コミット モード は、可用性レプリカが離れた距離に分散されている場合に正常に利用できる災害復旧ソリューションです。Asynchronous-commit mode is a disaster-recovery solution that works well when the availability replicas are distributed over considerable distances. すべてのセカンダリ レプリカが非同期コミット モードで実行されている場合、プライマリ レプリカは、いずれかのセカンダリ レプリカによりログが書き込まれるまで待機しません。If every secondary replica is running under asynchronous-commit mode, the primary replica does not wait for any of the secondary replicas to harden the log. ログ レコードがローカル ログ ファイルに書き込まれるとすぐに、プライマリ レプリカはクライアントにトランザクションの確認を送信します。Rather, immediately after writing the log record to the local log file, the primary replica sends the transaction confirmation to the client. プライマリ レプリカは、非同期コミット モードが構成されているセカンダリ レプリカに対して、トランザクションの遅延を最小限に抑えて実行されます。The primary replica runs with minimum transaction latency in relation to a secondary replica that is configured for asynchronous-commit mode. 現在のプライマリに非同期コミット可用性モードが構成されている場合、このプライマリは、セカンダリの個々の可用性モードの設定に関係なく、すべてのセカンダリ レプリカに対してトランザクションを非同期にコミットします。If the current primary is configured for asynchronous commit availability mode, it will commit transactions asynchronously for all secondary replicas regardless of their individual availability mode settings.

    詳細については、このトピックの「 非同期コミット可用性モード」を参照してください。For more information, see Asynchronous-Commit Availability Mode, later in this topic.

  • 同期コミット モード は、パフォーマンスよりも高可用性が重視され、トランザクションの遅延が増加するのが欠点です。Synchronous-commit mode emphasizes high availability over performance, at the cost of increased transaction latency. 同期コミット モードでは、セカンダリ レプリカでログがディスクに書き込まれるまで、トランザクションの確認はクライアントに送信されません。Under synchronous-commit mode, transactions wait to send the transaction confirmation to the client until the secondary replica has hardened the log to disk. セカンダリ データベースでデータの同期が開始されると、セカンダリ レプリカで、対応するプライマリ データベースから受信したログ レコードの適用が開始されます。When data synchronization begins on a secondary database, the secondary replica begins applying incoming log records from the corresponding primary database. すべてのログ レコードが書き込まれるとすぐに、セカンダリ データベースが SYNCHRONIZED 状態になります。As soon as every log record has been hardened, the secondary database enters the SYNCHRONIZED state. その後、すべての新しいトランザクションがセカンダリ レプリカによって書き込まれてから、ログ レコードがローカル ログ ファイルに書き込まれます。Thereafter, every new transaction is hardened by the secondary replica before the log record is written to the local log file. 特定のセカンダリ レプリカのすべてのセカンダリ データベースが同期されると、同期コミット モードでは、手動でのフェールオーバーがサポートされます (オプションで自動フェールオーバーがサポートされます)。When all the secondary databases of a given secondary replica are synchronized, synchronous-commit mode supports manual failover and, optionally, automatic failover.

    詳細については、このトピックの「 同期コミット可用性モード」を参照してください。For more information, see Synchronous-Commit Availability Mode, later in this topic.

  • "構成のみモード" は、Windows Server フェールオーバー クラスター上にない可用性グループに適用されます。Configuration only mode applies to availability groups that are not on a Windows Server Failover Cluster. 構成のみモードのレプリカには、ユーザー データは含まれません。A replica in configuration only mode does not contain user data. 構成のみモードでは、レプリカの master データベースに可用性グループの構成メタデータが格納されます。In configuration only mode, the replica master database stores availability group configuration metadata. 詳しくは、構成のみのレプリカでの可用性グループに関するページをご覧ください。For more information see Availability group with configuration only replica.

    次の図には、5 つの可用性レプリカがある可用性グループを示しています。The following illustration shows an availability group with five availability replicas. プライマリ レプリカおよびセカンダリ レプリカの 1 つには、自動フェールオーバーが指定された同期コミット モードが構成されています。The primary replica and one secondary replica are configured for synchronous-commit mode with automatic failover. もう 1 つのセカンダリ レプリカは、計画的な手動フェールオーバーのみが指定された同期コミット モードで構成されています。残りの 2 つのセカンダリ レプリカは、強制手動フェールオーバー (通常は 強制フェールオーバーと呼ばれます) のみをサポートする非同期コミット モードで構成されています。Another secondary replica is configured for synchronous-commit mode with only planned manual failover, and two secondary replicas are configured for asynchronous-commit mode, which supports only forced manual failover (typically called forced failover).

    レプリカの可用性およびフェールオーバー モードAvailability and failover modes of replicas

    2 つの可用性レプリカ間の同期およびフェールオーバー動作は、両方のレプリカの可用性モードに依存します。The synchronization and failover behavior between two availability replicas depends on the availability mode of both replicas. たとえば、同期コミットを発生させるには、現在のプライマリ レプリカとセカンダリ レプリカの両方で同期コミットが構成されている必要があります。For example, for synchronous commit to occur, both the current primary replica and the secondary replica in question must be configured for synchronous commit. 同様に、自動フェールオーバーを発生させるには、両方のレプリカで自動フェールオーバーが構成されている必要があります。Likewise, for automatic failover to occur, both replicas need to be configured for automatic failover. 上の配置シナリオについて、それぞれのプライマリ レプリカでの動作を次の表に示します。Therefore, the behavior for the illustrated deployment scenario above can be summarized in the following table, which explores the behavior with each potential primary replica:

現在のプライマリ レプリカCurrent Primary Replica 自動フェールオーバー ターゲットAutomatic Failover Targets 同期コミット モードの動作の対象Synchronous-Commit Mode Behavior With 非同期コミット モードの動作の対象Asynchronous-Commit Mode Behavior With 自動フェールオーバーAutomatic failover possible
0101 0202 02 と 0302 and 03 0404 はいYes
0202 0101 01 と 0301 and 03 0404 はいYes
0303 01 と 0201 and 02 0404 いいえNo
0404 01、02、0301, 02, and 03 いいえNo

通常、非同期コミット レプリカとしてのノード 04 が災害復旧サイトに配置されます。Typically, Node 04 as an asynchronous-commit replica, is deployed in a disaster recovery site. ノード 04 にフェールオーバーした後もノード 01、02、03 は非同期コミット モードにとどまるため、2 つのサイト間の長いネットワーク待機時間が原因で可用性グループに生じるパフォーマンスの低下を回避できます。The fact that Nodes 01, 02, and 03 remain at asynchronous-commit mode after failing over to Node 04 helps prevent potential performance degradation in your availability group due to high network latency between the two sites.

Asynchronous-Commit Availability ModeAsynchronous-Commit Availability Mode

非同期コミット モードでは、セカンダリ レプリカがプライマリ レプリカと同期されることはありません。Under asynchronous-commit mode, the secondary replica never becomes synchronized with the primary replica. 特定のセカンダリ データベースが対応するプライマリ データベースからの遅れを取り戻す場合もありますが、セカンダリ データベースはどの時点でも遅延する可能性があります。Though a given secondary database might catch up to the corresponding primary database, any secondary database could lag behind at any point. 非同期コミット モードは、プライマリ レプリカから非常に離れた場所にセカンダリ レプリカがあり、軽度のエラーによるプライマリ レプリカへの影響でも不都合が生じる災害復旧シナリオ、または同期によるデータ保護よりもパフォーマンスの方が重要な場合に役立ちます。Asynchronous-commit mode can be useful in a disaster-recovery scenario in which the primary replica and the secondary replica are separated by a significant distance and where you do not want small errors to impact the primary replica or in or situations where performance is more important than synchronized data protection. また、プライマリ レプリカはセカンダリ レプリカから送信される確認を待機しないため、セカンダリ レプリカの問題がプライマリ レプリカに影響することはありません。Furthermore, since the primary replica does not wait for acknowledgements from the secondary replica, problems on the secondary replica never impact the primary replica.

非同期コミット セカンダリ レプリカは、プライマリ レプリカから受信するログ レコードとの時間差を埋めようとします。An asynchronous-commit secondary replica attempts to keep up with the log records received from the primary replica. ただし、非同期コミット セカンダリ データベースは常に同期されていない状態であり、対応するプライマリ データベースよりも若干遅れる可能性があります。But asynchronous-commit secondary databases always remain unsynchronized and are likely to lag somewhat behind the corresponding primary databases. 通常、非同期コミット セカンダリ データベースと対応するプライマリ データベース間の時間差はわずかですが、Typically the gap between an asynchronous-commit secondary database and the corresponding primary database is small. セカンダリ レプリカをホストするサーバーに負荷がかかり過ぎている場合やネットワークが低速の場合は、この時間差が大きくなります。But the gap can become substantial if the server hosting the secondary replica is over loaded or the network is slow.

非同期コミット モードでサポートされるフェールオーバーは、強制フェールオーバーのみです (データ損失の可能性あり)。The only form of failover supported by asynchronous-commit mode is forced failover (with possible data loss). フェールオーバーの強制は、現在のプライマリ レプリカが長期間使用できない状態のままであり、データを失うリスクよりもプライマリ データベースがすぐに使用できるようになることの方が重要である場合にのみ、最後の手段として使用します。フェールオーバー ターゲットとなるレプリカは、ロールが SECONDARY 状態または RESOLVING 状態であることが必要です。Forcing failover is a last resort intended only for situations in which the current primary replica will remain unavailable for an extended period and immediate availability of primary databases is more critical than the risk of possible data loss.The failover target must be a replica whose role is in the SECONDARY or RESOLVING state. フェールオーバー ターゲットはプライマリ ロールに移行し、データベースのコピーがプライマリ データベースになります。The failover target transitions to the primary role, and its copies of the databases become the primary database. 元のプライマリ データベースが使用できるようになると、残りのセカンダリ データベースと元のプライマリ データベースは手動で個別に再開されるまで中断されます。Any remaining secondary databases, along with the former primary databases, once they become available, are suspended until you manually resume them individually. 非同期コミット モードでは、元のプライマリ レプリカから元のセカンダリ レプリカにまだ送信されていなかったトランザクション ログはすべて失われます。Under asynchronous-commit mode, any transaction logs that the original primary replica had not yet sent to the former secondary replica are lost. つまり、一部またはすべての新しいプライマリ データベースで、最近コミットされたトランザクションが欠落している可能性があります。This means that some or all of the new primary databases might be lacking recently committed transactions. 強制フェールオーバーのしくみと、強制フェールオーバーを使用する際のベスト プラクティスの詳細については、「 フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)」を参照してください。For more information on how forced failover works and on best practices for using it, see Failover and Failover Modes (Always On Availability Groups).

Synchronous-Commit Availability ModeSynchronous-Commit Availability Mode

同期コミット可用性モード (同期コミット モード) では、セカンダリ データベースは可用性グループに参加すると、対応するプライマリ データベースからの遅れを取り戻し、SYNCHRONIZED 状態になります。Under synchronous-commit availability mode (synchronous-commit mode), after being joined to an availability group, a secondary database catches up to the corresponding primary database and enters the SYNCHRONIZED state. データの同期が継続されている間は、セカンダリ データベースは SYNCHRONIZED のままです。The secondary database remains SYNCHRONIZED as long as data synchronization continues. これにより、特定のプライマリ データベースでコミットされたすべてのトランザクションが、対応するセカンダリ データベースでもコミットされていることが保証されます。This guarantees that every transaction that is committed on a given primary database has also been committed on the corresponding secondary database. 特定のセカンダリ レプリカのすべてのセカンダリ データベースが同期されると、セカンダリ レプリカ全体の同期状態が HEALTHY になります。When every secondary database on a given secondary replica is synchronized, the synchronization-health state of the secondary replica as a whole is HEALTHY.

このセクションの内容In This Section:

データの同期が中断する要因Factors That Disrupt Data Synchronization

すべてのデータベースが同期されると、セカンダリ レプリカは HEALTHY 状態になります。Once all of its databases are synchronized, a secondary replica enters the HEALTHY state. 次のいずれかの状況にならない限り、同期されたセカンダリ レプリカは HEALTHY のままです。The synchronized secondary replica will remain healthy unless one of the following occurs:

  • ネットワークやコンピューターの遅延または不具合が原因で、セカンダリ レプリカとプライマリ レプリカ間のセッションがタイムアウトになった。A network or computer delay or glitch causes the session between the secondary replica and primary replica to timeout.

    注意

    可用性レプリカのセッション時間プロパティの詳細については、「 AlwaysOn 可用性グループの概要 (SQL Server)」を参照してください。For information about the session-time property of availability replicas, see Overview of Always On Availability Groups (SQL Server).

  • セカンダリ レプリカ上のセカンダリ データベースを中断した。You suspend a secondary database on the secondary replica. セカンダリ レプリカの同期が行われなくなり、同期状態が NOT_HEALTHY としてマークされます。The secondary replica ceases to be synchronized, and its synchronization-health state is marked as NOT_HEALTHY. 中断されたセカンダリ データベースが再開されて再同期されるか、可用性グループから削除されるまで、セカンダリ レプリカを HEALTHY にすることはできません。the secondary replica cannot become healthy again until the suspended secondary database is either resumed and resynchronized or removed from the availability group.

  • プライマリ データベースを可用性グループに追加した。You add a primary database the availability group. 以前に同期されたセカンダリ レプリカは NOT_HEALTHY 同期状態になります。Previously synchronized secondary replicas enter the NOT_HEALTHY synchronization-health state. この状態は、少なくとも 1 つのデータベースが NOT SYNCHRONIZING 同期状態であることを示しています。This state indicates that at least one database is in the NOT SYNCHRONIZING synchronization state. 対応するセカンダリ データベースがレプリカ上で準備され、可用性グループに参加し、新しいプライマリ データベースと同期されるまで、特定のセカンダリ レプリカを HEALTHY にすることはできません。A given secondary replica cannot be HEALTHY again until a corresponding secondary database has been prepared on the replica, has been joined to the availability group, and has become synchronized with the new primary database.

  • プライマリ レプリカまたはセカンダリ レプリカを非同期コミット可用性モードに変更した。You change the primary replica or the secondary replica to asynchronous-commit availability mode. 非同期コミット モードに変更すると、データの同期が継続されている間は、セカンダリ レプリカは HEALTHY 同期状態のままになります。After changing to asynchronous-commit mode, the secondary replica will remain in the HEALTHY synchronization-health state as long as data synchronization continues. ただし、プライマリ レプリカのみを非同期コミット モードに変更すると、同期コミット セカンダリ レプリカは PARTIALLY_HEALTHY 同期状態になります。However, if only the primary replica is changed to asynchronous-commit mode, the synchronous-commit secondary replica will enter the PARTIALLY_HEALTHY synchronization-health state. この状態は、少なくとも 1 つのデータベースが SYNCHRONIZING 同期状態であり、NOT SYNCHRONIZING 状態のデータベースが 1 つもないことを示しています。This state indicates that at least one database is in the SYNCHRONIZING synchronization state, but none of the databases are in the NOT SYNCHRONIZING state.

  • セカンダリ レプリカを同期コミット可用性モードに変更した。You change any secondary replica to synchronous-commit availability mode. これにより、すべてのデータベースが SYNCHRONIZED 同期状態になるまで、This causes that secondary replica to be marked as in the PARTIALLY_HEALTHY synchronization-health state. セカンダリ レプリカは PARTIALLY_HEALTHY 同期状態としてマークされます。until all of its databases are in the SYNCHRONIZED synchronization state.

ヒント

可用性グループ、可用性レプリカ、または可用性データベースの同期状態を確認するには、 sys.dm_hadr_availability_group_statessys.dm_hadr_availability_replica_states 、または sys.dm_hadr_database_replica_statesそれぞれの synchronization_health列または synchronization_health_desc列に対してクエリを実行します。To view the synchronization health of an availability group, availability replica, or availability database, query the synchronization_health or synchronization_health_desc column of sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states, or sys.dm_hadr_database_replica_states, respectively.

セカンダリ レプリカでの同期のしくみHow Synchronization Works on a Secondary Replica

同期コミット モードでは、セカンダリ レプリカは可用性グループに参加してプライマリ レプリカとのセッションを確立した後、受信したログ レコードをディスクに書き込み (ログ書き込み)、プライマリ レプリカに確認メッセージを送信します。Under the synchronous-commit mode, after a secondary replica joins the availability group and establishes a session with the primary replica, the secondary replica writes incoming log records to disk (hardens the log) and sends a confirmation message to the primary replica. セカンダリ データベースの書き込まれたログがプライマリ データベースのログの末尾に追い付くと、セカンダリ データベースの状態は SYNCHRONIZED に設定されます。Once the hardened log on the secondary database has caught up the end of log on the primary database, the state of the secondary database is set to SYNCHRONIZED. 同期に必要な時間は、主にセッションの開始時にセカンダリ データベースがプライマリ データベースからどれだけ遅れたか (プライマリ レプリカから最初に受信したログ レコード数によって測定)、プライマリ データベースのワークロード、およびセカンダリ レプリカをホストするサーバー インスタンスのコンピューター速度に依存します。The time required for synchronization depends essentially on how far the secondary database was behind the primary database at the start of the session (measured by the number of log records initially received from the primary replica), the work load on the primary database, and the speed of the computer of the server instance that hosts the secondary replica.

同期操作は次のように行われます。Synchronous operation is maintained in the following manner:

  1. プライマリ レプリカは、クライアントからトランザクションを受け取ると、そのトランザクションのログをトランザクション ログに書き込み、同時にログ レコードをセカンダリ レプリカに送信します。On receiving a transaction from a client, the primary replica writes the log for the transaction to the transaction log and concurrently sends the log record to the secondary replicas.

  2. ログ レコードがプライマリ データベースのトランザクション ログに書き込まれた後にトランザクションを元に戻すには、ログを受け取っていないセカンダリへのフェールオーバーがこの時点で存在している必要があります。Once a log record is written to the transaction log of the primary database, the transaction can be undone only if there is a failover at this point to a secondary that did not receive the log. プライマリ レプリカは、同期コミット セカンダリ レプリカから送信される確認を待機します。The primary replica waits for confirmation from the synchronous-commit secondary replica.

  3. セカンダリ レプリカはログを書き込み、確認をプライマリ レプリカに返します。The secondary replica hardens the log and returns an acknowledgement to the primary replica.

  4. プライマリ レプリカは、セカンダリ レプリカから確認を受け取ると、コミット処理を終了させ、確認メッセージをクライアントに送信します。On receiving the confirmation from the secondary replica, the primary replica finishes the commit processing and sends a confirmation message to the client.

    注意

    同期コミット セカンダリ レプリカによってログが書き込まれたことを確認する前にタイムアウトになった場合、プライマリはそのセカンダリ レプリカを失敗としてマークします。If a synchronous-commit secondary replica times out without confirming that it has hardened the log, the primary marks that secondary replica as failed. セカンダリ レプリカの接続状態は DISCONNECTED に変更され、プライマリ レプリカはセカンダリ レプリカから送信される確認の待機を停止します。The connected state of the secondary replica changes to DISCONNECTED, and the primary replica stops waiting for confirmation from the secondary replica. この動作により、失敗した同期コミット セカンダリ レプリカによってプライマリ レプリカのトランザクション ログの書き込みが実行できなくなることを回避します。This behavior ensures that a failed synchronous-commit secondary replica does not prevent hardening of the transaction log on the primary replica.

    同期コミット モードでは、2 か所間のデータの同期を要求することによってデータを保護しますが、トランザクションの遅延が多少大きくなるというデメリットもあります。Synchronous-commit mode protects your data by requiring the data to be synchronized between two places, at the cost of somewhat increasing the latency of the transaction.

手動フェールオーバーのみを指定した同期コミット モードSynchronous-Commit Mode with Only Manual Failover

これらのレプリカが接続され、データベースが同期されている場合、手動フェールオーバーがサポートされます。When these replicas are connected and the database is synchronized, manual failover is supported. セカンダリ レプリカがダウンしても、プライマリ レプリカは影響を受けません。If the secondary replica goes down, the primary replica is unaffected. SYNCHRONIZED 状態のレプリカが存在しない場合、プライマリ レプリカは公開された状態で (つまり、データをセカンダリ レプリカに送信せずに) 実行されます。The primary replica runs exposed if no SYNCHRONIZED replicas exist (that is, without sending data to any secondary replica). プライマリ レプリカが利用できなくなると、セカンダリ レプリカが RESOLVING 状態になりますが、データベース所有者はセカンダリ レプリカへの強制フェールオーバーを実行できます (データを損失する可能性もあります)。If the primary replica is lost, the secondary replicas enter the RESOLVING state, but the database owner can force a failover to the secondary replica (with possible data loss). 詳細については、このトピックの「 フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)」を参照してください。For more information, see Failover and Failover Modes (Always On Availability Groups).

自動フェールオーバーを指定した同期コミット モードSynchronous-Commit Mode with Automatic Failover

自動フェールオーバーは、プライマリ レプリカが機能しなくなった後もデータベースをすぐに再度使用できるようにすることで、高可用性を実現します。Automatic failover provides high availability by ensuring that the database is quickly made available again after the loss of the primary replica. 可用性グループを自動フェールオーバー用に構成するには、現在のプライマリ レプリカと少なくとも 1 つのセカンダリ レプリカの両方を、自動フェールオーバーを指定した同期コミット モードに設定する必要があります。To configure an availability group for automatic failover, you need to set both the current primary replica and at least one secondary replica to synchronous-commit mode with automatic failover. 最大 3 つの自動フェールオーバー レプリカを所有することができます。You can have up to three automatic failover replicas.

さらに、特定の時点で自動フェールオーバーを実行するには、このセカンダリ レプリカがプライマリ レプリカと同期されている (つまり、すべてのセカンダリ レプリカが同期されている) 必要があるだけでなく、Windows Server フェールオーバー クラスタリング (WSFC) クラスターがクォーラムを持っている必要もあります。Furthermore, for an automatic failover to be possible at a given time, this secondary replica must be synchronized with the primary replica (that is, the secondary databases are all synchronized), and the Windows Server Failover Clustering (WSFC) cluster must have quorum. プライマリ レプリカが使用できなくなると、これらの条件で自動フェールオーバーが発生します。If the primary replica becomes unavailable under these conditions, automatic failover occurs. セカンダリ レプリカはプライマリ ロールに切り替わり、そのデータベースをプライマリ データベースとして提供します。The secondary replica switches to the role of primary, and it offers its database as the primary database. 詳細については、「フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)」トピックの「自動フェールオーバー」セクションを参照してください。For more information, see the "Automatic Failover " section of the Failover and Failover Modes (Always On Availability Groups) topic.

注意

WSFC クォーラムと Always On 可用性グループAlways On availability groups については、「WSFC クォーラム モードと投票の構成 (SQL Server)」を参照してください。For information about WSFC quorum and Always On 可用性グループAlways On availability groups, see For more information, see WSFC Quorum Modes and Voting Configuration (SQL Server).

関連タスクRelated Tasks

可用性モードとフェールオーバー モードを変更するにはTo change the availability mode and failover mode

関連コンテンツRelated Content

参照See Also

AlwaysOn 可用性グループの概要 (SQL Server) Overview of Always On Availability Groups (SQL Server)
フェールオーバーとフェールオーバー モード (Always On 可用性グループ) Failover and Failover Modes (Always On Availability Groups)
Windows Server フェールオーバー クラスタリング (WSFC) と SQL ServerWindows Server Failover Clustering (WSFC) with SQL Server