如何在内部执行azure sql geo复制？

Question

我的公司搬到azure，并开始使用azure Sql数据库和geo复制。

对于我们的前提服务器，我们严重依赖微软事务性复制来移动数据.现在，我们在前提服务器(publisher)和azure之间设置事务性复制。然后，我们发现事务性复制本身在azure上不断地消耗100%的DTU (我们使用的是125个DTU P1)。

我们将它升级到250个DTU，而复制则要高兴得多。然而，我们不确定这是一个伟大的想法，不断更新到更高的DTU。所以我们做了这个：

1. 创建了两个125 two服务器。
2. 在前提服务器和服务器A之间设置事务复制。
3. 在服务器A和服务器B之间建立地理复制。
4. 我们的客户将使用服务器B。

好处是heo复制不会触发100%的DTU节流阀，当我们将其提高到微软的支持时，他还说这是个好主意。支持人员还说，sql复制对于事务性复制来说效率要高得多。

然而，当我们问他内部使用哪种技术，为什么要比旧的事务性复制更好时，他只是给出了一些营销回复：

geo复制利用Server的始终On技术，使用快照隔离将主数据库上提交的事务异步复制到辅助数据库。对主数据库的影响是最小的，因为这个过程与自动备份运行的上下文相同，例如.

。

就我个人而言，我并没有真正理解为什么geo复制比旧的复制更好。有人知道一些技术细节吗？

Answer 1

正如支持所告诉的那样，Azure SQL数据库的geo复制使用了“始终在可用性组上”的特殊风格来复制数据。“特殊风格”在您的问题中并不重要，所以我将以“复制与可用性组”的方式来回答，因为它也适用于您的情况。

复制

Server事务复制是在数据库之间复制特定数据的一种方法。默认情况下，它将在已发布的订阅服务器和订阅服务器之间复制数据。分发服务器具有一个日志读取器代理，用于读取发布服务器的事务日志，并将其转换为单独的update语句，这些语句通过分发代理发送给订阅服务器。

在发布服务器上更新1,000行的单个update语句将在订阅服务器上生成1,000个单独的update语句，根据PK进行逐行更新。

有其他选择，但在大多数情况下，这是人们使用的配置，因为这是默认行为。(例如，您可以将存储过程执行配置为复制，以便订阅服务器不再复制逐行数据更新，而是再次执行存储过程.你可能不会那样做。)

可以想象，订阅服务器上的逐行更新可能效率低下。订阅服务器上的每个单独更新都将是快速的，因为它是基于主键的单行更新--但是逐行与基于集的操作并不总是理想的。

可用性组

可用性组(AGs)以不同的方式处理事情。使用AGs，整个数据库将被复制，而不仅仅是特定的数据。复制方法包括写入辅助服务器上的事务日志，然后在辅助服务器上重新执行事务。这两个步骤通常称为“发送”和“重做”阶段。

它的工作方式的一个简化版本:主服务器上用于" send“的开销本质上仅仅是它必须在本地写入事务日志，并将相同的确切信息发送给备用服务器，以获取它的事务日志副本。辅助服务器上用于“重做”的开销实质上只是处理该事务的方式，就像在主服务器上处理事务一样。