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