【问题标题】:SQL Server replication to AzureSQL Server 复制到 Azure
【发布时间】:2016-06-25 04:51:41
【问题描述】:

我们有一个 Access 前端和一个 SQL Server 后端。

由于合同变更,我们现在需要让客户访问我们的数据库。

我们针对 Azure 中的数据库副本测试了我们的前端,但发现它滞后。

是否有将我们的 SQL Server 数据库复制到 Azure 的机制,允许客户端访问它并进行更改,并将这些更改复制回我们的 SQL Server 数据库?

这就是 SQL Server 中的点对点复制吗?

我读了这个博客,它似乎描述了我在寻找什么:http://tk.azurewebsites.net/2012/07/17/how-to-setup-peer-to-peer-replication-in-azure-iaas-sql-server-2012/

【问题讨论】:

  • 为什么不公开本地 SQL 实例,以便他们可以远程访问它?那么你就没有复制了。像这样的 p2p/replication 对我来说有一种强烈的难闻气味......复制是一个有点复杂的场景,但在你的情况下,如果你基本上只是将它用于备份,那么它可能没问题。
  • 要访问 FE/Azure BE 性能,请在此处阅读:dymeng.com/techblog/azure-series-05-database-performance
  • 我们需要一个快速(廉价)的解决方案。将我们的服务器暴露给客户端是不可能的。

标签: sql-server azure ms-access azure-sql-database


【解决方案1】:

如果您觉得必须使用复制,我认为选择的最佳方法取决于您的客户查看数据的需求。

提供三种核心类型的复制:

  • 事务性(非常精细,事务从发布者推送到订阅者)
  • 合并复制:通过使用触发器完成
  • 快照:通过从发布者推送到订阅者的时间点快照完成。

(更多信息在这里,随后的链接指向每个详细的用例/行为):https://msdn.microsoft.com/en-us/library/ms152531(v=sql.120).aspx

点对点是一种事务复制。如果您的客户只希望能够读取数据库,这可能是矫枉过正。我认为快照的侵入性最小,并为它们提供合理的数据间隔。

我想知道是否有任何理由不能通过 TCP 公开当前的本地 SQL 和数据库?似乎会更容易一些:给他们一个只读登录名,他们可以随时检查。同样,我想这取决于他们的要求。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2015-09-11
    • 2013-05-09
    • 2019-03-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-12-01
    • 2013-01-08
    相关资源
    最近更新 更多