SQL 2008R2中跨服务器的数据库同步

您可以通过订阅，镜像或日志传送（或者在许多情况下复制types – 例如镜像和订阅可用性和分区）来执行复制。 问题是复制背后的目标是什么。 此外，为什么不把这样的东西迁移到亚马逊，azure色或任何数量的基于云的解决scheme，以解决所有这些types的问题，以及您可能没有想到的问题（备份，地理负载平衡 – 只是离开我的头顶）

对于我的钱来说，云就是您开始寻找地理分布解决scheme的答案的地方。

我们如何处理这种情况是我们使用对等（PTP）复制。 这使我们不仅可以跨两个独立的数据中心同步数据库，而且还可以灵活地同步我们关心的用户数据表而不logging数据。

性能明智的PTP同步对于我们来说是相对即时的，这显然取决于数据中心与站点之间有多lessstream量之间的联系。 如果需要，PTP也使我们能够让我们的服务器独立于另一个服务器。

经验最大的问题之一就是适当地设置主键。 如果你使用guid作为你的主键，那么没有任何问题，但是增加身份列变得棘手，因为每个数据库都是相互独立的。 因此，您需要确保在服务器2上不会生成由服务器1上的标识列生成的密钥，否则复制将会遇到错误，因为由于主键违反而无法插入新logging。

这可以通过将每个表的标识种子设置为不同的值来解决。 例如，服务器1将具有1的身份种子开始，并且服务器2将具有1000000的身份种子开始。 另一种select是稍微交错身份种子，并增加PTP复制scheme中服务器的数量。 因此，在2服务器示例中，服务器1将从种子1开始，服务器2将从种子2开始，同时递增值为2。

对于Google的背景，“Brewer的CAP定理” – 基本上说，你不能复制高度可用的交易一致的蛋糕，并把它吃掉。

有很多方法可以做到这一点，我不认为你已经告诉我们足够的规定性的build议，但基本上你可以在应用程序，数据库或虚拟机级别做到这一点。

添加复制到应用程序往往是困难的，所以我会尽可能避免这种情况。

如果你select在数据库中做到这一点：

事务复制非常适合提供近实时的只读数据库副本。 它允许您select单独的表，所有列的子集，甚至在出版物中进行行筛选，适应连接性问题，多个订户和一个很好的pipe理界面。 您可以使用一些技巧来在订阅者中启用有限的写入function，但这些技巧很复杂。

合并复制提供了多主复制副本，但具有繁重的模式要求，作为其devise的一部分具有冲突，并且具有可扩展性和可靠性问题。 避免。

点对点复制。 这我从来没有用过，但它是build立在事务复制上的，所以应该可以，但强烈的build议是只允许单个节点上的更新来防止

数据库镜像仅适用于连接良好的情况 – 即相同的数据中心。 在标准实现中，如果镜像的一个成员失败，则交易将停止。 同步事务镜像还会减慢生产服务器的速度。 避免。

你的问题并没有说明你为什么要复制 – 无论是为了性能还是容错，或者是什么，但是我build议你考虑一下，例如一个SQL Azure实例是否能够满足你的需求。

祝你好运。

数据库复制并不能真正提高性能，因为两台服务器仍然需要处理和存储所有更改。

跨地理位置的服务器可能需要考虑联合分区，但这不是初学者的主题。

数据库镜像不可写。

你可能想看看红门软件的SQL数据比较 – 这将允许你同步数据库之间的数据。

他们也有一个SQL比较产品，只是同步模式的变化。