「同期コミット可用性モード」はレプリカ間の一貫性を保証しますか？
Synchronous-Commit Availability Mode でMSDNドキュメントを参照している場合、次のように読むことができます。
同期コミット可用性モード（同期コミットモード）では、セカンダリデータベースは可用性グループに参加した後、対応するプライマリデータベースに追いつき、SYNCHRONIZED状態になります。データの同期が続く限り、セカンダリデータベースはSYNCHRONIZEDのままです。これにより、特定のプライマリデータベースでコミットされるすべてのトランザクションが、対応するセカンダリデータベースでもコミットされることが保証されます。特定のセカンダリレプリカ上のすべてのセカンダリデータベースが同期されると、セカンダリレプリカ全体の同期正常性状態は正常です。
HEALTHY状態の同期されたデータベースを持つ3つのノードの可用性グループがあるとします。すべてのレプリカは同期コミットモードを使用しています。
さらに、私は 設定済みの読み取り専用ルーティング があると仮定します。これにより、ApplicationIntent=Read-Onlyを使用したリクエストがセカンダリレプリカに接続します。
読み取り/書き込み接続を介して変更をコミットした場合、ApplicationIntent=Read-Only接続を使用して別の接続を介して変更されたレコードをすばやく選択すると、常に両方のレプリカから一貫した結果が返されると期待できますか？
EDIT-受け入れられた回答をサポートする詳細情報
Microsoftテクニカルペーパー "AlwaysOn：Offloading Read-Only Workloads to Secondary Replicas（Sunil Agarwal、July 2012）" 見出しの下のセクションData Latency読み取り（鉱山を強調）。
セカンダリレプリカで実行されるレポートワークロードには、データレイテンシが発生します。通常、プライマリワークロードとネットワークレイテンシに応じて、数秒から数分かかります。 データレイテンシは、セカンダリレプリカを同期モードに構成した場合でも存在します。同期レプリカは、コミットされたトランザクションのトランザクションログレコードをプライマリにACKを送信する前に強化することにより、理想的な状態（つまり、RPO = 0）でデータの損失がないことを保証するのに役立ちますは、セカンダリレプリカのREDOスレッドが実際に関連するログレコードをデータベースページに適用したことを保証しません。そのため、データの待ち時間が発生します。セカンダリレプリカを非同期モードで構成した場合、このデータ待機時間が発生する可能性が高いのではないかと思われるかもしれません。これは答えるのが難しい質問です。プライマリレプリカとセカンダリレプリカの間のネットワークがトランザクションログトラフィックに対応できない場合（つまり、十分な帯域幅がない場合）、非同期レプリカがさらに遅れて、データの待ち時間が長くなる可能性があります。同期レプリカの場合、ネットワーク帯域幅が不十分であってもセカンダリでのデータ待ち時間は長くなりませんが、トランザクションの応答時間とプライマリワークロードのスループットが低下する可能性があります。
レポートワークロードがデータ遅延を許容できない場合は、プライマリレプリカで実行する必要があります。良いニュースは、ほとんどのレポートワークロードは、ある程度のデータ遅延を許容できるため、セカンダリレプリカに安全に移行できることです。
Microsoftのドキュメントの幅は矛盾していませんが、もっと明確になっていると思います。 「同期」は、 [〜＃〜] acid [〜＃〜] の頭字語で使用されているように、原子性と一貫性を意味しません。
SYNCHRONIZED状態では、セカンダリ（ログがディスクに書き込まれる）によって書き込みがハード化されることのみが保証されます。 適用された（データが変更された）ことについては何も述べていません。
常に両方のレプリカから一貫した結果が返されることを期待できますか？
はい。読み取りは常にconsistentです。ただし、リレーショナル用語では、整合性（ACID）は分散（CAP）整合性とは異なる意味を持つことに注意してください。 最新の一貫した状態を読み取ることは保証されていません。特に、自分がコミットした書き込みを読み取る保証はありません。また、各レプリカからの読み取りは、それぞれが一貫しているものの、一致しない場合があります。