通过 WAN 进行 Sql Server 复制
我正在考虑开发一个简单的电子商务平台,需要通过互联网将产品和客户数据复制到网络主机,以便网站可以离线运行。我目前能想到的两个选项是使用企业消息传递和数据库复制。
我倾向于企业消息传递上的数据库复制,因为企业消息传递需要额外的开发人员资源来编写所有管道代码。有人通过互联网在不可靠的 WAN 链接上使用 sql server 单向复制取得过任何成功吗?
Im looking at developing a simple ecommerce platform and need to replicate product and customer data to the web host over the internet so the website can run disconnected. The two options i can think of at present are using enterprise messaging and database replication.
Im leaning towards database replication over enterprise messaging as enterprise messaging would require additional developer resource to write all the plumbing code. Anyone have any success using sql server one way replication over unreliable wan links through the internet?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
很抱歉我错过了这个... Nitrosphere.com 的 NitroAccelerator 正是为了加速互联网上的复制而构建的。它非常有效地压缩 TDS 数据包,并使复制时间缩短 80-90%。
I'm sorry I missed this... NitroAccelerator from Nitrosphere.com is built exactly to speed up replication over the internet. It compresses the TDS packets very efficiently and results in 80-90% improvement in replication times.
在我工作的上一家公司中,我们为一些客户提供了完整的合并复制。
有 2 种情况
合并复制
我们的一些客户拥有 PDA,他们订阅了我们主数据库的一些已发布表格。它们长时间断开连接,合并复制工作正常,并在连接恢复时更新了双方的更改
完整站点到站点合并复制
这适用于拥有远程办公室但出于性能原因需要完全同步的本地数据库的客户。在大多数情况下,VPN 的性能非常差,我们确实有一些 VPN 停机一周的实例,并且在恢复复制时同步两个数据库没有出现问题。
在这两种情况下,复制似乎都具有很强的容错能力并且执行得非常好。
在您的情况下,它是单向复制,因此不应该没有合并冲突来处理,使情况变得更容易。
复制有一个学习曲线,但作为一项技术,我发现即使在连接较差的情况下,它也能很好地工作。
利亚姆
In the last company I worked for we had full merge replication for some of our customers.
There were 2 scenarios
Merge Replication for hanadheld devices
Some of our customers had PDAs and they subscribed to some published tables of our main database. They were disconnected for large periods and merge replication worked fine and updated changes on both sides when the connection was restored
Full site to site Merge Replications
This was used for customers that had remote offices but required a fully synchronized local database for performance reasons. In most cases the VPN was extremely poor and we did have some instances of the VPN being down for a week and on restoration replication synchronized both database without an issue.
In both cases replication seems to be very fault tolerant and performed very well.
In your case its one way replication so there should not be no merge conflicts to deal with making the situation easier.
There is a learning curve with replication but as a technology it works very well I found even over poor connections.
Liam