我们在1年前开始了一些海外合并复制,到目前为止一切都很顺利。我的问题是,我们的系统中现在有如此多的数据,其中一个用户的服务器上的任何崩溃都将是一场灾难:重新初始化订阅标准方式需要几天(我们的联系肯定很慢,但已经非常昂贵)!我一直在跟进的想法如下:

  1. 制作原件的副本 数据库,冻结它,发送文件 乘飞机到订户,和 无需启动复制 快照:这是真的 完成传统与旧的 SQL的版本,但听起来像 对我来说有点麻烦:我会的 将我的出版商的数据放入 只读模式并停止所有 重复,直到操作 完成。
  2. 制作数据的快照, 将快照文件发送到国外, 将它们安装在订户上,并且 指示新的快照位置 作为一个替代位置 复制属性。这个 对我来说听起来很公平(没有必要暂停正在进行的复制,没有数据冻结),但是,就此而言 点,微软的帮助不... 帮助。
  3. 我相信你们中的一些人已经经历过这样的情况。你有什么选择?

    编辑:当然,人们可以说“你为什么不试试你的想法”,但这需要几个小时(多个sql-servers,虚拟机和所有这些东西的实例...... ),我认为做这件事的人只需要2分钟来解释他的想法。如果有人接受了2分钟的时间来节省我几个小时的辛苦工作,那我就是最开心的人......

有帮助吗?

解决方案

在将数据从加利福尼亚州洛杉矶复制到中国时,我不得不做类似的事情。使用常规方法加载快照需要44天。

我所做的是将SQL Replication配置为使用快照的本地路径。然后我禁用了事务性作业(在您的情况下是合并作业)。然后我跑了一下。我拉上了快照并将文件从加利福尼亚FTP到中国。当他们到达中国时,我将它们解压缩并将它们放在我在加利福尼亚州使用的文件夹路径中。

然后我从中国服务器上的命令行运行distrib.exe。这将数据加载到中国的表格中。加载快照后,关闭中国服务器上的经销商,启动加利福尼亚服务器上的普通经销商。

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

如果您的数据需要花费几天时间才能到达目的地,那么您将需要编辑发布并增加可排队的数据量或订阅者将超时并且新快照将需要采取。

其他提示

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

只是为了让事情变得更加困难,至少在SQL 2000中,如果压缩的驾驶室超过4 Gig,快照将会失败。

我能提供的最好建议是确保每个站点都有良好的备份。这样,至少数据不必手动传送给用户。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top