Alauda Cache Service E1
  • 简体中文

    • 升级

    Alauda Cache Service E1 经过设计，可在所有受支持的版本之间提供服务连续性和数据安全性。本指南详细介绍版本兼容性，并概述推荐的升级路径，以帮助您的环境顺利完成过渡。

    升级提示

    在升级生产环境之前，强烈建议先在开发环境或预发布环境中验证升级过程。此初步步骤有助于在潜在兼容性问题（包括与硬件相关的冲突）影响生产服务之前，及时发现并缓解这些问题。

    目录

    版本兼容性原则前提条件受支持的升级路径升级策略小版本升级补丁版本升级大版本升级升级步骤

    版本兼容性原则

    Alauda Cache Service E1 遵循语义化版本控制原则，并提供以下兼容性保证：

    • 补丁版本（x.y.z）在同一小版本系列中完全向后兼容和向前兼容。
    • 小版本（x.y.z）在同一大版本中保持 API 和功能兼容性。
    • 大版本（x.y.z）可能引入需要特定升级操作步骤的不兼容变更。

    前提条件

    开始升级前，请确保满足以下前提条件：

    1. 版本兼容性：当前版本必须位于受支持的升级路径上。
    2. 组件运行状况：所有 Redis 实例都必须报告 Ready 状态。
    3. 资源可用性：集群必须具备足够的 CPU、内存和存储资源以完成升级。
    4. 备份：必须具有所有关键数据和配置的最新备份。

    受支持的升级路径

    下表列出了经过测试的版本组合及其相应的依赖项：

    Alauda Cache Service E1 版本Redis Server 版本ACP 版本
    v5.1.x6.0.22, 7.2.16v4.2, v4.3, v4.4
    v5.0.x6.0.21, 7.2.12, 7.2.14v4.1, v4.2, v4.3
    v4.1.x5.0.14, 6.0.20, 7.2.10v4.1, v4.2
    v4.0.x5.0.14, 6.0.20, 7.2.xv4.0
    v5.1.x 的 ACP 兼容性

    Alauda Cache Service E1 v5.1.x 仅可运行于 ACP v4.2、v4.3 和 v4.4。不支持在 ACP v4.1 上运行：请先将 ACP 升级到 v4.2 或更高版本，再升级 Alauda Cache Service E1；或者继续使用 v5.0.x。

    相反，Alauda Cache Service E1 v5.0.x 及更早版本尚未在 ACP v4.4 上经过测试。升级到 ACP v4.4 前，请先将 Alauda Cache Service E1 升级到 v5.1.0 或更高版本。

    ACP v4.3 兼容性

    Alauda Cache Service E1 v4.1.x 和 v4.0.x 尚未在 ACP v4.3 上经过测试。升级到 ACP v4.3 前，请先将 Alauda Cache Service E1 升级到 v5.0.0 或更高版本。

    升级到 ACP v4.3 前先升级 Redis 5.0 实例

    升级 Alauda Cache Service E1 operator 不会自动升级现有实例的 Redis 版本；必须显式升级每个实例的 Redis 版本。

    由于 ACP v4.3 要求 Alauda Cache Service E1 v5.0.0 或更高版本，而这些版本不再支持 Redis 5.0，因此从早于 v4.3 的 ACP 版本升级到 v4.3 之前，必须先将每个 Redis 5.0 实例升级到受支持的版本（6.0 或 7.2）。

    开始 ACP 升级前，请确认 VERSION 列中没有实例报告 5.0（例如运行 kubectl get redis -A）。有关升级操作步骤，请参阅实例升级指南。

    跨 Redis 小版本升级复制实例

    如果实例启用了跨数据中心复制，则无法单独更改其 Redis 版本。请按照将灾难恢复组从 Redis 6.0 升级到 Redis 7.2的说明操作，该操作会协调整个复制组。

    升级到 v5.1 期间的复制实例

    将 operator 升级到 v5.1 不会中断现有的灾难恢复组。复制会在升级期间继续进行，双方的数据不受影响——实例会继续使用当前的 Redis 版本，因此仍会运行之前使用的模块版本。

    有一项内容会发生迁移。在 v5.1 中，链接凭证通过实例上的 spec.activeRedis.redisUserRef 声明，而不是通过连接上的 spec.secretName 声明；operator 会在升级后的首次 reconcile 中为每个复制实例写入该绑定。它会指定实例自己的默认账户，即 Redis 6.0 链接始终用于进行身份验证的账户，因此线路上的内容不会发生变化，也无需执行任何操作。

    您的清单确实需要进行更改：从 ActiveRedisConnection 和 ActiveRedisInspection 中移除 spec.secretName；仍设置该字段的清单会在下一次 apply 时被拒绝。请参阅设置灾难恢复复制。

    升级策略

    小版本升级

    • 方式：支持从同一大版本中的任意小版本直接升级到更新的版本（例如，4.0.x → 4.1.0）。
    • 优势：这种方式可最大限度地降低操作风险，并实现版本之间的无缝过渡。

    补丁版本升级

    • 兼容性：同一小版本系列中的补丁版本完全兼容。
    • 示例：在同一小版本系列中升级（例如，x.y.0 → x.y.1）会应用最新的 bug 修复和安全补丁。

    大版本升级

    • 要求：跨大版本升级时（例如，4.1.0 → 5.0.0），请直接升级到目标大版本的最新可用版本。
    • 操作步骤：按照以下升级操作步骤升级 operator，然后按照实例升级指南升级各个实例。
    • 注意事项：大版本升级可能需要修改配置，并全面检查功能兼容性。

    升级步骤

    1. 从 AlaudaCloud 下载目标版本的 Alauda Cache Service E1 plugin，并将其保存到可访问 ACP 集群的节点上。
    2. 使用 violet 软件包管理工具将 plugin 上架到目标集群。有关详细说明，请参阅Upload Packages文档。
    3. 升级会按照 Subscription 中配置的策略执行：

      • Automatic Upgrade：上传后，plugin 会自动升级。

      • Manual Upgrade：

        CLI
        Web Console
        # Check for available upgrades
$ kubectl -n redis-system get subscriptions.operators.coreos.com redis-operator -o go-template='{{ printf "Installed: %s\n  Current: %s" .status.installedCSV .status.currentCSV }}'

# If an upgrade is available, find the corresponding InstallPlan for the Subscription
$ kubectl -n redis-system get subscriptions.operators.coreos.com redis-operator -o jsonpath='{.status.installplan.name}'

# Approve the InstallPlan to proceed with the upgrade
$ kubectl -n redis-system patch --type='json' -p='[{"op":"replace","path":"/spec/approved","value":true}]'

        有关升级 plugin 的详细说明，请参阅Operator文档。

    4. 要升级 Redis 实例本身，请参阅实例升级指南。