2009-06-26 141 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