Azure Database for MySQL 执行定期维护，以帮助确保托管数据库的安全、稳定和最新。 在维护期间，服务器会获取新的功能、更新和补丁。
重要
避免在 Azure Database for MySQL 维护期间进行任何服务器操作，如修改、配置更改、启动/停止。 参与这些活动可能会导致可能影响服务器性能和稳定性的不可预知的结果。 请等待维护结束，然后再执行服务器操作。
维护周期
以下部分介绍维护类型。 有关每个维护更新需要的具体详细信息，请参阅发行说明。 这些说明提供有关维护期间应用的更新的综合信息，以便你可以了解并准备影响环境的任何更改。
注意
并非所有服务器在计划更新期间都必然进行维护，无论是常规还是关键更新。 Azure MySQL 团队采用特定条件来确定哪些服务器需要维护。 这种选择性方法可确保维护既高效又重要，根据每个服务器环境的独特需求量身定做，并最大程度地减少生产停机时间。
例行维护
我们的标准维护周期不低于每 30 天一次。 此时间段有助于确保系统稳定性和性能，同时最大程度地减少服务中断。
紧急维护
在某些情况下（例如，需要部署对维护可用性和数据完整性至关重要的紧急安全修补程序或更新），我们可能会更频繁地进行维护。 这些例外有助于保护您的数据并确保服务的持续运行。
Virtual Canary 维护
Virtual Canary 是一个试验性的维护计划，可让用户提前访问更新。 它使客户能够测试与新的 Azure Database for MySQL 版本的工作负载兼容性，并提供有关新功能的反馈。
与常规维护不同，虚拟金丝雀不需要遵循 30 天的最小间隔或 7 天的通知期。 该计划可帮助客户主动验证新功能，并为产品改进提供早期反馈。 可突发层服务器（通常用于非生产环境）会自动在 Virtual Canary 计划中注册。
Virtual Canary 注册
Azure Database for MySQL 可让客户灵活地管理他们对 Virtual Canary 计划的参与。 客户可以根据需要选择加入或退出该计划，以符合其运营要求。
若要验证服务器是否已在 Virtual Canary 程序中注册，请使用以下命令。 如果结果包括 "patchStrategy": "VirtualCanary"，则服务器已加入该计划。
az mysql flexible-server show --resource-group {resourcegroupname} --name {servername} --query "maintenancePolicy"
若要在 Virtual Canary 计划中注册服务器，请运行以下命令：
az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy VirtualCanary
若要退出虚拟 Canary 程序并恢复到标准维护策略，请使用以下命令：
az mysql flexible-server update --resource-group {resourcegroupname} --name {servername} --maintenance-policy-patch-strategy Regular
维护时段
可以计划在一周中特定某天以及该天某个时段范围内进行维护。 或者，你可以让系统自动选择某一天和某个时段。 无论哪种方式，系统都会在运行任何维护前 7 天发出警报。 系统还会告诉你维护何时启动，以及何时成功完成。
有关即将开始的计划性维护的通知可能会：
- 通过电子邮件发送到特定地址。
- 通过电子邮件发送到 Azure 资源管理器角色。
- 通过短信发送到移动设备。
- 将通知推送至 Azure 应用。
- 以语音消息方式传送。
指定维护计划的首选项时，可以选择一周中的一天和一个时间范围。 如果未指定首选项，系统会在服务器的区域时间中选取下午 11 点到 7 点之间的时间。 你可以为 Azure 订阅中的每个灵活服务器定义不同的计划。
你可以随时更新计划设置。 如果为灵活服务器安排维护并更新时间安排首选项，当前正在进行的执行将按计划进行。 计划设置的更改将在下一次计划维护成功完成后生效。
可以为 Azure 订阅中的每个灵活服务器定义系统托管计划或自定义计划：
- 使用自定义计划，可以选择一周中的一天和一小时的时间窗口，为服务器指定维护时段。
- 使用由系统管理的日程安排，系统会在服务器所在区域时间晚上11点到早上7点之间随机选择一个小时的时间段。
重要
截至 2024 年 8 月 31 日，Azure Database for MySQL 将不再支持针对突发型实例的自定义维护时间窗口。 此更改有助于简化维护过程并确保最佳性能。 此外，我们的分析表明，在可突发层上使用自定义维护时段的用户数量最少。
具有自定义维护时段的现有可突发层实例不受影响。 但是，用户无法再修改自定义维护时段的这些设置。
对于需要自定义维护时段的客户，建议升级到“常规用途”或“业务关键”层。
在极少数情况下，系统可能会取消维护事件，或者可能无法成功完成维护事件。 如果维护操作失败，则会回退更新，并恢复先前版本的二进制文件。 在更新失败的情况下，在维护时段内仍可能会遇到服务器重启的情况。
如果维护事件已取消或失败，系统会向你发送通知。 下一次维护的安排将根据您当前的设置进行。 你会在五天前收到关于下次尝试的通知。
维护状态
对于单个服务器，可以在 Azure 门户中的 Azure MySQL 维护边栏选项卡中查看维护状态。 维护状态指示是计划维护、正在进行、已完成还是已取消。
对于管理多个 Azure Database for MySQL 灵活服务器的客户，可以使用 Azure Resource Graph 跨订阅和资源组执行批量查询。 对于审核维护历史记录、识别受影响的资源以及跟踪一段时间内的维护事件，这特别有用。 下面是 Kusto 查询，用于检索客户订阅下所有 MySQL 灵活服务器的维护状态、开始和结束时间以及跟踪 ID。 这样，客户就可以可缩放和自动化的方式监视过去三个月的维护活动：
ServiceHealthResources
| where type == "microsoft.resourcehealth/events/impactedresources"
| extend TrackingId = split(split(id, "/events/", 1)[0], "/impactedResources", 0)[0]
| extend p = parse_json(properties)
| project subscriptionId, TrackingId, resourceName= p.resourceName, resourceGroup=p.resourceGroup, resourceType=p.targetResourceType, status= p.status, maintenanceStartTime=todatetime(p.maintenanceStartTime), maintenanceEndTime=todatetime( p.maintenanceEndTime), details = p, id
| where resourceType == "Microsoft.DBforMySQL/flexibleServers"
| order by maintenanceEndTime
还可以转到 Azure 服务运行状况的“受影响的资源”选项卡，查看所有 Azure 资源的维护状态，包括 Azure Database for MySQL 灵活服务器。 请注意，Azure 服务运行状况中显示的维护状态表示区域级别的维护事件的总体状态，可能不会反映各个服务器的状态。
近零停机维护
Azure Database for MySQL 近零停机维护 功能是高可用性服务器的开创性开发。 此功能旨在大幅减少维护停机时间。 此功能对于要求高可用性和数据库操作中断最少的企业至关重要。
条件和限制
若要实现此功能提供的最佳性能，请注意以下条件和限制：
- 停机时间：在大多数情况下，维护期间的停机时间范围为 10 到 30 秒。
- 所有表中的主键：确保每个表都有主键至关重要。 缺少主键可能会显著增加复制延迟并影响停机时间。
- 维护期间工作负荷较低：维护期应与服务器上的低工作负荷时间一致，以最大程度地减少停机时间。 建议使用 自定义维护时段 在非高峰时段计划维护。
- 停机时间保证：尽管我们努力使维护停机时间尽可能低，但我们不能保证在所有情况下的维护停机时间都小于 60 秒。 各种因素（如高工作负荷或特定服务器配置）可能会增加停机时间。 在最坏的情况下，停机时间可能与独立服务器的情况类似。
维护重新安排
使用 维护重新安排 功能可以更好地控制 Azure Database for MySQL 灵活服务器上的维护活动的时间。 收到维护通知后，可以将其重新安排到更方便的时间，系统托管和自定义托管均可。
使用此功能可避免在关键数据库操作期间发生中断。 在我们继续开发此功能的过程中，我们鼓励你提供反馈。
重新安排参数和通知
重新安排不限于固定时间段。 这取决于当前维护周期中最早和最新的允许时间。 周期通常从第一天到该区域维护时段的最后一天。 重新计划时，会根据标准通知策略收到一条通知来确认更改。
注意事项和限制
请注意以下有关该功能的要点：
- 层层级用性：维护重新安排不适用于可突发计算层。 此功能适用于生产环境中的服务器，而可突发层旨在用于非生产目的。
- 需求约束：如果在同一区域中同时发生大量维护活动，则重新安排的维护可能会被取消。
- 锁定期：在最初安排的维护时间前的 15 分钟无法使用重新安排，以保持服务的可靠性。
- 重新安排节流：如果在同一区域中安排在同一时间维护的服务器过多，则重新安排请求可能会失败。 如果发生此故障，将收到一条错误通知，建议选择备用时间段。 成功重新计划的维护不太可能被取消。
重新安排维护事件次数没有限制。 只要维护事件未进入 “正在准备 ”状态，就可以始终将其重新安排到另一次。
注意
建议在预览阶段密切监视通知，以适应潜在的调整。
FAQ
为什么我的一些服务器收到维护通知，而另一些服务器没有收到维护通知？
维护开始时间因区域而异。 不同区域中的服务器可能会在不同时间收到维护通知。
为什么同一区域中的某些服务器收到维护通知，而另一些服务器则没有收到维护通知？
最近可能会创建未收到通知的服务器，并且系统确定它们尚不需要维护。
是否可以选择退出计划内维护？
否，不允许选择退出计划内维护。 但是，可以使用维护重新安排功能来调整时间。 或者，可以启用高可用性功能，以最大程度地减少停机时间。 由于 Azure Database for MySQL 是一种平台即服务（PaaS）数据库产品，因此执行及时维护有助于确保数据库的安全性和可靠性。