Compartir a través de

Azure SQL 数据库中的维护时段

  • Artículo

适用于：Azure SQL 数据库

使用维护时段功能，可以为 Azure SQL 数据库和 Azure SQL 托管实例资源配置维护计划，从而使重大维护事件可预测，并减少工作负载的中断次数。

注意

维护时段功能仅保护免受升级或计划性维护产生的计划影响。 它不能保护免受所有故障转移原因影响；可能在维护时段之外导致短暂连接中断的异常包括硬件故障、群集负载均衡和数据库重新配置，这些异常是由于数据库服务级别目标变化等事件引起的。

提前通知可用于配置为使用非默认维护时段的数据库。 使用提前通知，客户可以将通知配置为最多在发生任何计划事件前的 24 小时内发送。

概述

Azure 会定期执行 SQL 数据库资源的计划内维护。 在维护事件期间，数据库完全可用，但可能在 SQL 数据库的可用性服务级别协议 (SLA) 中发生短暂的重新配置。

维护时段专用于不能复原到数据库重新配置的生产工作负载，并且无法缓解由计划内维护事件引起的短暂连接中断。 通过选择你喜欢的维护时段，将维护安排在你的高峰营业时间之外发生，可最大程度地减少‭‬计划内维护‬的影响。 可复原的工作负载和非生产工作负载可能依赖于 Azure SQL 的默认维护策略。

维护时段是免费的，可在创建时或针对现有资源进行配置。 可以使用 Azure 门户、PowerShell、CLI 或 Azure API 对其进行配置。

重要

配置维护时段是一种长期运行的异步操作，类似于更改 Azure SQL 资源的服务层级。 该资源在操作过程中可用，只在操作结束时会发生短暂的重新配置，即使在长期运行的事务中断的情况下，通常最多也仅持续 8 秒。 若要将重新配置的影响降至最低，应在高峰时段之外执行操作。

通过维护时段提高可预测性

默认情况下，Azure SQL 维护策略会在当地时间每天早上 8 点到下午 5 点段期间阻止影响最大的更新，以避免在正常高峰营业时间内发生任何中断。 当地时间由承载资源的 Azure 区域的位置确定，并根据当地时区定义遵守夏令时。

在维护期间，数据库仍可用，但某些更新可能需要故障转移。 系统默认维护时段（下午 5 点到上午 8 点）将大多数活动限制到该时段，但紧急更新可能会超出该时段。 若要确保所有更新仅在维护时段内发生，请选择非默认选项。

通过从两个非默认的维护时段槽中进行选择，可以将维护更新时段调整为适用于 Azure SQL 资源的时间：

  • 工作日时段：本地时间晚上 10 点到早上 6 点，星期一到星期四
  • 周末时段：本地时间晚上 10 点到早上 6 点，星期五到星期日

列出的维护时段所在日子表示每个 8 小时维护时段的开始日期。 例如，“本地时间晚上 10 点到早上 6 点，星期一到星期四”表示维护时段从本地时间（星期一到星期四的）每天晚上 10:00 开始，并在本地时间（星期一到星期四的）早上 6:00 结束。

选择维护时段并完成服务配置后，计划内维护仅在所选的时段中进行。 维护事件通常是在单个时段内完成，但其中某些事件可能会跨越两个或更多相邻时段。

注意

Azure SQL 数据库遵循安全部署做法，保证不会同时部署到 Azure 配对区域。 但是，无法预测将首先升级哪个区域，因此无法保证部署顺序。 有时将首先升级主数据库，有时将首先升级辅助数据库。

  • 如果已为异地复制或故障转移组启用数据库，并且异地复制与 Azure 区域配对不一致，则应为主数据库和辅助数据库选择不同的维护时段计划。 例如，可以为异地辅助数据库选择“工作日”维护时段，为异地主数据库选择“周末”维护时段。

重要

在极少数情况下，任何延迟操作都可能会导致严重影响（例如应用关键安全修补程序），可能会暂时覆盖已配置的维护时段。

提前通知

可以将维护通知配置为提醒你即将发生的 Azure SQL 数据库的计划维护事件。 警报会在维护时段打开前 24 小时以及维护时段结束时到达。 有关详细信息，请参阅提前通知。

功能可用性

支持的订阅类型

配置和使用维护时段适用于以下套餐类型：即用即付、云解决方案提供商 (CSP)、Microsoft 企业协议或 Microsoft 客户协议。

仅限开发/测试使用的套餐不符合条件（例如即用即付开发/测试或企业开发/测试）。

备注

Azure 套餐是用户拥有的 Azure 订阅类型。 例如，具有即用即付率的订阅、Azure 开放许可和 Visual Studio Enterprise 都是 Azure 套餐。 每个套餐和计划都有不同的条款和权益。 你的套餐或计划显示在订阅的“概述”上。 有关将订阅切换到其他套餐的详细信息，请参阅将 Azure 订阅更改为其他套餐。

受支持的服务级别目标

除以下情况外，所有的 SLO 上都可以选择默认维护时段之外的维护时段。

  • 不支持 SLO：
    • Azure SQL 数据库 DTU 基本层、S0 层和 S1 层
    • DC 硬件
    • Fsv2 硬件

其他方案：

Azure SQL 数据库区域对维护时段的支持

目前在以下区域可以为 Azure SQL 数据库选择默认维护时段以外的维护时段，由购买模型进行管理。

Azure 区域
中国东部 2 是
中国北部 2 是

网关维护

若要从维护时段获得最大优势，请确保客户端应用程序使用的是重定向连接策略。 重定向是推荐的连接策略，其中客户端直接与托管数据库的节点建立连接，从而降低延迟并改进吞吐量。

在 Azure SQL 数据库中，使用代理连接策略的任何连接都可能会受到所选维护时段和网关节点维护时段的影响。 但是，使用推荐的重定向连接策略的客户端连接不受网关节点维护重新配置的影响。

有关 Azure SQL 数据库中客户端连接策略的详细信息，请参阅 Azure SQL 数据库连接策略。

检索维护事件列表

Azure Resource Graph 是可以扩展 Azure 资源管理的 Azure 服务。 Azure Resource Graph Explorer 可提供高效且高性能的资源浏览功能，它能够在一组给定的订阅中进行大规模查询，使你能够有效地管理环境。

你可以使用 Azure Resource Graph Explorer 查询维护事件。 有关如何运行这些查询的介绍，请参见快速入门：使用 Azure Resource Graph Explorer 运行第一个资源图查询。

若要检查订阅中所有 SQL 数据库的维护事件，请在 Azure Resource Graph 资源浏览器中使用以下示例查询：

servicehealthresources
| where type =~ 'Microsoft.ResourceHealth/events'
| extend impact = properties.Impact
| extend impactedService = parse_json(impact[0]).ImpactedService
| where  impactedService =~ 'SQL Database'
| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = todatetime(tolong(properties.ImpactStartTime)), impactMitigationTime = todatetime(tolong(properties.ImpactMitigationTime))
| where eventType == 'PlannedMaintenance'
| order by impactStartTime desc

有关示例查询的完整参考以及如何跨 PowerShell 或 Azure CLI 等工具使用这些查询，请访问适用于 Azure 服务运行状况的 Azure Resource Graph 查询示例。

相关内容