Azure 弹性数据库池缩放持续时间查询答案

【问题标题】：Azure elastic database pool scaling duration queryAzure 弹性数据库池缩放持续时间查询
【发布时间】：2018-06-30 07:45:37
【问题描述】：

我们目前在 Azure 中有一个弹性数据库池，我们希望根据高 eDTU 使用率进行扩展。池中有 30 多个数据库，它们目前使用 100GB 的存储空间（尽管这可能会增加）。

当我们检测到高 eDTU 使用率时，我们计划增加分配给池的 eDTU。然而，网上的一些帖子让我质疑这将如何运作。以下引用摘自 azure 文档 - https://docs.microsoft.com/en-us/azure/sql-database/sql-database-resource-limits

重新调整池 eDTU 的持续时间可能取决于池中所有数据库使用的存储空间总量。通常，每 100 GB 的重新缩放延迟平均为 90 分钟或更短。

如果我理解正确，这意味着如果我们想增加 eDTU，我们将不得不平均每 100GB 等待 90 分钟。如果是这种情况，动态扩展将不适合我们，因为等待性能提升的 90 分钟太长了。

谁能确认我上面所说的是否正确？是否有任何替代建议可以动态增加 eDTU 而无需等待如此长的时间？

这也意味着，如果我们想根据时间表进行扩展，即在上午 8 点扩展 eDTU，我们实际上必须在上午 6:30 开始扩展，以允许估计的 90 分钟扩展时间 - 如果我对此的理解是正确的。

【问题讨论】：

让我确认每 100 GB 90 分钟的比率仍然很普遍。不确定我今天能否为您解答。
我期待今天的答复。感谢您的耐心等待。
扩容过程中，数据库离线？是否可以实现零停机扩展？

标签： azure azure-sql-database

【解决方案1】：

当您扩展池 eDTU 时，Azure 可能必须迁移数据（这是一个共享数据库服务）。如果需要，这将需要时间。我已经看到缩放是即时的，并且我已经看到它需要很多时间。我认为微软的目的是通过弹性池来节省成本，而不是通过快速更改 eDTU 的能力。

【讨论】：

补充约翰所说的。当您扩展服务层时，Azure 将尝试将您的数据保存在同一台计算机上，并为您的数据库分配更多资源。有时，它无法在同一台机器上分配更多资源，因此它必须将您的数据库复制到另一台机器上。如果您有一个大型数据库（大量 IO），则复制操作可能会很昂贵。

【解决方案2】：

以下是 Microsoft Azure SQL 数据库管理员提供的答案：

为了在同一层重新调整基本/标准池，一些服务已经进行了优化，因此现在重新调整延迟是通常与池中的数据库数量成正比，并且与它们的存储大小无关。通常，延迟约为每个数据库 30 秒，最多可并行提供 8 个数据库池利用率不太高且运行时间不长交易。例如，具有 500 个数据库的标准池无论大小如何，通常都可以在 30 多分钟内重新调整大小（即 ~ 500 个数据库 * 30 秒 / 8 个并行数据库）。

在高级池的情况下，重新缩放延迟仍然是与数据大小成正比。

这位 Azure SQL 数据库经理承诺在完成更多改进后立即更新 Azure 文档。

感谢您耐心等待这个答案。

【讨论】：

感谢您帮我解决这个问题。不幸的是，我们使用了高级池，所以我认为这样做的结果是我们将无法根据需求进行扩展，而必须根据时间表进行扩展。