Upgrade an existing Redis Enterprise Software deployment
To upgrade Redis Enterprise Software, you:
-
Upgrade the software on all nodes of the cluster.
-
(Optional) Upgrade each database in the cluster.
You don’t have to upgrade the databases in your cluster; however, new features and important fixes might not be enabled until you do so.
Default Redis database versions
When you upgrade an existing database or create a new one, it uses the default Redis version (default_redis_version
) unless you specify the database version explicitly with redis_version
in the REST API or rladmin upgrade db
.
Redis Enterprise Software v6.x includes two Redis database versions: 6.0 and 6.2. The default Redis database version differs between Redis Enterprise releases as follows:
Redis Enterprise |
Bundled Redis DB versions |
Default DB version (upgraded/new databases) |
---|---|---|
6.2.x | 6.0, 6.2 | 6.0 |
6.4.2 | 6.0, 6.2 | 6.2 |
-
v6.2.x:
default_redis_version
is 6.0.Setting
redis_upgrade_policy
tomajor
enforces this default. However, if you changeredis_upgrade_policy
tolatest
, this enforces 6.2 as the default.The upgrade policy is only relevant for Redis Enterprise Software versions 6.2.4 through 6.2.18. For more information about upgrade policies, see the 6.2 version of this document.
-
v6.4.2:
default_redis_version
is 6.2.Both
major
andlatest
upgrade policies use this new default.You can override the default version with
rladmin tune cluster
; however, this might limit future upgrade options:rladmin tune cluster default_redis_version 6.0
Supported upgrade paths
The following upgrade paths are supported:
Current cluster version |
Upgrade to cluster version |
---|---|
6.2.x | 6.4.2 |
6.0.x | 6.4.2 6.2.x |
5.6 | 6.0.x |
Upgrade a cluster
Upgrade prerequisites
Before upgrading a cluster:
-
Verify that you meet the upgrade path requirements for your desired cluster version and review the relevant release notes for any preparation instructions.
-
Identify the cluster master node and upgrade that node first.
Use the
rladmin status nodes
command or send aGET /nodes/status
request to the REST API to identify the master node.
Cluster upgrade process
Starting with the master node, follow these steps for every node in the cluster. (We recommend upgrading each node separately to ensure cluster availability.)
-
Download the Redis Enterprise Software installation package to the machine running the node.
For help, see Download the installation package
-
Untar the installation package. Note that neither the installation path nor the user can be changed during the upgrade.
-
Verify node operation with the following commands:
rlcheck rladmin status extra all
-
Run the install command:
sudo ./install.sh -y
The installation script automatically recognizes the upgrade and responds accordingly.
The upgrade replaces all node processes, which might briefly interrupt any active connections.
-
Verify node operation by repeating the commands from Step 3.
-
If the admin console was open in a web browser during the upgrade, refresh the browser to reload the console.
When each node is upgraded, the cluster is fully upgraded.
Upgrade a database
Upgrade prerequisites
Before upgrading a database:
-
Review the relevant release notes for any preparation instructions.
-
Verify that the database version meets the minimums specified earlier.
To determine the database version:
-
Use the admin console to open the Configuration tab for the database.
-
Use the
rladmin status extra all
command to display configuration details. When the database compatibility version is outdated, appears in the command output.OLD REDIS VERSION
-
-
Verify the cluster is fully upgraded and operational.
Use the admin console to display the Configuration tab for the cluster. The tab displays the cluster version information and the Redis database compatibility version.
-
To avoid data loss during the upgrade, take care to back up the data.
You can export the data to an external location, enable replication, or enable persistence.
When choosing how to back up data, keep the following in mind:
-
To reduce downtime when replication is enabled, a failover is performed before restarting the master database.
-
When persistence is enabled without replication, the database is unavailable during restart because the data is restored from the persistence file. AOF persistence restoration is slower than snapshot restoration.
-
Database upgrade process
To upgrade a database:
-
Verify that the
redis_upgrade_policy
is set according to your preferences. -
(Optional) Back up the database to minimize data loss.
-
Use
rladmin
to upgrade the database:rladmin upgrade db <database name | database ID>
This restarts the database. No data is lost.
-
Check the Redis database compatibility version for the database to confirm the upgrade.
To do so:
-
Use the admin console to open the Compatibility tab for the database; the Redis version displays the Redis database compatibility version.
-
Use
rladmin status databases extra all
to display a list of the databases in your cluster and their current Redis database compatibility version.
Verify that the Redis version is set to the expected value.
-
When you upgrade an Active-Active (CRDB) database, you can also upgrade:
-
Protocol version - Starting with version 5.4.2, a new CRDB protocol version helps support Active-Active features.
The CRDB protocol is backward-compatible, which means v5.4.2 CRDB instances can understand write-operations from instances using the the earlier CRDB protocol. However, earlier CRDB instances (those using the older protocol cannot) understand write-operations from instances using the newer protocol version.
Once you upgrade the CRDB protocol on one instance, non-upgraded instances cannot receive write updates from the upgraded instance.
The upgraded instance receives updates from upgraded and non-upgraded instances.
When upgraded to the latest protocol version, upgraded instances automatically receives any missing write-operations.
Guidelines:
-
Upgrade all instances of a specific CRDB within a reasonable time frame to avoid temporary inconsistencies between the instances.
-
Make sure that you upgrade all instances of a specific CRDB before you do global operations on the CRDB, such as removing instances and adding new instances.
-
As of v6.0.20, protocol version 0 is deprecated; support will be removed in a future version.
-
To avoid upgrade failures, update all Active-Active databases to the latest protocol version before upgrading Redis Enterprise Software to v6.0.20 or later.
-
-
Feature version - Starting with version 5.6.0, a new feature version (also called a feature set version) helps support new Active-Active features.
When you update the feature version for an Active-Active database, the feature version is updated for all of the database instances.
Guidelines:
-
As of v6.0.20, feature version 0 is deprecated; support will be removed in a future version.
-
To avoid upgrade failures, update all Active-Active databases to the latest protocol version before upgrading Redis Enterprise Software to v6.0.20 or later.
-
To upgrade a CRDB instance:
-
Upgrade Redis Enterprise Software on each node in the clusters where the CRDB instances are located.
-
To see the status of your CRDB instances, run:
rladmin status
The statuses of the CRDB instances on the node can indicate:
OLD REDIS VERSION
OLD CRDB PROTOCOL VERSION
OLD CRBD FEATURESET VERSION
-
To upgrade each CRDB instance, including the Redis version and CRDB protocol version, run:
rladmin upgrade db <database_name | database_ID>
If the protocol version is old, read the warning message carefully and confirm.
The CRDB instance uses the new Redis version and CRDB protocol version.
Use the
keep_crdt_protocol_version
option to upgrade the database feature version without upgrading the CRDB protocol version.If you use this option, make sure that you upgrade the CRDB protocol soon after with the
rladmin upgrade db
command.You must upgrade the CRDB protocol before you update the CRDB feature set version.
-
If the feature set version is old, you must upgrade all of the CRDB instances. Then, to update the feature set for each active-active database, run:
crdb-cli crdb update --crdb-guid <CRDB-GUID> --featureset-version yes
You can retrieve the
<CRDB-GUID>
with the following command:crdb-cli crdb list
Look for the fully qualified domain name (CLUSTER-FDQN) of your cluster and use the associated GUID:
CRDB-GUID NAME REPL-ID CLUSTER-FQDN 700140c5-478e-49d7-ad3c-64d517ddc486 aatest 1 aatest1.example.com 700140c5-478e-49d7-ad3c-64d517ddc486 aatest 2 aatest2.example.com