代码之家 › 专栏 › 技术社区 › Philippe Grondier

MS-SQL Server 2005:使用备用快照位置初始化合并订阅

snapshot replication synchronization sql-server

3

Philippe Grondier · 技术社区 · 16 年前

一年前我们开始了一些海外合并复制,到现在一切都很好。我的问题是,我们的系统中现在有太多的数据,以至于订阅服务器上的任何一个崩溃都将是一场灾难:重新启动订阅的标准方式将需要数天时间(我们的连接肯定很慢,但已经非常昂贵)!我一直在跟进的想法包括:

复印原件数据库,冻结它,发送文件乘飞机到订户,以及启动复制而不快照:这是做传统与老年人 SQL的版本,但听起来对我来说有点混乱:我会的将发布者的数据放入只读模式并全部停止复制直到所有操作完整的。
制作数据快照, 将快照文件发送到国外, 在订阅服务器上安装它们,并且指示新快照位置作为复制属性。这一个对我来说是公平的(不需要暂停正在进行的复制,不需要冻结数据),但在这一点上点,Microsoft帮助不… 帮助。

我相信你们中的一些人已经经历过这种情况。你的选择是什么?

编辑:当然,有人会说“你为什么不试试你的想法”,但这需要几个小时(多个SQL服务器实例、虚拟机和所有这些东西……),我想做这件事的人只需要2分钟来解释他的想法。如果有人愿意抽出2分钟的时间来给我工作,我会是最快乐的人…

2 回复 | 直到 16 年前

1

mrdenny 16 年前

当我将数据从加州洛杉矶复制到中国时,我必须做类似的事情。使用常规方法加载快照需要44天。

我所做的是将SQL复制配置为使用快照的本地路径。然后我禁用了事务性作业(在您的情况下是合并作业)。然后我拍了快照。我把快照压缩,然后把文件从加利福尼亚州传送到中国。当他们到了中国,我把他们拉开拉链,放在我在加利福尼亚使用的文件夹路径中。

然后我从中国服务器上的命令行运行distrib.exe。这将数据加载到中国的表中。加载快照后,我关闭了中国服务器上的分发服务器,并在加利福尼亚启动了服务器上的常规分发服务器。

这种方法只花了大约28个小时,而不是一个多月。

如果数据到达目的地需要几天以上的时间,则需要编辑发布并增加可以排队的数据量,否则订阅服务器将超时,需要拍摄新快照。

2

1

user21884 16 年前

我们刚刚经历了这样的事情,但并不漂亮。尽管所有涉及的服务器都是本地的,但这仍然需要很长时间。

为了使事情变得更困难,至少在使用SQL 2000时,如果压缩的cab超过4 gig,快照将失败。

我能提供的最好建议是确保每个站点都有好的备份可用。这样,至少数据就不必手工携带到订阅服务器上了。