經常需要同步一個數據庫中主表中的數據以克隆其他數據庫中的表(通常在其他服務器上)。例如,考慮後端系統管理庫存數據並且庫存數據最終必須推送到作爲網站應用程序一部分的一個或多個數據庫的情況。單向數據庫同步
後臺系統中的源數據嚴重規範化,有數十個表和外鍵約束。這是一個設計良好的OLTP RDBMS系統。許多表格都包含數百萬行。需要將這些數據定期推送到其他數據庫。儘可能頻繁;延遲是可以容忍的。最重要的是,後端和遠程數據庫的最大正常運行時間是必不可少的。
我正在使用SQL Server,並且熟悉更改跟蹤,rowversion,觸發器等等。我知道Microsoft爲這些場景大量推送複製,SyncFx和SSIS。但是,供應商的白皮書和推薦技術的概述與解決方案的實際實施,部署和維護之間存在很大差異。在SQL Server領域,複製通常被視爲一攬子解決方案,但我正在嘗試探索備用解決方案。 (有些人擔心複製難以管理,難以更改模式,並且在需要重新初始化的情況下,關鍵系統的停機時間會很長。)
有很多問題。由於大量表格之間存在複雜的外鍵關係,因此確定要執行的操作順序是捕獲還是應用更新並非微不足道。由於唯一索引,兩行可能會互鎖,以致一次一行更新甚至無法工作(需要在最終更新之前對每行執行中間更新)。這些不一定是show-stoppers,因爲唯一索引通常可以更改爲常規索引,並且可以禁用外鍵(儘管禁用外鍵是非常不可取的)。通常,您會聽到「只是」使用SQL 2008更改跟蹤和SSIS或SyncFx。這些答案實際上並不符合實際的困難。 (當然,客戶真的很難考慮如何複製數據如此困難,從而使情況變得更糟!)
此問題最終非常通用:執行許多單向同步大量相關的數據庫表。幾乎所有參與數據庫的人都必須處理這類問題。白皮書是常見的,實用的專業知識很難找到。我們知道這可能是一個棘手的問題,但工作必須完成。讓我們聽聽什麼對你有用(以及要避免什麼)。告訴您使用Microsoft產品或其他供應商的產品的經驗。但是,如果你個人沒有經過大量嚴重相關的表格和行的戰鬥測試,請不要回答。讓我們保持這種實際 - 而不是理論。
謝謝,但我從數據庫開發人員的角度來看待這個問題,而不是服務器管理員。從前期的軟件設計角度來看,這非常重要,而不僅僅是操作問題。 – 2009-06-26 15:23:51