Compartir a través de

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

  • Artículo

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

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

重要

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

维护周期

例行维护

我们的标准维护周期不会低于每 30 天一次。 此时间段使我们能够确保系统稳定性和性能，同时最大程度地减少服务中断。

关键维护

在某些情况下（例如，需要部署紧急安全修补程序或更新来维护可用性和数据完整性至关重要时），可能会更频繁地进行维护。 这些例外情况用于保护数据并确保服务持续运行。

查找维护详细信息

有关每个维护更新需要的具体详细信息，请参阅我们的发行说明。 这些说明提供有关维护期间应用的更新的综合信息，使你能够了解和准备应对任何会影响环境的更改。

注意

并非所有服务器都必须在计划更新期间进行维护，无论是例程维护还是“关键”维护。 Azure MySQL 团队采用特定条件来确定哪些服务器需要维护。 这种选择性方法可确保维护既高效又重要，根据每个服务器环境的独特需求量身定做，并最大程度地减少生产停机时间。

选择维护时段

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

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

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

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

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

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

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

重要

从 2024 年 8 月 31 日起，Azure Database for MySQL 将不再支持可突发 SKU 实例的自定义维护时段。 这一变化是为了简化维护流程，确保最佳性能，并且我们的分析表明，在可突发 SKU 上使用自定义维护时段的用户数量最少。 具有自定义维护时段配置的现有可突发 SKU 实例将不受影响；但是，用户将无法修改这些自定义维护时段设置。

对于需要自定义维护时段的客户，建议升级到“常规用途”或“业务关键”SKU，以继续使用此功能。

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

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

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

精确的停机时间预期

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

限制和先决条件

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

  • 所有表中的主键：确保每个表中都有主键至关重要。 缺少主键可能会显著增加复制延迟，从而影响停机时间。
  • 维护期间的低工作负载：维护周期应与服务器上的低工作负载时间一致，以确保停机时间保持最短。 我们鼓励使用自定义维护时段功能在非高峰时段计划维护。
  • 停机时间保证：虽然我们努力在最大程度上减少维护停机时间，但我们不能保证在所有情况下始终少于 60 秒。 各种因素（例如高工作负载或特定的服务器配置）都可能会导致更长的停机时间。 在最坏的情况下，停机时间可能与独立服务器的情况类似。

维护重新计划

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

重新计划参数和通知

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

注意事项和限制

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

  • 需求约束：由于同一区域中同时发生大量维护活动，重新计划的维护可能会被取消。
  • 锁定期：在最初计划的维护时间前 15 分钟无法重新计划，以保持服务的可靠性。
  • 重新计划限制 如果同一时间内计划维护同一区域中的过多服务器，则重新计划请求可能会失败。 如果发生这种情况，用户将收到错误通知，并建议选择其他时间段。 成功重新计划的维护不太可能被取消。

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

注意

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

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

常见问题解答

问：为什么我的一些服务器收到维护通知，而另一些服务器没有收到维护通知？

答：维护开始时间因区域而异，因此不同区域中的服务器可能会在不同时间收到维护通知。

问：为什么同一区域中一些服务器收到维护通知，而另一些服务器没有收到维护通知？

答：这可能是因为没有收到通知的服务器是最近才创建的，系统认为它们还不需要维护。

问：是否可以选择退出计划性维护？

答：否，不允许选择退出计划性维护。 不过，可以使用维护重新计划功能来调整时间或启用高可用性 (HA) 功能，以尽量减少停机时间。 对于 PaaS 数据库产品，必须及时进行维护，以确保数据库的安全性和可靠性。

后续步骤