始終處於具有大延遲的同步送出模式
對於同步送出模式下的 SQL Server Enterprise 的 Always On 可用性組，是否存在無法超過的延遲量？例如，它可以在非常遙遠的數據中心之間工作，例如在美國和歐洲之間嗎？
您正在尋找的答案在文件中
⚠ 注意
如果輔助副本超過了主副本的會話超時期限，則主副本會暫時切換到該輔助副本的非同步送出模式。當輔助副本與主副本重新連接時，它們會恢復同步送出模式。
發生這種情況時，同步輔助將回退為非同步（有些人稱之為“偽同步”，因為您將其設置為同步，但它實際上是非同步的）。這並非特定於網路延遲或物理距離，而是可能在多種情況下發生。例如，如果您重新啟動同步副本並且該伺服器處於離線狀態，您的 AG 將回退到非同步並繼續處理事務。
同步 AG 僅在寫入事務日誌（需要寫入輔助副本）時付出性能損失。寫入活動通常是數據庫活動的一小部分，大部分流量是讀取操作，不受同步/非同步的影響。
在美國和歐盟之間以同步送出模式執行 AG 是完全可能的。寫入事務會更慢，因為它們需要寫入大洋彼岸的日誌。通常，更好的設計是保持同步副本更接近以避免網路延遲。但是，根據您的數據庫的 IO 模式、您的業務需求以及您在不同地區之間的網路主幹，這是可能的。在我支持的系統上，我們可以容忍數百英里的同步送出延遲——但是當距離變得更長時，性能影響就會變得太大。並不是 SQL Server 不能支持它——而是使用者不能容忍這種緩慢。
通常，我發現大多數人最終會在數據中心/地理區域內執行同步送出以實現高可用性，並在地理/數據中心之間執行非同步送出以實現災難恢復。對於跨地區的計劃故障轉移，您可以將遠端副本臨時切換到同步模式，以確保在故障轉移期間不會失去數據。
找出對應用程序的實際影響的最簡單方法是對其進行測試。
輔助副本幾乎不應該配置為同步模式，特別是如果主副本和輔助副本之間存在延遲，因為它會導致主副本的性能下降，從而導致爭用問題等等。此外，請記住，兩個數據中心總是會出現網路斷開連接……當您在同步模式下工作時，您可以將其視為幾乎是兩階段送出。