2010-01-15 20 views
4

我的web應用程序對SQL Server 2008使用ADO.NET。數據庫寫入是針對主(發佈程序)數據庫發生的,但讀取在主要和次要(訂戶)數據庫。我們使用SQL Server的內置事務複製來保持次級最新。大多數情況下,幾秒鐘的延遲時間不成問題。等待ADO.NET或TSQL中的事務複製

但是,我確實有一個情況,我想阻止該事務在輔助站點上提交。阻塞幾秒鐘即可,但是向用戶返回一個陳舊的頁面不是。 ADO.NET或TSQL中是否有任何方法來指定我想等待複製完成?或者,我可以從發行商處檢查事務的複製狀態,而無需手動連接到輔助服務器。

99.9%的時間,訂戶中的數據「足夠新鮮」。但有一項操作使其無效。我無法從出版商那裏瞭解到每次都有可能失效。如果我在事務複製下無法解決這個問題,您能否提出一個備用架構?

回答

2

有沒有這樣的SQL Server解決方案,但這是我在其他環境中解決它的方式。在您的應用程序

使用三個獨立的連接字符串,並選擇基於查詢的需要是正確的:

  • 實時 - 直接指向一個主服務器。所有寫入到這個連接字符串,並且只有最關鍵的任務讀取到這裏。
  • 近實時 - 在負載均衡的用戶池中的點數。沒有寫入這裏,只讀。用於絕大多數OLTP讀取。
  • 延遲報告 - 現在在您的環境中,它將指向相同的負載平衡用戶池,但您可以使用類似日誌傳送技術的服務器擁有8-24小時的服務器池。這些擴展非常好,但數據遠遠落後。這對報告,搜索,長期歷史記錄和其他非實時需求非常有用。

如果您從一開始就將應用程序設計爲使用這3個連接字符串,縮放比較容易,特別是在遇到這種情況時。

+0

非常感謝。我大概認爲這是我們需要做的,但很高興得到確認。 – solublefish 2010-01-24 20:18:36

0

您正在描述同步鏡像情況。根據定義,複製不能支持您的需求。複製必須在從日誌中讀取並將其交付給分發服務器並從訂閱服務器傳輸到訂閱服務器之前等待事務提交,這意味着根據定義進行復制具有數據不同步的機會窗口。

如果您有要求閱讀授權數據副本的操作,那麼您應該在客戶端做出決定,並確保您在該情況下從發佈者那裏讀取數據。

雖然您可以在確認某個交易是否已分配給訂戶時進行驗證,但您不應將其設計基於此。事務複製無法保證延遲,因此您無法依賴「完美的一天」操作模式。

+0

感謝您的意見。請參閱編輯。 – solublefish 2010-01-16 21:12:07