Upgrade Redis Enterprise Software
To upgrade the Redis Enterprise Software software on a cluster, you must upgrade each of the nodes and then upgrade each of the databases in the cluster.
For Active-Active clusters, you must upgrade all the nodes on all clusters first, and then upgrade each of the databases in each cluster.
- To upgrade your cluster to v6.0, your cluster must first be on 5.4.0 or above
and the databases must be running Redis 5.
- To upgrade your cluster to v6.0.20, your cluster must first be on 5.6.0
- To upgrade your cluster to v5.6, your cluster must first be on 5.0.2-30 or above.
- To upgrade your cluster to v5.4, your cluster must first be on 5.0 or above.
- To upgrade your cluster to v5.2, your cluster must first be on 4.5 or above.
The upgrade process for a Redis Enterprise Software cluster is “ongoing” when the nodes in the cluster have mixed versions. The upgrade is only considered complete when all of the nodes are upgraded to the new version.
Upgrade a node
Upgrading the software on a node requires installing the RS installation package on all of the machines on which RS is installed.
- You must upgrade the master node before you upgrade the other nodes.
We recommend that you plan to keep all nodes up until the upgrade is completed
on all nodes. The node role is shown in the output of the
rladmin status nodescommand.
- You cannot change the installation path or user during upgrade.
- Node upgrade fails if the SSL certificates were configured in version 5.0.2 or above by manually updating the certificates on the disk instead of updating them through the API. For assistance with this issue, contact Support.
You run install.sh from the directory where you untarred the media just like you do for a new installation. The software recognizes this is an upgrade and proceeds accordingly.
Just like for a new installation, you must sudo or be root to do the upgrade.
To upgrade a node run:
The node upgrade process restarts the services running RS, which causes a short interruption to connections to the proxy, node and databases.
To make sure that the node is functioning properly, run
rladmin status extra all
on the node both before and after the upgrade.
If you have the RS management UI open in the browser while you are upgrading the nodes, make sure that you refresh the browser before trying to work with the UI again.
Upgrade a database
Some upgrades add support for new Redis versions. In these cases, Redis Labs recommends that you upgrade the databases to the new Redis version, although this is not mandatory because upgrades are backward compatible. Redis Software also supports a mix of Redis database versions.
Redis Software always supports two Redis versions. By default, new Redis databases
are created with the latest version, and existing databases get upgraded
to the latest version according to the instructions detailed below. If
you would like to change the default Redis version to the previous
version supported, you should use the
tune cluster default_redis_version
command in the
rladmin CLI and set it to the previous Redis version supported.
To check whether your Redis database versions match the latest supported Redis version:
- In the rladmin CLI,
statuscommand. If the Redis version is not the latest supported, an indication appears in the command output next to the database’s status.
- In the Management UI, go to the Cluster > Configuration page. The page lists the latest Redis version supported.
If the Redis database versions are older than the version supported by RS, Redis Labs recommends that you upgrade your Redis databases.
To upgrade your database:
- Make sure that all of the nodes in the RS cluster are upgraded. You cannot upgrade databases before all of the nodes in the cluster are upgraded.
- In the rladmin CLI
on any node in the cluster, run this command for each database:
rladmin upgrade db <database_name | database_ID>
During the database upgrade process, the database is restarted. As a result:
- For databases that have replication enabled, a failover is done before the master database restarts to make sure that there is no downtime.
- For databases without replication but with persistence enabled, the database is unavailable during the restart because data is restored from the persistence file. The length of the downtime is different for each persistence option. For example, AOF usually takes longer than an RDB file.
- For databases that have neither replication nor persistence enabled, the database loses all its data after it is restarted.
Upgrade Active-Active databases
When you upgrade an Active-Active (CRDB) database, you can also upgrade:
Protocol version - RS 5.4.2 and higher include a new CRDB protocol version to support new Active-Active features. The CRDB protocol is backward-compatible so that RS 5.4.2 CRDB instances can understand write-operations that come from instances with the older CRDB protocol, but CRDB instances with the older protocol cannot understand write-operations of instances with the newer protocol version. As a result, after you upgrade the CRDB protocol on one instance, instances that were not upgraded yet cannot receive write updates from the upgraded instance. The upgraded instance receives updates from upgraded and non-upgraded instances.Note:
- 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.
- Protocol version 0 is deprecated on RS 6.0.20 or later.
- To avoid a failed upgrade, make sure all your Active-Active databases are configured with the latest protocol version before upgrading to Redis Enterprise Software 6.0.20 or later.
After you upgrade an instance to use the new protocol version, it automatically receives any missing write-operations.
Feature set version - RS 5.6.0 and higher include a new feature set version to support new Active-Active features. When you update the feature set version for an Active-Active database, the feature set version is updated for all of the database instances.Note:
- Feature set version 0 is deprecated on RS 6.0.20 or later.
- To avoid a failed upgrade, make sure all your Active-Active databases are configured with the latest feature set version before upgrading to Redis Enterprise Software 6.0.20 or later.
To upgrade a CRDB instance:
Upgrade RS on each node in the clusters where the CRDB instances are located.
To see the status of your CRDB instances, run:
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.To upgrade the CRDB instance without upgrading the protocol version:
You can use the
keep_crdt_protocol_versionoption to upgrade the database without upgrading the CRDB protocol version and continue using the old version. If you use this option, make sure that you upgrade the CRDB protocol soon after with the
rladmin upgrade dbcommand.
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