Azure Database for MySQL 灵活服务器中的计划性维护

  • 项目

适用于：Azure Database for MySQL - 灵活服务器

Azure Database for MySQL 灵活服务器会执行定期维护，以确保托管数据库安全、稳定并处于最新状态。 在维护期间，服务器会获取新的功能、更新和补丁。

重要

请避免在 Azure Database for MySQL 灵活服务器维护期间执行所有服务器操作（修改、配置更改、启动/停止服务器）。 参与这些活动可能会导致不可预知的结果，可能会影响服务器性能和稳定性。 等待维护结束后再执行服务器操作。

选择维护时段

可以计划在一周中特定某天以及该天某个时段范围内进行维护。 或者，你可以让系统自动选择某一天和某个时段。 无论采用哪种方式，系统都会在运行任何维护前 7 天提醒你。 系统还会在维护开始时以及在维护成功完成时告知你。

有关即将开始的计划性维护的通知可能会：

  • 通过电子邮件发送到特定地址
  • 通过电子邮件发送到 Azure 资源管理器角色
  • 以短信 (SMS) 形式发送到移动设备
  • 作为通知推送到 Azure 应用
  • 作为语音消息传递

为维护计划指定首选项时，可以选择一周中的某一天，然后选择一个时间范围。 如果未指定，系统将选择服务器区域时间中的晚上 11 点到早上 7 点之间的时间。 你可以为 Azure 订阅中的每个灵活服务器定义不同的计划。

重要

通常，服务器的成功计划性维护事件间隔至少为 30 天。

但是，如果发生关键紧急更新（例如严重漏洞），通知时间范围可能短于 7 天。 即使在过去 30 天内成功地执行了计划性维护，关键更新也可能会应用于服务器。

你可以随时更新计划设置。 如果你为灵活服务器计划了维护，并且更新了计划首选项，则当前推出的维护将按计划继续进行，并在其成功完成后为下次计划性维护应用计划设置更改。

可以为 Azure 订阅中的每个灵活服务器定义系统管理的计划或自定义计划。

  • 使用自定义计划时，可以通过选择星期几和一小时时间范围来为服务器指定维护时段。
  • 使用系统管理的计划时，系统会在服务器的区域时间中选择介于晚上 11 点与上午 7 点之间的任意一小时的时间。

重要

以前，系统托管和自定义托管计划之间的部署间隔为 7 天。 由于不断变化的维护需求和维护重新计划功能（公共预览版）的引入，我们无法再保证这 7 天的间隔。

在极少数情况下，维护事件可能会被系统取消，或者可能无法成功完成。 如果更新失败，则会还原更新，并还原以前版本的二进制文件。 在这种失败的更新情况中，你可能仍会在维护时段内遇到服务器重启。 如果更新已取消或失败，系统会创建有关已取消或失败维护事件的通知，并发送相应的通知。 会根据当前计划设置安排下次维护，并且你会提前 5 天收到相关通知。

近零停机维护（公共预览版）

Azure Database for MySQL 灵活服务器的“近零停机维护”功能是针对支持 HA（高可用性）的服务器的突破性开发。 此功能旨在大幅减少维护停机时间，确保在大多数情况下，维护停机时间预计在 40 到 60 秒之间。 此功能对于要求高可用性和数据库操作中断最少的企业至关重要。

精确的停机时间预期

  • 停机时间：在大多数情况下，维护期间的停机时间范围为 10 到 30 秒。
  • 其他注意事项：发生故障转移事件后，会有大约 30 秒的 DNS 生存时间 (TTL)。 该时间段不直接由维护过程控制，而是 DNS 行为的标准部分。 因此，从客户的角度来看，维护期间的总停机时间可能在 40 到 60 秒之间。

限制和先决条件

若要实现此功能承诺的最佳性能，应注意某些条件和限制：

  • 所有表中的主键：确保每个表中都有主键至关重要。 缺少主键可能会显著增加复制延迟，从而影响停机时间。
  • 维护期间的低工作负载：维护周期应与服务器上的低工作负载时间一致，以确保停机时间保持最短。 我们鼓励使用自定义维护时段功能在非高峰时段计划维护。

维护重新计划（公共预览版）

重要

维护重新计划功能目前为预览版。 它受制于限制和持续开发。 我们重视你的反馈，以帮助增强此功能。 请注意，此功能不适用于使用可突发 SKU 的服务器。

通过维护重新计划功能，可以更好地控制 Azure Database for MySQL 灵活服务器实例上维护活动的计时。 收到维护通知后，可以将其重新安排到更方便的时间，无论它是系统托管还是自定义托管。

重新计划参数和通知

重新计划并不局限于固定的时间段；这取决于当前维护周期中允许的最早和最新时间。 重新计划后，将按照标准通知策略发送通知以确认更改。

注意事项和限制

使用此功能时，请注意以下事项：

  • 需求约束：由于同一区域中同时发生大量维护活动，重新计划的维护可能会被取消。
  • 锁定期：在最初计划的维护时间前 15 分钟无法重新计划，以保持服务的可靠性。

只要维护未进入“准备”状态，重新计划维护的次数即无限制，始终可以将维护重新安排到其他时间。

注意

我们建议在预览阶段密切监视通知，以适应潜在的调整。

使用此功能可避免在关键数据库操作期间发生中断。 在我们继续开发此功能的过程中，我们鼓励你提供反馈。

后续步骤