代码之家 › 专栏 › 技术社区 › Jason Kresowaty

单向数据库同步

data-synchronization database sql

Jason Kresowaty · 技术社区 · 15 年前

通常需要将一个数据库中主表的数据同步到其他数据库(通常在其他服务器上)中的克隆表。例如,考虑这样一种情况:后端系统管理库存数据,而库存数据最终必须推送到作为网站应用程序一部分的一个或多个数据库。

我使用的是SQL Server,熟悉更改跟踪、行版本、触发器等。我知道Microsoft在这些场景中大力推广复制、SyncFx和SSIS。但是,供应商白皮书和概述推荐的技术与解决方案的实际实现、部署和维护之间存在很大差异。在SQL Server世界中,复制通常被视为交钥匙解决方案,但我正在尝试探索其他解决方案。(有些人担心复制很难管理,很难更改架构,而且在需要重新初始化的情况下,关键系统会有大量的停机时间。)

有很多陷阱。由于大量表之间存在复杂的外键关系,确定执行捕获或应用更新的顺序并非易事。由于索引是唯一的,所以两行可能以这样一种方式互锁:一次更新一行甚至不起作用(需要在最终更新之前对每一行执行中间更新)。这些不一定是show stopper,因为唯一索引通常可以更改为常规索引,并且可以禁用外键(尽管禁用外键是非常不可取的)。通常,您会听到“just”use sql2008 change tracking和SSIS或SyncFx。这种回答确实不能解决实际困难。(当然,客户真的很难理解复制数据是多么的困难,这使得困难的情况更加糟糕!)

这个问题最终是非常普遍的:对具有大量行的许多高度相关的数据库表执行单向同步。几乎所有参与数据库的人都必须处理这种问题。白皮书很常见,很难找到实用的专业知识。我们知道这可能是一个困难的问题,但这项工作必须完成。让我们来听听什么对你有效(以及避免什么)。讲述您对Microsoft产品或其他供应商产品的体验。但是,如果您个人没有使用大量高度相关的表和行对解决方案进行过测试,请不要回答。让我们保持这个实用性——而不是理论性。

1 回复 | 直到 5 年前

Remus Rusanu 15 年前

最好继续问服务器故障.com(我不能发表评论,脚本被打断了,所以我必须发表一个完整的答案)

没有银弹。对于易用性和“一键转向”部署,没有什么能打败复制。是唯一的解决方案 深深地

用于推动变革的技术是原始的、缓慢的和不可靠的。它需要文件共享来启动复制副本,而实际复制数据又依赖于T-SQL,这导致了各种可伸缩性问题:复制线程使用服务器工作线程,而它们与任意表和应用程序查询交互的事实导致阻塞和死锁。我听说过的最大的部署是大约400-500个站点,由超人mvp和顶级顾问完成。这就阻碍了许多项目的发展开始在1500个站点(远远超过最大的已部署复制项目)。我很想知道我是否错了,您是否知道部署了500多个站点的SQL Server复制解决方案。
复制的比喻过于以数据为中心。它没有考虑分布式应用程序的需求:需要版本化和形式化的契约、数据的自治性 fiefdoms ,从可用性和安全性角度进行松耦合。因此,基于复制的解决方案解决了“在那里提供数据”的迫切需要,但未能解决“我的应用程序需要与你的应用程序对话”的真正问题。

另一方面,您将找到真正解决应用程序通信问题的解决方案,比如基于排队消息传递的服务。但要么速度慢得令人痛苦,要么充满了源于通信机制(web服务和/或msmq)和数据存储(comm和db之间的DTC事务,没有共同的高可用性故事,没有共同的可恢复性故事等)分离的问题。解决方案 blazingly fast and fully integrated with DB exists in the MS stack

我参与了几个项目,这些项目需要大规模的“数据同步”(+1200个站点,+1600个站点),我的解决方案是将问题转化为“应用程序通信”问题。一旦改变了这种思维方式,数据流就不再被视为“用表Y的键X记录”,而是“客户Y购买商品X的消息”,解决方案就变得更容易理解和应用。您不再考虑“按X-Y-Z顺序插入记录以便FK关系不会中断”,而是考虑“按消息XYZ描述的流程购买”。