適用対象:
SQL Server
Always On 可用性グループの 可用性モード は、可用性レプリカが同期コミット モードで動作できるかどうかを指定するレプリカのプロパティです。 可用性レプリカごとに、可用性モードを同期コミット モード、非同期コミット モード、または構成のみモードとして構成する必要があります。 プライマリ レプリカが 非同期コミット モード用に構成されている場合、セカンダリ レプリカが受信トランザクション ログ レコードをディスクに書き込むのを待機しません ( ログを強化するため)。 特定のセカンダリ レプリカが非同期コミット モードで構成されている場合、プライマリ レプリカはそのセカンダリ レプリカによるログの堅牢化を待機しません。 プライマリ レプリカとセカンダリ レプリカの両方が 同期コミット モードで構成されている場合、プライマリ レプリカはログが書き込まれたことをセカンダリ レプリカが確認するまで待機します (プライマリの セッション タイムアウト期間内に、セカンダリ レプリカがプライマリ レプリカに対する ping に失敗した場合を除きます)。
メモ
セカンダリ レプリカがプライマリのセッション タイムアウト期間を超えた場合、プライマリ レプリカはそのセカンダリ レプリカに対して一時的に非同期コミット モードに移行します。 セカンダリ レプリカがプライマリ レプリカと再接続すると、同期コミット モードが再開されます。
サポートされている可用性モード
Always On 可用性グループでは、次の 3 つの可用性モードがサポートされています。
- 非同期コミット モード
- 同期コミット モード
- 構成のみモード
非同期コミット モード は、可用性レプリカが離れた距離に分散されている場合に正常に利用できる災害復旧ソリューションです。 すべてのセカンダリ レプリカが非同期コミット モードで実行されている場合、プライマリ レプリカは、どのセカンダリ レプリカによりログの堅牢化も待機しません。 ログ レコードがローカル ログ ファイルに書き込まれるとすぐに、プライマリ レプリカはクライアントにトランザクションの確認を送信します。 プライマリ レプリカは、非同期コミット モードが構成されているセカンダリ レプリカに対して、トランザクションの遅延を最小限に抑えて実行されます。 現在のプライマリが非同期コミット可用性モード用に構成されている場合、個々の可用性モードの設定に関係なく、すべてのセカンダリ レプリカに対してトランザクションが非同期的にコミットされます。
詳細については、このトピックの「 非同期コミット可用性モード」を参照してください。
同期コミット モード は、パフォーマンスよりも高可用性が重視され、トランザクションの遅延が増加するのが欠点です。 同期コミット モードでは、セカンダリ レプリカによりログがディスクに保存されて堅牢化されるまで、トランザクションの確認はクライアントに送信されません。 セカンダリ データベースでデータの同期が開始されると、セカンダリ レプリカで、対応するプライマリ データベースから受信したログ レコードの適用が開始されます。 すべてのログ レコードが堅牢化されるとすぐに、セカンダリ データベースが SYNCHRONIZED 状態になります。 その後、すべての新しいトランザクションはセカンダリ レプリカによって強化され、ログ レコードがローカル ログ ファイルに書き込まれます。 特定のセカンダリ レプリカのすべてのセカンダリ データベースが同期されると、同期コミット モードでは、手動でのフェールオーバーがサポートされます (オプションで自動フェールオーバーがサポートされます)。
詳細については、このトピックの「 同期コミット可用性モード」を参照してください。
構成のみモード は、Windows Server フェールオーバー クラスター上にない可用性グループに適用されます。 構成のみのモードのレプリカには、ユーザー データが含まれません。 構成のみモードでは、レプリカの master データベースに可用性グループの構成メタデータが格納されます。 詳しくは、構成のみのレプリカでの可用性グループに関するページをご覧ください。
次の図には、5 つの可用性レプリカがある可用性グループを示しています。 プライマリ レプリカと1台のセカンダリ レプリカが、自動フェールオーバー付きの同期コミット モードで構成されています。 もう 1 つのセカンダリ レプリカは、計画的な手動フェールオーバーのみが指定された同期コミット モードで構成されています。残りの 2 つのセカンダリ レプリカは、強制手動フェールオーバー (通常は 強制フェールオーバーと呼ばれます) のみをサポートする非同期コミット モードで構成されています。
2 つの可用性レプリカ間の同期とフェールオーバーの動作は、両方のレプリカの可用性モードによって異なります。 たとえば、同期コミットを実行するには、プライマリ レプリカとセカンダリ レプリカの両方を同期コミット用に構成する必要があります。 自動フェールオーバーの場合も同様に、両方のレプリカを自動フェールオーバー用に構成する必要があります。 上の配置シナリオについて、それぞれのプライマリ レプリカでの動作を次の表に示します。
| 現在のプライマリ レプリカ | 自動フェールオーバー ターゲット | 同期コミット モードの動作の対象 | 非同期コミット モードの動作の対象 | 自動フェールオーバーが可能 |
|---|---|---|---|---|
| 01 | 02 | 02 と 03 | 04 | はい |
| 02 | 01 | 01 と 03 | 04 | はい |
| 03 | 01 と 02 | 04 | いいえ | |
| 04 | 01、02、03 | いいえ |
通常、非同期コミット レプリカとしてのノード 04 が災害復旧サイトに配置されます。 ノード 04 にフェールオーバーした後もノード 01、02、03 は非同期コミット モードにとどまるため、2 つのサイト間の長いネットワーク待機時間が原因で可用性グループに生じるパフォーマンスの低下を回避できます。
非同期コミット可用性モード
非同期コミット モードでは、セカンダリ レプリカがプライマリ レプリカと同期されることはありません。 特定のセカンダリ データベースが対応するプライマリ データベースからの遅れを取り戻す場合もありますが、セカンダリ データベースはどの時点でも遅延する可能性があります。 非同期コミット モードは、プライマリ レプリカとセカンダリ レプリカが大きな距離で区切られ、小さなエラーがプライマリ レプリカに影響を与えるのを望まないディザスター リカバリー シナリオや、同期されたデータ保護よりもパフォーマンスが重要な状況で役立ちます。 さらに、プライマリ レプリカはセカンダリ レプリカからの受信確認を待機しないため、セカンダリ レプリカの問題がプライマリ レプリカに影響することはありません。
非同期コミット セカンダリ レプリカは、プライマリ レプリカから受信するログ レコードとの時間差を埋めようとします。 ただし、非同期コミット セカンダリ データベースは常に同期されていない状態であり、対応するプライマリ データベースよりも若干遅れる可能性があります。 通常、非同期コミット セカンダリ データベースと対応するプライマリ データベース間のギャップは小さいです。 セカンダリ レプリカをホストするサーバーに負荷がかかり過ぎている場合やネットワークが低速の場合は、この時間差が大きくなります。
非同期コミット モードでサポートされるフェールオーバーは、強制フェールオーバーのみです (データ損失の可能性あり)。 フェールオーバーの強制は、現在のプライマリ レプリカが長期間使用できない状態のままであり、データを失うリスクよりもプライマリ データベースがすぐに使用できるようになることの方が重要である場合にのみ、最後の手段として使用します。 フェールオーバー ターゲットとなるレプリカは、ロールが SECONDARY 状態または RESOLVING 状態である必要があります。 フェールオーバー ターゲットはプライマリ ロールに移行し、データベースのコピーがプライマリ データベースになります。 元のプライマリデータベースと他の全てのセカンダリデータベースは、利用可能になると、手動で個別に再開されるまで中断されます。 非同期コミット モードでは、元のプライマリ レプリカがまだ以前のセカンダリ レプリカに送信されていないトランザクション ログは失われます。 つまり、一部またはすべての新しいプライマリ データベースで、最近コミットされたトランザクションが欠落している可能性があります。 強制フェールオーバーのしくみと、これを使用する際のベスト プラクティスの詳細については、「フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)」を参照してください。
同期コミット可用性モード
同期コミット可用性モード (同期コミット モード) では、セカンダリ データベースは可用性グループに参加すると、対応するプライマリ データベースからの遅れを取り戻し、SYNCHRONIZED 状態になります。 データの同期が継続されている間は、セカンダリ データベースは SYNCHRONIZED のままです。 これにより、特定のプライマリ データベースでコミットされたすべてのトランザクションが、対応するセカンダリ データベースでコミットされます。 特定のセカンダリ レプリカのすべてのセカンダリ データベースが同期されると、セカンダリ レプリカ全体の同期状態が HEALTHY になります。
このセクションの内容
データ同期を中断する要因
すべてのデータベースが同期されると、セカンダリ レプリカは HEALTHY 状態になります。 次のいずれかの状況にならない限り、同期されたセカンダリ レプリカは HEALTHY のままです。
ネットワークやコンピューターの遅延または不具合が原因で、セカンダリ レプリカとプライマリ レプリカ間のセッションがタイムアウトになる。
メモ
可用性レプリカのセッション時間プロパティの詳細については、「Always On 可用性グループとは (SQL Server)」を参照してください。
セカンダリ データベースをセカンダリ レプリカ上で中断する。 セカンダリ レプリカの同期が行われなくなり、同期の正常性状態が NOT_HEALTHY としてマークされます。 中断されたセカンダリ データベースが再開され、再同期されるか、可用性グループから削除されるまで、セカンダリ レプリカは再度正常になりません。
プライマリ データベースを可用性グループに追加した。 以前に同期されたセカンダリ レプリカは同期の正常性状態が NOT_HEALTHY になります。 この状態は、少なくとも 1 つのデータベースが NOT SYNCHRONIZING （同期中ではない）同期状態であることを示しています。 特定のセカンダリ レプリカは、対応するセカンダリ データベースがレプリカで準備され、可用性グループに参加し、新しいプライマリ データベースと同期されるまで、もう一度 HEALTHY にすることはできません。
プライマリ レプリカまたはセカンダリ レプリカを非同期コミット可用性モードに変更した。 非同期コミット モードに変更すると、データの同期が継続されている間は、セカンダリ レプリカは HEALTHY 同期状態のままになります。 ただし、プライマリ レプリカのみを非同期コミット モードに変更すると、同期コミット セカンダリ レプリカは PARTIALLY_HEALTHY 同期ヘルス状態になります。 この状態は、少なくとも 1 つのデータベースが SYNCHRONIZING 同期状態であり、NOT SYNCHRONIZING 状態のデータベースが 1 つもないことを示しています。
セカンダリ レプリカを同期コミット可用性モードに変更します。 これにより、セカンダリ レプリカのすべてのデータベースの同期状態が SYNCHRONIZED になるまで、セカンダリ レプリカの同期正常性状態は PARTIALLY_HEALTHY としてマークされます。
ヒント
可用性グループ、可用性レプリカ、または可用性データベースの同期状態を確認するには、 sys.dm_hadr_availability_group_states 、 sys.dm_hadr_availability_replica_states 、または sys.dm_hadr_database_replica_statesそれぞれの synchronization_health列または synchronization_health_desc列に対してクエリを実行します。
セカンダリ レプリカでの同期のしくみ
同期コミット モードでは、セカンダリ レプリカが可用性グループに参加し、プライマリ レプリカとのセッションを確立した後、
- セカンダリ レプリカは、受信ログ レコードをディスクに書き込みます (ログが強化されます)。
- セカンダリ レプリカは、プライマリ レプリカに確認メッセージを送信します。
セカンダリ データベースのセキュリティ強化されたログがプライマリ データベースのログの最後まで追いついた後、セカンダリ データベースの状態は SYNCHRONIZED に設定されます。
同期に必要な時間は、セッションの開始時にセカンダリ データベースがプライマリ データベースの背後にあった距離によって異なります。 この差分は、プライマリ レプリカから最初に受信したログ レコードの数、プライマリ データベースでの作業負荷、およびセカンダリ レプリカのインスタンス ホストの速度によって測定されます。
トランザクション プロセス
同期コミット モードでは、トランザクションは次の順序で両方のレプリカにコミットされます。
プライマリ レプリカは、クライアントからトランザクションを受信します。
プライマリ レプリカは、レコードをトランザクション ログに書き込み、ログ レコードをセカンダリ レプリカに同時に送信します。
ログ レコードがプライマリ データベースのトランザクション ログに書き込まれると、ログを受信しなかったセカンダリへのフェールオーバーがある場合にのみ、トランザクションを元に戻すことができます。
プライマリ レプリカは、同期コミット セカンダリ レプリカから送信される確認を待機します。
セカンダリ レプリカはログを強化し、確認をプライマリ レプリカに返します。
プライマリ レプリカはコミット処理を完了し、確認メッセージをクライアントに送信します。
同期コミット タイムアウト
同期コミットのセカンダリ レプリカがログを永続化したことを確認せずにタイムアウトすると、可用性グループで以下のアクションが実行されます。
- プライマリ レプリカは、そのセカンダリ レプリカを失敗としてマークします。
- セカンダリ レプリカの状態が DISCONNECTED に変わります。
- プライマリは確認の待機を中止します。
- 可用性グループは同期状態を NOT SYNCHRONIZING としてマークし、レプリカの状態をNOT_HEALTHYとしてマークします。
この動作により、失敗した同期コミット セカンダリ レプリカがプライマリ レプリカでのログの堅牢化を妨げることはありません。
セカンダリ レプリカがオンラインに戻ったとき:
- セカンダリ レプリカの状態が CONNECTED に変わります。
- セカンダリ レプリカは、プライマリ レプリカのログ送信キューを処理します。
- 同期状態が SYNCHRONIZING に遷移し、レプリカの正常性が PARTIALLY_HEALTHY に遷移します。
ログ送信キューが処理されると、同期状態が SYNCHRONIZED になり、レプリカの正常性が正常になります。
同期コミット モードでは、2 か所間のデータの同期を要求することによってデータを保護しますが、トランザクションの遅延が多少大きくなるというデメリットもあります。
手動フェールオーバーのみを指定した同期コミット モード
これらのレプリカが接続され、データベースが同期されている場合、手動フェールオーバーがサポートされます。 セカンダリ レプリカがダウンしても、プライマリ レプリカは影響を受けません。 SYNCHRONIZED 状態のレプリカが存在しない場合、プライマリ レプリカは無防備な状態で (つまり、データをセカンダリ レプリカに送信せずに) 実行されます。 プライマリ レプリカが利用できなくなると、セカンダリ レプリカが RESOLVING 状態になりますが、データベース所有者はセカンダリ レプリカへの強制フェールオーバーを実行できます (データを損失する可能性もあります)。 詳しくは、「フェールオーバーとフェールオーバー モード (Always On 可用性グループ)」をご覧ください。
自動フェールオーバーを使用した同期コミット モード
自動フェールオーバーは、プライマリ レプリカが機能しなくなった後もデータベースをすぐに再度使用できるようにすることで、高可用性を実現します。 可用性グループを自動フェールオーバー用に構成するには、現在のプライマリ レプリカと少なくとも 1 つのセカンダリ レプリカの両方を、自動フェールオーバーを指定した同期コミット モードに設定する必要があります。 SQL Server 2019 (15.x) では同期レプリカの最大数が SQL Server 2017 (14.x) での 3 から 5 へと増加しました。 この 5 つのレプリカのグループを、グループ内で自動フェールオーバーするように構成できます。 1 つのプライマリ レプリカと、4 つの同期セカンダリ レプリカがあります。
さらに、特定の時点で自動フェールオーバーを実行するには、このセカンダリ レプリカがプライマリ レプリカと同期されている (つまり、すべてのセカンダリ レプリカが同期されている) 必要があるだけでなく、Windows Server フェールオーバー クラスタリング (WSFC) クラスターがクォーラムを持っている必要もあります。 プライマリ レプリカが使用できなくなると、これらの条件で自動フェールオーバーが発生します。 セカンダリ レプリカはプライマリ ロールに切り替わり、そのデータベースをプライマリ データベースとして提供します。 詳しくは、「フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)」トピックの「自動フェールオーバー」セクションをご覧ください。
メモ
WSFC クォーラムと Always On 可用性グループの詳細については、「WSFC クォーラム モードと投票の構成 (SQL Server)」を参照してください。
セカンダリ レプリカでのデータ待機時間
セカンダリ レプリカへの読み取り専用アクセスの実装が役立つのは、読み取り専用ワークロードである程度のデータ待機時間を許容できる場合です。 データ待機時間が許容できない場合は、読み取り専用ワークロードをプライマリ レプリカに対して実行することを検討してください。
プライマリ レプリカは、プライマリ データベースでの変更のログ レコードをセカンダリ レプリカに送信します。 それぞれのセカンダリ データベースで、専用の再実行スレッドがログ レコードに適用されます。 読み取りアクセスセカンダリ データベースでは、変更を含むログ レコードがセカンダリ データベースに適用され、トランザクションがプライマリ データベースでコミットされるまで、特定のデータ変更はクエリ結果に表示されません。
つまり、プライマリ レプリカとセカンダリ レプリカの間には、通常は数秒しか待ち時間が発生しません。 ただし、ネットワークの問題のためにスループットが低下するなどの特殊なケースでは、待機時間が長くなることがあります。 I/O ボトルネックが生じた場合やデータの移動が中断された場合は、待機時間が増加します。 データ移動の中断を監視する場合、Always On ダッシュボードまたは sys.dm_hadr_database_replica_states 動的管理ビューを使用できます。
SQL Server 2025 (17.x) プレビュー以降では、待機時間を短縮するために、プライマリ レプリカがセカンダリ レプリカにトランザクションをコミットするために要する時間をミリ秒単位で短縮できます。 可用性グループのコミット時間 (ミリ秒) を確認して詳細を確認します。
可用性モードとフェールオーバー モードを変更するには
クォーラム投票を調整するには:
手動フェールオーバーを実行するには
可用性グループ、可用性レプリカ、およびデータベースの状態を確認するには
関連コンテンツ
こちらも参照ください
Always On 可用性グループの概要 (SQL Server)
フェールオーバーとフェールオーバー モード (Always On 可用性グループ)
Windows Server フェールオーバー クラスタリング (WSFC) と SQL Server