对于 HeatWave Service 的用户来说，维护流程有时感觉像个黑匣子。它包含哪些内容？它与版本升级有何不同？更新何时以及如何应用？面对这些疑问，是时候深入剖析 HeatWave 维护的机制，并阐明其目的、范围和灵活性了。无论您是管理生产数据库还是规划部署，本指南都能帮助您自信地完成整个流程。
HeatWave 服务中的维护目的
HeatWave MySQL 服务维护的核心在于确保数据库系统的持续安全性、性能和稳定性。它是一项全面、主动的举措，涵盖了基础架构的多个层面：
- 数据库安全性和关键修复： 维护团队会应用补丁程序来修复 MySQL 同一主版本（例如 8.3、8.4 等）和次版本（例如 8.3.x、8.4.x 等）中的漏洞和关键错误。例如，如果您使用的是 8.0.38-u1 版本，维护团队可能会将其更新至 8.0.38-u2，以反映增量“-u”更新（例如，错误修复或安全补丁）。
- 操作系统修补： 作为 OCI 的一部分，底层操作系统会接收更新以维护其安全性和可靠性，从而确保部署基础的安全性和合规性。
- 固件和虚拟机管理程序更新： 硬件固件和虚拟机管理程序已更新，以优化性能并确保与更广泛的 OCI 系统兼容。
默认情况下，此过程不会 更改 数据库的主版本或次版本——这意味着，除非满足特定条件（稍后会详细介绍），否则从 8.0.38 升级到 8.0.39 不属于例行维护。相反，它专注于保持当前版本处于最佳状态。
注意：Oracle 会定期发布与安全相关的补丁更新和安全警报。请尽快安装所有安全补丁。 有关详细信息， 请参阅重要补丁更新和安全警报。
维护与自动小版本升级：有什么区别？
一个常见的混淆点是维护与自动小版本升级有何不同。让我们来澄清一下：
- 维护： 这是每月一次的操作，重点关注当前版本的稳定性和安全性。它会应用上述更新，包括安全修复、操作系统补丁和固件刷新，而不会更改主版本或次版本号（例如，8.0.38 仍为 8.0.38，但“-u”后缀可能会递增）。
- 自动次要版本升级： 仅当您当前的数据库版本不可用（即 Oracle 逐步停止支持该版本）时，才会进行此升级。例如，如果 8.0.39 版本（错误修复）已到达其不可用日期（2025 年 10 月），HeatWave 将在后续维护周期内自动将您的数据库升级到下一个可用版本（例如 8.0.40 错误修复）。请参阅HeatWave MySQL 服务器版本 文档。
两者的区别至关重要：维护是为了维护，而自动小版本升级则是由版本生命周期变化（例如版本弃用或不可用）触发的强制升级。例行维护不会仅仅因为某个新小版本可用就强制您升级，而是等待必要性出现时再进行。
注意：仍在使用旧版本的客户将持续收到有关即将推出的版本不可用的通知。您可以使用控制台或 CLI 手动升级版本。请参阅 手动升级数据库系统。
维护如何处理自动次要版本升级
那么，当一个版本的退役与维护同步时会发生什么呢？这个过程是经过深思熟虑的，并与 Oracle 的发布时间表紧密相关：
- 触发点： 当某个版本不可用时（例如，2025 年 10 月发布的 8.0.39 错误修复），HeatWave 不会立即升级。相反，它会将升级安排在该日期之后的下一个维护周期。
- 执行： 在此周期内，数据库将自动升级到下一个受支持的版本（例如，8.0.40 Bug Fix）。此升级包含在标准维护工作流程中，确保平稳过渡，无需人工干预。
- 规划影响： 由于一旦某个版本不再受支持，这些升级就是强制性的，因此最好关注 Oracle 的版本生命周期公告。例如，了解 8.0.39 将于 2025 年 10 月退役，可以让您为 10 月之后升级到 8.0.40 做好准备，很可能是在 2025 年 11 月的维护窗口期。
这种一致性可以确保您的系统始终处于受支持的版本，但也意味着维护有时需要兼顾两个目的：日常维护和版本升级。关键在于，这种情况仅在系统不可用时发生，而非主动调整。
一次性更新：超越月度周期的灵活性
HeatWave 服务还通过一次性更新（非每月发布一次的补丁或修复程序）提供灵活性。以下是它们与维护集成的方式：
- 立即应用： 当 Oracle 发布一次性更新（例如，关键安全补丁）时，您可以立即应用。这对于时间紧迫、刻不容缓的修复来说非常理想。
- 自动纳入： 如果您未手动应用更新，更新不会丢失——HeatWave 会将其纳入下一个月度维护周期。例如，2025 年 5 月 10 日发布的补丁可以立即应用，也可以推迟到 5 月底的月度维护时段。
- 这种双路径方法让您掌控全局：您可以快速响应紧急情况，或根据计划周期进行便捷更新。无论哪种方式，更新都能得到保障，这符合 HeatWave 对安全性和稳定性的承诺。
执行一次性更新：导航至 HeatWave MySQL -> DB 系统 -> DB 系统详细信息，然后单击 DB 系统信息面板中数据库版本下的编辑链接
图 1：维护 - 执行一次性更新
图 2：维护 - 执行一次性更新
从下拉菜单中，选择立即执行维护选项以完成一次性更新
维护执行机制
Oracle 会每月进行一次维护，维护时间会安排在您为数据库系统定义的每周维护开始时间的两小时内。维护流程如下：
调度： 您可以设置一个首选的每周维护时段（例如，每周日凌晨 2:00）。Oracle 会在每个月该时段后的两小时内启动维护。如果您未指定时段，Oracle 会自动分配一个：请确保该时段与您的低流量时段一致，以最大程度地减少中断。
执行： Oracle 端到端管理整个流程，无缝应用数据库修复、操作系统补丁和固件更新。无需任何人工干预，但了解时间安排有助于制定运营计划。
HeatWave 维护管理的最佳实践
为了充分利用此系统，请考虑以下提示：
- 定义您的维护窗口： 设置适合您工作负载的维护开始时间。如果 Oracle 指定了默认时间，请确认。
- 跟踪版本生命周期：通过监控Oracle 的版本可用性， 随时掌握自动小版本升级的动态 （例如，计划于 2025 年 10 月退役 8.0.39）
- 订阅 OCI 公告： 通过电子邮件、短信或其他渠道及时获取有关 HeatWave MySQL 运营的更新
- 配置客户联系人： 确保正确的团队收到补丁通知 - 不要依赖默认的租户管理员电子邮件
- 利用事件通知： 使用 REST API 或 SDK 将维护开始/结束事件集成到您的监控或自动化工具中
- 利用一次性更新： 必要时立即应用关键补丁，或将其纳入非紧急情况下的月度更新周期
- 测试升级： 当自动小升级迫在眉睫时（例如，8.0.39 到 8.0.40），请事先在暂存环境中测试新版本
结论：维护作为战略资产
MySQL HeatWave 服务的维护功能是一款强大的工具，可确保您的数据库安全高效，并具备处理版本升级和一次性更新的内置灵活性。通过了解其在版本内稳定性的目的与其在强制升级中的作用，并利用即时补丁选项，您可以根据自己的运营需求进行调整。无论是日常维护还是战略性版本迁移，HeatWave 的维护流程都能确保您的系统持续保持最新状态并具有弹性。
