经常需要将一个数据库中的主表中的数据同步到其他数据库（通常位于其他服务器上）中的克隆表。例如，考虑这样一种情况：后端系统管理库存数据，并且库存数据最终必须推送到作为网站应用程序一部分的一个或多个数据库。
后端系统中的源数据高度规范化，有数十个表和外键约束。它是一个精心设计的OLTP RDBMS系统。许多相关表包含数百万行。需要定期将此数据推送到其他数据库。尽可能频繁；延迟是可以容忍的。最重要的是，后端和远程数据库的最大正常运行时间至关重要。
我正在使用 SQL Server，熟悉更改跟踪、行版本、触发器等。我知道 Microsoft 针对这些场景大力推动复制、SyncFx 和 SSIS。然而，供应商的白皮书和概述推荐的技术与解决方案的实际实施、部署和维护之间存在很大差异。在 SQL Server 领域，复制通常被视为交钥匙解决方案，但我正在尝试探索替代解决方案。 （有人担心复制难以管理，难以更改架构，并且如果需要重新初始化，关键系统将会出现大量停机时间。）
有很多陷阱。由于大量表之间存在复杂的外键关系，因此确定执行捕获或应用更新的顺序并非易事。由于唯一索引，两行可能会以这样的方式互锁，以至于一次行更新甚至无法工作（需要在最终更新之前对每行执行中间更新）。这些不一定是表演障碍，因为唯一索引通常可以更改为常规索引，并且可以禁用外键（尽管禁用外键是非常不可取的）。通常，您会听到“仅”使用 SQL 2008 更改跟踪和 SSIS 或 SyncFx。这样的回答确实没有反映实际困难。 （当然，客户确实很难理解复制数据为何如此困难，从而使困难的情况变得更糟！）
这个问题最终是非常普遍的：对许多具有大量行的高度相关的数据库表执行单向同步。几乎每个涉及数据库的人都必须处理此类问题。白皮书很常见，实用的专业知识很难找到。我们知道这可能是一个困难的问题，但工作必须完成。让我们听听什么对您有用（以及应该避免什么）。讲述您使用 Microsoft 产品或其他供应商产品的体验。但是，如果您个人没有使用大量密切相关的表和行对解决方案进行过实际测试，请不要回答。让我们保持实用性——而不是理论性。
最好在 serverfault.com 上询问（我无法发表评论，脚本已损坏，所以我必须发布完整的答案）
更新：（切换到 Safari，脚本再次工作，我可以正确发布）
没有灵丹妙药。为了易于使用和“一键式”部署，没有什么比复制更好的了。是唯一涵盖的解决方案deeply冲突检测和解决，支持推送模式更改，并附带一套用于设置和监控模式的全面工具。在这个“议程”被 .Net 群体接管之前，它多年来一直是 MS 数据同步的典型代表。我认为复制有两个根本问题：
- 用于推动变革的技术原始、缓慢且不可靠。它需要文件共享来启动副本，并且依赖于 T-SQL 来实际复制数据，从而导致各种可扩展性问题：复制线程使用服务器工作线程，并且它们与任意表和应用程序查询交互，从而导致阻塞和僵局。我听说过的最大部署约为 400-500 个站点，由超人 MVP 和顶级顾问完成。这使许多项目停止了轨道start1500 个站点（远远超出了最大的已部署复制项目）。我很想知道我是否错了，并且您知道部署了 500 多个站点的 SQL Server 复制解决方案。
- 复制比喻过于以数据为中心。它没有考虑分布式应用程序的要求：需要版本化和形式化的合同、数据的自治性”fiefdoms http://msdn.microsoft.com/en-us/magazine/cc164125.aspx'，与可用性和安全性观点的松散耦合。因此，基于复制的解决方案解决了“使数据可用”的迫切需求，但未能解决“我的应用程序需要与您的应用程序对话”的真正问题。
另一方面，您将找到真正解决应用程序通信问题的解决方案，例如基于排队消息传递的服务。但要么速度慢得令人痛苦，要么充满了源于通信机制（Web 服务和/或 msmq）与数据存储（comm 和 db 之间的 DTC 事务、没有常见的高可用性故事、没有常见的可恢复性故事等）分离的问题。解决方案是MS 堆栈中速度极快且与 DB 完全集成 http://msdn.microsoft.com/en-us/library/ms166043(SQL.90).aspx，但没有人知道如何使用它们。在这些和复制之间的某个地方，您会发现各种中间解决方案，例如 OCS/Synch 框架和基于 SSIS 的自定义解决方案。没有一个能够提供复制设置和监控的便利性，但它们可能会扩展并表现得更好。
我参与了几个需要大规模“数据同步”的项目（+1200 个站点、+1600 个站点），我的解决方案是将问题转向“应用程序通信”问题。一旦思维方式改变，数据流不再被视为“带有表 Y 的键 X 的记录”，而是“传达客户 Y 购买商品 X 的消息”，解决方案将变得更容易理解和应用。您不再考虑“按 X-Y-Z 顺序插入记录，以免破坏 FK 关系”，而是考虑“按照消息 XYZ 的描述处理购买”。
在我看来，复制及其衍生产品（即数据跟踪和数据报传送）是植根于 80 年代技术和数据/应用程序视图的解决方案。过时的恐龙（并且绝不会变成鸟类）。
我知道这甚至还没有开始解决您所有的（非常合法的）担忧，但是写出我对这个主题的所有要说/咆哮/咆哮将填满大量平装本......
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
