[SQL Server] AlwaysOn 同步認可時的短暫延遲現象

為了降低主要複本負載,除了倉儲與報表作業讀取非同步認可的複本,最近計畫把線上交易查詢改道同步認可的複本,一種類讀寫分流

開始測試網站,就在明細頁修改完資料(主要複本)回到清單頁重查資料時(次要同步複本),顯示的還是舊資料?

寫一段單元測試來觀察,測試程式的流程:

  • 1.更新主要複本內特定資料列的值。
  • 2.迴圈查詢次要複本,直到查詢到與主要複本有相同的值。

SQL Server 版本:Microsoft SQL Server 2012 (SP1) - 11.0.3153.0 (X64) Enterprise Edition (64-bit)

驚! 0.1秒(153毫秒),真的出現延遲!

驚!驚! 0.3秒(320毫秒)

延遲時間落在0.1-0.4秒間(默默記下RPO)

 

一直認為AlwaysOn也把同步複本處理在ACID的範圍內,但理所當然的"隔離(Isolation)"竟然沒發生,查看同步設定,次要複本確實是設定同步複本啊!

有圖有真相:

 

好!又是釐清觀念的時間了: AlwaysOn Data Synchronization Process流程

主要複本偵測Log的產生、傳送,次要同步複本接收、Log Flush到Disk,最後才redo回次要複本上的Data Page!
好用的AlwaysOn就少了次要複本維持ACID的步驟,讀寫分流就好像破了馬拉松PB才發現這場里程數不足。(低頭喪志)

 

回到MSDN上的AlwaysOn 可用性群組 (SQL Server)介紹

「同步認可模式」(Synchronous-Commit Mode)。這種可用性模式強調的是高可用性資料保護非效能,但是相對地增加了"交易延遲"。

 

TODO:
同步複本(Synchronous)和非同步複本(Asynchronous)延遲性的差別?

 

參考:

AlwaysOn 可用性群組 (SQL Server)介紹

AlwaysOn Data Synchronization Process