2009-06-26 111 views
6

經常需要同步一個數據庫中主表中的數據以克隆其他數據庫中的表(通常在其他服務器上)。例如,考慮後端系統管理庫存數據並且庫存數據最終必須推送到作爲網站應用程序一部分的一個或多個數據庫的情況。單向數據庫同步

後臺系統中的源數據嚴重規範化,有數十個表和外鍵約束。這是一個設計良好的OLTP RDBMS系統。許多表格都包含數百萬行。需要將這些數據定期推送到其他數據庫。儘可能頻繁;延遲是可以容忍的。最重要的是,後端和遠程數據庫的最大正常運行時間是必不可少的。

我正在使用SQL Server,並且熟悉更改跟蹤,rowversion,觸發器等等。我知道Microsoft爲這些場景大量推送複製,SyncFx和SSIS。但是,供應商的白皮書和推薦技術的概述與解決方案的實際實施,部署和維護之間存在很大差異。在SQL Server領域,複製通常被視爲一攬子解決方案,但我正在嘗試探索備用解決方案。 (有些人擔心複製難以管理,難以更改模式,並且在需要重新初始化的情況下,關鍵系統的停機時間會很長。)

有很多問題。由於大量表格之間存在複雜的外鍵關係,因此確定要執行的操作順序是捕獲還是應用更新並非微不足道。由於唯一索引,兩行可能會互鎖,以致一次一行更新甚至無法工作(需要在最終更新之前對每行執行中間更新)。這些不一定是show-stoppers,因爲唯一索引通常可以更改爲常規索引,並且可以禁用外鍵(儘管禁用外鍵是非常不可取的)。通常,您會聽到「只是」使用SQL 2008更改跟蹤和SSIS或SyncFx。這些答案實際上並不符合實際的困難。 (當然,客戶真的很難考慮如何複製數據如此困難,從而使情況變得更糟!)

此問題最終非常通用:執行許多單向同步大量相關的數據庫表。幾乎所有參與數據庫的人都必須處理這類問題。白皮書是常見的,實用的專業知識很難找到。我們知道這可能是一個棘手的問題,但工作必須完成。讓我們聽聽什麼對你有用(以及要避免什麼)。告訴您使用Microsoft產品或其他供應商的產品的經驗。但是,如果你個人沒有經過大量嚴重相關的表格和行的戰鬥測試,請不要回答。讓我們保持這種實際 - 而不是理論。

回答

7

,你最好去問上serverfault.com(我不能發表評論,腳本在SO壞了,所以我要發佈一個完整的答案)

更新:(切換到Safari瀏覽器,腳本重新工作,我可以正確發帖)

沒有銀彈。爲了便於使用和「一鍵轉」部署,沒有任何東西可以打敗複製。是唯一一個涵蓋深度衝突檢測和解決方案的解決方案,它支持推送模式更改並附帶一套完整的工具來設置和監控它。在這個「議程」被.Net人羣接管之前,它一直是數據同步的MS海報孩子。在我看來,複製有兩個基本問題:

  • 用於推送更改的技術是原始的,緩慢的和不可靠的。它需要文件共享來啓動副本,並且它依賴於T-SQL來實際複製數據,從而導致各種可伸縮性問題:複製線程使用服務器工作線程,並且它們與任意表和應用程序查詢交互的事實導致阻塞和死鎖。我聽說的最大的部署是大約400-500個站點,由超人MVP和頂級美元顧問完成。這在其軌道上停止了許多項目,其中在1500個站點處開始(超出最大部署的複製項目的方式)。我很想知道我是否錯了,並且知道部署了超過500個站點的SQL Server複製解決方案。
  • 複製的比喻太數據中心。它沒有考慮到分佈式應用程序的需求:需要版本化和正式的合同,數據的自主性'fiefdoms',與可用性和安全性的鬆散耦合。因此,基於複製的解決方案解決了「使數據在那裏可用」的迫切需求,但卻無法解決「我的應用需要與您的應用交談」的真正問題。

另一方面,您會發現真正解決應用程序通信問題的解決方案,例如基於排隊消息的服務。但無論是痛苦的緩慢和充滿了根植於通信機制(Web服務和或MSMQ)和數據存儲(通訊和db,沒有共同的高可用性的故事,沒有共同的可恢復性的故事等等等等之間DTC交易)的分離問題。解決方案是blazingly fast and fully integrated with DB exists in the MS stack,但沒有人知道如何使用它們。在這些與複製之間的某處,您可以找到各種中間解決方案,如OCS/Synch框架和基於SSIS的定製解決方案。沒有人會提供複製安裝和監控的簡易性,但它們可能會擴展並且性能更好。

我參與了,需要一個非常大的規模「數據同步」的幾個項目(+ 1200點,+1600點)和我的解決辦法是把這一問題上的「應用程序通信」的問題。一旦心態被改變爲這種情況,數據流不再被視爲'用表格Y的關鍵字X記錄',而是'消息傳達由客戶Y購買項目X',該解決方案變得更容易理解和應用。您不再考慮'按X-Y-Z順序插入記錄,因此FK關係不會中斷',而是按'消息XYZ'描述的'流程購買'來考慮。

我認爲複製,並且它衍生物(即數據跟蹤和數據克運費),都是在'80技術和視圖中的數據/應用的錨定的解決方案。過時的恐龍(絕不會變成鳥類)。

我知道這並不甚至開始解決你所有的(非常正式的)的擔憂,但寫出所有我不得不說關於這一主題/咆哮/ rable將填補平裝冊...

+0

謝謝,但我從數據庫開發人員的角度來看待這個問題,而不是服務器管理員。從前期的軟件設計角度來看,這非常重要,而不僅僅是操作問題。 – 2009-06-26 15:23:51