调整Azure地理复制数据库的大小

Question

如果我有一个S2 Sql数据库，并且我创建了一个辅助地理复制数据库，它是否应该具有相同的大小（S2）？我看到你收到了辅助DB的费用，但DTU报告的次要数据是0％，这似乎表明S2太大了。

显然，我们希望尽可能节省成本，并尽可能将次要尺寸移到更小的尺寸。

考虑

我知道如果我们需要故障转移到辅助服务器，那么它需要提升到S2的大小以满足生产工作负载，但假设我们可以在故障转移时执行此操作吗？ / p>

如果我们积极使用复制的数据库进行报告等，我也会得到它，那么我们必须相应地调整它以满足该需求。但是目前，如果需要，我们不会主动使用辅助节点作为故障转移点。

Answer 1

您可以安全地更改辅助数据库的层，但请记住，在故障转移的情况下，您将面临性能问题。此外，您无法超过当前的绩效等级（因此两个基数应该是同一层）。

是的，您可以在故障转移后更改大小，但该过程是手动的。

Answer 2

此时，主要版本和次要版本必须属于同一版本，但可以具有不同的性能目标（DTU大小）。我们正在努力解除这一限制，以便地理复制数据库可以在需要时扩展到不同的版本，而不会破坏复制链接（例如标准到高级版）。

重新调整中学，你可以＆＃34;如果您认为更新占用的容量小于读取（高读/写比率），则DTU中的DTU比主要小。但如前所述，您必须在故障转移后立即升级它，并且可能需要一段时间才能影响应用程序的性能。一般情况下，我们不建议将次要级别设置为小于1级。例如。 S3-＆gt; S1不是一个好主意，因为它可能会导致复制滞后，并可能导致故障转移后过多的数据丢失。