单向数据库同步

通常需要将来自一个数据库中的主表的数据同步到其他数据库中的克隆表,通常是在其他服务器上.例如,考虑后端系统管理库存数据并且最终必须将库存数据推送到属于网站应用程序的一个或多个数据库的情况.

后端系统中的源数据严格标准化,具有数十个表和外键约束.它是一个精心设计的OLTP RDBMS系统.许多表中包含数百万行.需要定期将这些数据推送到其他数据库.尽可能频繁; 可以容忍延迟.最重要的是,后端和远程数据库的最大正常运行时间是必不可少的.

我正在使用SQL Server,熟悉更改跟踪,rowversion,触发器等.我知道微软会为这些场景大量推送复制,SyncFx和SSIS.但是,供应商白皮书和概述推荐技术以及解决方案的实际实施,部署和维护之间存在很大差异.在SQL Server世界中,复制通常被视为交钥匙解决方案,但我正在尝试探索替代解决方案.(有些人担心复制难以管理,难以更改架构,并且如果需要重新初始化,关键系统的停机时间会很长.)

有很多陷阱.由于大量表之间存在复杂的外键关系,因此确定执行捕获或应用更新的顺序并非易事.由于唯一索引,两行可能会以这样的方式互锁,即一次一行更新甚至不起作用(需要在最终更新之前对每一行执行中间更新).这些不一定是show-stoppers,因为唯一索引通常可以更改为常规索引,并且可以禁用外键(尽管禁用外键是非常不合需要的).通常,您会听到"只是"使用SQL 2008更改跟踪和SSIS或SyncFx.这些答案实际上并不符合实际困难.(当然,客户真的很难理解如何复制数据如此困难,使情况变得更糟!)

这个问题最终非常通用:执行许多重度相关的数据库表的单向同步.几乎每个参与数据库的人都必须处理这类问题.白皮书是常见的,实用的专业知识很难找到.我们知道这可能是一个难题,但工作必须完成.让我们来听听对你有用的东西(以及要避免的东西).告诉您使用Microsoft产品或其他供应商的产品的经验.但是,如果你个人没有对大量严重相关的表和行进行战斗测试,请不要回答.让我们保持这种实际 - 不是理论上的.

更好地询问serverfault.com(我无法发表评论,脚本在SO中被破坏,所以我必须发布完整答案)

更新:(切换到Safari,脚本再次工作,我可以正确发布)

没有银弹.为了便于使用和"一键转"部署,没有什么能够击败复制.是覆盖的唯一解决方案深深冲突检测和解决,对推动模式变化的支持,并配有设置它和监视它的全面的工具集.在这个"议程"被.Net人群接管之前,它已成为多年来数据同步的MS典型代表.在我看来,复制有两个潜在的问题:

用于推动变革的技术是原始的,缓慢的和不可靠的.它需要文件共享来启动副本,它依赖于T-SQL来实际复制数据,从而导致各种可伸缩性问题:复制线程使用服务器工作线程,以及它们与任意表和应用程序查询交互的事实导致阻塞和死锁.我听说过的最大部署是大约400-500个站点,由超人MVP和顶级美元顾问完成.这会阻止许多项目从 1500个站点开始(超出最大部署的复制项目).我很想知道我是否错了,你知道部署了超过500个站点的SQL Server复制解决方案.

复制隐喻太以数据为中心.它没有考虑分布式应用程序的要求:需要版本化和正式化的合同,数据" 领域 "的自主性,可用性和安全性pov的松散耦合.因此,基于复制的解决方案解决了"在那里提供数据"的迫切需求,但未能解决"我的应用需要与您的应用交谈"的真正问题.

在频谱的另一端,您将找到真正解决应用程序通信问题的解决方案,例如基于排队消息传递的服务.但要么是痛苦地缓慢而且充满了根植于通信机制(Web服务和/或msmq)和数据存储(通信和数据库之间的DTC事务,没有共同的高可用性故事,没有共同的可恢复性故事等等)的问题.MS堆栈中存在速度极快且与DB完全集成的解决方案,但没有人知道如何使用它们.在这些和复制之间的某处,你会发现各种中间解决方案,如OCS/Synch框架和基于SSIS的自定义解决方案.没有人会提供复制的简易设置和监控,但它们可能会扩展并且性能更好.

我参与了几个需要大规模"数据同步"的项目(+1200个站点,+ 1600个站点),我的解决方案是将问题转化为"应用程序通信"问题.一旦思维模式改变为此并且数据流不再被视为"使用表Y的密钥X记录",而是"消息传达由客户Y购买项目X",则解决方案变得更容易理解和应用.您不再考虑"按XYZ顺序插入记录,以便FK关系不会中断",而是根据消息XYZ描述的"流程购买".

在我看来,复制及其衍生产品(即数据跟踪和数据传输)是固定在'80技术和数据/应用程序视图中的解决方案.过时的恐龙(绝不会变成鸟类).

我知道这甚至没有开始解决你所有的(非常合法的)问题,但写出我要说的所有内容/咆哮/ rable这个话题将填补大量的平装书......