如何强制 Azure SQL(无服务器)暂停?

How do you force Azure SQL (Serverless) to pause?

提问人:MYK 提问时间:11/5/2021 最后编辑:MYK 更新时间:3/4/2023 访问量:1519

问:

我们将 Azure SQL 数据库(无服务器)作为 PoC 的一部分运行。 我们现在正在测试其他一些解决方案,因此我们想强制暂停数据库几天。即。我们只想产生几天的存储计费。

数据库显示的使用量较低,使数据库表单自动暂停(导致与数据库的存储使用量关联的最小 vCore 保持一致)

如何强制 serverless db 暂停?

azure-sql-database

评论

0赞 Alexander Derck 2/11/2022
我也在研究一些逻辑来处理这种自动暂停,这真的很烦人,你必须等待至少 1 小时,直到它暂停进行测试
1赞 MYK 2/11/2022
顺便说一句,我没有弄清楚,我删除了数据库并切换到 Azure 超大规模,我们在不重负载时将其缩减到 2 个 vCore
0赞 Alexander Derck 2/12/2022
在创建连接时,我使用 Polly 的重试机制让它工作。

答:

-1赞 Sarang Kulkarni 11/8/2021 #1

您可以备份数据库以供以后恢复并删除数据库,否则可以切换到具有 5 个 DTU 的基本层

评论

1赞 Alexander Derck 2/11/2022
暂停与不可用不同。暂停后,它将在建立连接时恢复。但是,在代码中,这会导致超时,直到数据库再次启动并运行。OP 可能试图测试的是处理此暂停恢复的一些逻辑,而不是处理不存在的数据库的逻辑。
0赞 Zak 6/15/2022
@AlexanderDerck 这就是我来这里的原因。仍然没有答案
2赞 StuartLC 9/29/2022 #2

无法显式/以编程方式强制 Azure SQL Serverless 暂停 - 只有在未检测到配置的“自动暂停延迟”设置(至少 1 小时)的连接或 CPU 活动后,数据库才会暂停。任何连接(例如来自应用的连接池)或其他无意的后台活动都将重置暂停计时器(并产生成本)。(几乎)保证暂停的唯一方法是停止使用数据库的所有应用程序并终止所有连接,然后等待(至少)一个小时。

您可以考虑的替代方法是在不活动期间自动更改层(而不是依赖暂停来触发),尤其是在测试环境中。

例如,如果您预计周末不会有大量的数据库负载,则可以在周五晚上安排作业:

  ALTER DATABASE [MY_TEST_DB] 
  MODIFY(EDITION='Standard', SERVICE_OBJECTIVE='S0');

S0 会将数据库降低到 10 DTU 级别,在撰写本文时每月约 20 美元。如果您的数据库大小低于 2GB,那么您甚至可以降至“基本”级别。

根据数据库的当前大小,最低层定价可能不可用 - 图表 此处

数据库可以在星期一早上返回到 Serverless:

 ALTER DATABASE [MY_TEST_DB] 
 MODIFY(EDITION='GeneralPurpose' , SERVICE_OBJECTIVE='GP_S_Gen5_1');

其中,上述内容将数据库更改为无服务器 vCore Gen 5,最多 1 个 vCore。在缩减无服务器 SKU 之前,建议运行:

  SELECT DATABASEPROPERTYEX('MY_TEST_DB', 'ServiceObjective');

并记下原始的 Serverless 目标设置,以便您可以返回到该值。

笔记:

  • 当位于基于 DTU 的廉价层上时,数据库将始终可用(从不暂停),但将以较低的费率计费,因为功能将大大降低。
  • 您至少需要 ,也许还需要其他 AD 资源权限才能执行db_ownerALTER DATABASE .. MODIFY
  • 数据库层可能需要几分钟时间才能在各层之间切换
  • 似乎版本未经过验证,因此如果您输入错误版本,则不会出现错误。有效值显示为 、 和 。BasicStandardGeneralPurpose
  • 可以在 Azure 门户上确认层更改You can confirm the tier change on the Azure portal
0赞 FFFffff 3/4/2023 #3

自动执行 Azure SQL 数据库层更改的另一个选项是使用 Azure 逻辑应用。

您可以设置任何计划并执行 SQL 命令来更改层,例如每天早上切换到 100 个 DTU,每天晚上切换回 10 个 DTU。

这很容易做到,与自动暂停相比,它可以让您完全控制。较低层几乎是免费的,因此它同样可以达到目的。

IMO:从长远来看,它比对随机唤醒事件进行故障排除更容易维护。