Upgrade Preparation for Redis Software 8.0.2

Preparing a Redis Software cluster for the 8.0.2 upgrade ensures a stable, predictable process with minimal downtime. This guide walks through supported upgrade paths, cluster and node health checks, database version compatibility, backup validation, licensing checks, and primary node sequencing.

If your deployment places Redis behind a load balancer (such as F5), contact Support before upgrading. Some load-balancer configurations require a non-standard upgrade sequence where the master node cannot be upgraded first.

Covers: Supported Upgrade Paths • Cluster & Node Checks • Database Compatibility • Backup Validation • Licensing • Primary Node Identification • Artifacts to Capture

Quick Reference: Supported Versions

Upgrade Preparation Steps

1) Review Release Notes and Known Behaviors

• Review RS 8.0.2 Release Notes for features, performance changes, and known limitations.
• Default DB version in 8.0.2 is Redis 8.2 (8.0/7.4/7.2/6.2 are supported).
• Modules: Only built-in modules are supported; custom/user modules are not supported in this release.
• Flash / Flex: Redis 8 databases cannot use Flash. Use 8.2 for Flash-enabled DBs.
• ACL categories (e.g., @json, @search) are defined but not active in 8.0.2-17. Use explicit command permissions if needed.

2) Pre-Upgrade Cluster & Node Checks

Run cluster/node health checks:

rladmin status extra all
rladmin cluster running_actions

All shards, nodes, and endpoints must show OK, and there should be no running actions.

Verify administrative access
Confirm you can run rlcheck and rladmin with appropriate privileges (root or equivalent).
Resolve any sudo or authentication issues before proceeding.

3) Database Version Compatibility

Action: Any DB earlier than Redis 6.2 must be upgraded before performing the cluster upgrade.

4) Licensing Checks

Avoid upgrade blocks by validating:

• License is valid and not expired
• FQDN in license matches cluster FQDN
• Capacity/shard limits won’t block post-upgrade operations

5) Backup & Restore Validation

Backup requirements

• Full backups of all databases before upgrade
• Test restores on a staging cluster (do not rely only on file existence)
• Ensure storage space is sufficient for backups and any restore operations

Command examples

rladmin bdb backup <db_id>
rladmin status bdbs

Best practice: Label backups clearly (e.g., pre-8.0.2-upgrade-full-backup-YYYYMMDD).

6) Maintenance Window & Change Freeze

• Schedule a window appropriate for your method (in-place vs rolling upgrade).
• Pause automation/monitoring to avoid interference (external health checks, scripts, auto-scalers).
• Apply a strict change freeze: no topology changes, migrations, scaling, or config edits during the upgrade.

7) Identify the Primary (Master) Node

Standard practice requires upgrading the primary (master) node first to avoid cluster hang or join failures.

Identify via:

• rladmin status nodes
• Cluster Manager UI (v7.2+)

Important: If your RS deployment is behind a load balancer such as F5, this sequencing may not be valid. Some L4/L7 configurations fail if the master node is upgraded first.
If Redis is behind a load balancer, contact Support before proceeding.

8) Capture Artifacts for Rollback & Audit

Pre-Upgrade Readiness Summary

Before starting the RS 8.0.2 upgrade, verify the following:

• You reviewed the 8.0.2-17 release notes and known limitations.

• Your cluster follows a supported upgrade path.

• All nodes and shards show healthy with no running actions.

• Administrative commands (rladmin, rlcheck) work on every node.

• All databases run Redis 6.2 or later.

• Full backups were taken and test-restored successfully.

• Your license is valid, matches the FQDN, and capacity limits are not exceeded.

• A maintenance window and change freeze are in place.

• The primary node is identified (and Support was contacted if using an F5/load balancer).

• Baseline artifacts (cluster info, config snapshot, dashboards) are captured.