通过不可靠通道进行事务性数据库复制
我想在两个办事处之间设置数据库复制（事务性），我想知道是否建议通过不可靠的渠道进行此操作？我计划在互联网上的 VPN 上设置此事务复制，并且我正在尝试解决互联网连接中断的问题。我还应该考虑其他事务复制问题吗？
另外，我无法弄清楚具有可更新订阅的事务复制和合并复制之间的区别，是否有任何推荐的复制最佳实践的文章/书籍。
我希望在 SQL Server 2008 上设置此复制。提前致谢。
I wanted to set up database replication (transactional) between 2 offices and I was wondering if it's advised to do so over an unreliable channel? I plan to set up this transactional replication on a VPN over the internet, and I'm trying to account for disruptions to the internet connection. Are there any other transactional replication issues I should take into account?
Also, I haven't been able to figure out the difference between transactional replication with updatable subscriptions and merged replication, is there any recommended article/book for replication best practices.
I'm hoping to set up this repliction on SQL Server 2008. Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们在客户端大量离线的情况下使用合并复制取得了很大的成功，我们可以进行两种方式的更改。合并复制的界面和设置相当简单。我们遇到的唯一真正的挑战是日志记录/验证级别。如果这些设置很高，可能会导致一些真正令人痛苦的性能问题。 Microsoft 关于合并复制的文档非常好，社交 MSDN 上的复制论坛也非常好（您将从 Hilary Cotter (MVP) 等人的问题中得到一些很好的答复）。
使用 VPN 可能是合并复制的一个很好的选择，尽管实际上取决于数据量等。我有大约 20 个订阅，它们经常离线，并且使用合并复制时几乎没有问题，但它们没有执行大量事务。
We have had a lot of success using Merge Replication with a scneario where the clients are offline quite a bit and we can have two way changes. The interface and setup for Merge Replication was fairly painless. The only real challenges we had was with the logging / validation levels. IF these are set to high it can cause some real pain staking performance issues. The Microsoft documentation on Merge replication is really good and the Replication Forums on Social MSDN are also very good (You will get some good responses to questions from folks like Hilary Cotter (MVP)).
Using VPN could be a good candiate for Merge Replication although really depends on amount of data, etc. I have about 20 subscriptions that are offline a lot and have very little issues using Merge Replication, but they are not performing large amounts of transactions.