title: Create a support package

summary: Create a support package that gathers essential information to help debug issues.

title: Overview

text:
If you encounter any issues that you are not able to resolve yourself
and need to [contact Redis support](https://redis.io/support/) for assistance, you can [create a support package](#create-support-package) that gathers all essential information to help debug
your issues.

The process of creating the support package can take several minutes and generates load on the system.

title: Create support package

text:
**Cluster Manager UI:**

To create a support package from the Cluster Manager UI:

1. In the navigation menu, select **Support**.

1. Click **Proceed**.

1. In the **Generate support package** dialog, select one of the following options:

    - **Full package including all nodes and databases**: Creates a support package with information about all nodes and databases in the cluster.

    - **For Databases**: Creates a support package that includes database information.

        - Select **All Databases** from the **Database name (Database ID)** list to include information about all databases in the cluster.

        - Select a specific database from the **Database name (Database ID)** list to include information about that database only.

    - **For Nodes**: Creates a support package that includes node information.

        - Select **All Nodes** from the **Node ID (IP Addresses)** list to include information about all nodes in the cluster.

        - Select a specific node from the **Node ID (IP Addresses)** list to include information about that node only.

1. Click **Generate package**.

1. The package is created and downloaded by your browser.

**rladmin:**

If package creation fails with `internal error` or if you cannot access the UI, create a support package for the cluster from the command line on any node in the cluster using the [`rladmin cluster debug_info`]() command:

[code example]

- If `rladmin cluster debug_info` fails for lack of space in the `/tmp` directory, you can:

    1. Change the storage location where the support package is saved:

        [code example]

        The `redislabs` user must have write access to the storage location on all cluster nodes.

    1. On any node in the cluster, run:

        [code example]

- If `rladmin cluster debug_info` fails for another reason, you can create a support package for the cluster from the command line on each node in the cluster with the command:

    [code example]

Upload the tar file to [Redis support](https://redis.com/company/support/). The path to the archive is shown in the command output.

**REST API:**

You can use `debuginfo` [REST API]() requests to create and download support packages.

To download debug info from all nodes and databases:

[code example]

To download debug info from all nodes:

[code example]

To download debug info from a specific node, replace `<uid>` in the following request with the node ID:

[code example]

To download debug info from all databases:

[code example]

To download debug info from a specific database, replace `<uid>` in the following request with the database ID:

[code example]

title: Support package files

text:
The support package is a zip file that contains all cluster configuration and logs.

When downloaded from the Cluster Manager UI, the support package's name is `debuginfo.tar.gz`.

title: Database support package files

text:
Cluster and database support packages collect database details in `database_<bdb_uid>` directories, where `<bdb_uid>` is the database ID, and Redis shard details in `<node_uid>` directories.

The following table describes the included files:

| File | Description |
|------|-------------|
| ccs-redis.json | Primary node's local cluster configuration store (CCS). |
| /database_<bdb_uid>/ | Directory that includes files for a specific database.<bdb_uid> is the database ID. |
| database_<bdb_uid>_ccs_info.txt | Database information from the cluster configuration store (CCS). Includes settings for databases, endpoints, shards, replicas, and CRDB. |
| database_<bdb_uid>.clientlist | List of clients connected to the database when the support package was created. |
| database_<bdb_uid>.info | Redis information and statistics for the database. See [`INFO`]() for details about the collected fields. |
| database_<bdb_uid>.rladmin | Database information. See [`rladmin info db`]() for an example of collected fields. Also includes creation time, last changed time, Redis version, memory limit, persistence type, eviction policy, hashing policy, and whether SSL, backups, and email alerts are enabled. |
| database_<bdb_uid>.slowlog | Contains slowlog output, which includes commands that took longer than 10 milliseconds. Only included if `slowlog_in_sanitized_support` is `true` in cluster settings. |
| /node_<node_uid>/redis_<shard_uid>.txt | For each shard of the specified database only. Includes shard configuration and [information](), slowlog information, and latency information. |

title: Node support package files

text:
Cluster and node support packages collect node details in `node_<node_uid>` directories, where `<node_uid>` is the node ID.

The following table describes the included files:

| File | Description |
|------|-------------|
| ccs-redis.json | The node's local cluster configuration store (CCS). |
| /conf/ | Directory that contains configuration files. |
| /logs/ | Directory that includes logs. |
| node_<node_uid>.ccs | Includes cluster configuration, node configuration, and DMC proxy configuration. |
| node_<node_uid>_envoy_config.json | Envoy configuration. |
| node_<node_uid>.rladmin | Information about the cluster's nodes, databases, endpoints, and shards. See [`rladmin status`]() for example output. |
| node_<node_uid>_sys_info.txt | Node's system information including:
• Socket files list
• Log files list
• Processes running on the node
• Disk usage
• Persistent files list
• Memory usage
• Network interfaces
• Installed packages
• Active iptables
• OS and platform
• Network connection
• Status of Redis processes |
| redis_<shard_uid>.txt | For each shard of the specified database only. Includes shard configuration and [information](), slowlog information, and latency information. |

Each node's `/conf/` directory contains the following files:

- bootstrap_status.json
- ccs-paths.conf
- config.json
- envoy.yaml
- gossip_envoy.yaml
- heartbeatd-config.json
- last_bootstrap.json
- local_addr.conf
- node.id
- node_local_config.json
- redislabs_env_config.sh
- socket.conf
- supervisord_alert_mgr.conf
- supervisord_cm_server.conf
- supervisord_crdb_coordinator.conf
- supervisord_crdb_worker.conf
- supervisord_mdns_server.conf
- supervisord_pdns_server.conf

Each node's `/conf/` directory also contains the following key and cert modulus files:

- api_cert.modulus
- api_key.modulus
- ccs_internode_encryption_cert.modulus
- ccs_internode_encryption_key.modulus
- cm_cert.modulus
- cm_key.modulus
- data_internode_encryption_cert.modulus
- data_internode_encryption_key.modulus
- gossip_ca_signed_cert.modulus
- gossip_ca_signed_key.modulus
- mesh_ca_signed_cert.modulus
- mesh_ca_signed_key.modulus
- metrics_exporter_cert.modulus
- metrics_exporter_key.modulus
- proxy_cert.modulus
- proxy_key.modulus
- syncer_cert.modulus
- syncer_key.modulus

title: Related info

text: - [Uploading Support Packages & Cluster Health Analysis](https://support.redislabs.com/hc/en-us/articles/26502436628370-Uploading-Support-Packages-Cluster-Health-Analysis)

section_id: create-support-package

code: rladmin cluster config debuginfo_path <path>

code: rladmin cluster debug_info

code: GET /v1/cluster/debuginfo

code: GET /v1/nodes/debuginfo

code: GET /v1/nodes/<uid>/debuginfo

code: GET /v1/bdbs/debuginfo

code: GET /v1/bdbs/<uid>/debuginfo


title: Install, set up, and upgrade Redis Software

summary: Learn how to install, set up, and upgrade Redis Software.

summary: Follow these quickstarts to try out Redis Software.

title: Redis Software quickstarts

summary: Install Redis Software on Linux.

title: Install Redis Software

summary: How to upgrade a cluster's Redis Software version, database version, and operating system.

title: Upgrade an existing Redis Software deployment

title: Uninstall Redis Software

title: Additional configuration

summary: The product lifecycle of Redis Software cluster versions.

title: Redis Software product lifecycle

title: Create a support package

page_type: content

title: Overview

role: overview

text:
You can run self-managed Redis Software in an on-premises data center or on your preferred cloud platform.

If you prefer a fully managed Redis database-as-a-service, available on major public cloud services, consider setting up a [Redis Cloud]() subscription. You can [try Redis Cloud](https://redis.io/try-free/) for free.

title: Quickstarts

role: setup

text:
If you want to try out Redis Software, see the following quickstarts:

- [Redis Software quickstart]()

- [Docker quickstart for Redis Software]()

title: Install Redis Software

text:
To install Redis Software on a [supported platform](), you need to:

1. [Plan your deployment]().

1. [Prepare to install]().

1. [Perform the install]().

Depending on your needs, you may also want to [customize the installation](#more-info-and-options).

title: Upgrade existing deployment

role: content

text:
If you already installed Redis Software, you can:

- [Upgrade a cluster]()

- [Upgrade a database]()

- [Upgrade an Active-Active database]()

title: Uninstall Redis Software

text: - [Uninstall existing deployment]()

title: More info and options

text:
More information is available to help with customization and related questions:

- [CentOS/RHEL firewall configuration]()
- [Change socket file location]()
- [Cluster DNS configuration]()
- [Cluster load balancer setup]()
- [File locations]()
- [Linux swap space configuration]()
- [mDNS client prerequisites]()
- [User and group ownership]()

title: Next steps

text:
After you install Redis Software and set up your cluster, you can:

- [Add users]() to the cluster with specific permissions.  To begin, start with [Access control]().

- [Create databases]() to use with your applications.


title: Customize installation directories

summary: Customize Redis Software installation directories.

title: Overview

text:
When you install Redis Software on Red Hat Enterprise Linux, you can customize the installation directories.

The files are installed in the `redislabs` directory located in the path that you specify.

title: Considerations

text:
- When you install with custom directories, the installation does not run as an RPM file.

- If a `redislabs` directory already exists in the path that you specify, the installation fails.

- All nodes in a cluster must be installed with the same file locations.

- Custom installation directories are not supported for databases using Auto Tiering.

- [Configure different mount points for data and log directories](#config-diff-data-log-dirs).

title: Specify file locations

text:
You can specify these file locations:

| Files               | Installer flag | Example parameter | Example file location |
| ------------------- | -------------- | ----------------- | --------------------- |
| Binaries files      | --install-dir  | /opt              | /opt/redislabs        |
| Configuration files | --config-dir   | /etc/opt          | /etc/opt/redislabs    |
| Data and log files  | --var-dir      | /var/opt          | /var/opt/redislabs    |

These files are not in the custom directories:

- OS files
    - /etc/cron.d/redislabs
    - /etc/firewalld/services
    - /etc/firewalld/services/redislabs-clients.xml
    - /etc/firewalld/services/redislabs.xml
    - /etc/ld.so.conf.d/redislabs_ldconfig.conf.tmpl
    - /etc/logrotate.d/redislabs
    - /etc/profile.d/redislabs_env.sh
    - /usr/lib/systemd/system/rlec_supervisor.service.tmpl
    - /usr/share/selinux/mls/redislabs.pp
    - /usr/share/selinux/targeted/redislabs.pp

- Installation reference files
    - /etc/opt/redislabs/redislabs_custom_install_version
    - /etc/opt/redislabs/redislabs_env_config.sh

To specify directories during [installation](), include installer flags as [command-line options]() when you run the `install.sh` script. For example:

[code example]

title: Configure different mount points for data and log directories {#config-diff-data-log-dirs}

role: configuration

text:
To configure different mount points for data and log directories, use symbolic links:

1. Create a symbolic link for the data directory:

    [code example]

1. Create a symbolic link for the log directory:

    [code example]

title: Customize storage paths

text:
When you install Redis Software to custom directories, you can specify custom storage paths for persistent and ephemeral storage during [cluster setup]() or when [adding nodes]().

1. Specify the custom file location with the `--var-dir` option when you install Redis Software:

    [code example]

2. Grant the `redislabs` user access to the custom directories:
   [code example]

3. Confirm the storage path is properly mounted:
   [code example]

4. Verify the directory exists and is accessible:
   [code example]

For more information about storage requirements, see [Persistent and ephemeral node storage]().

title: Limitations

role: limits

text:
Several Redis Software installation reference files are installed to the directory `/etc/opt/redislabs/` even if you use custom installation directories.

As a workaround to install Redis Software without using any root directories, do the following before installing Redis Software:

1. Create all custom, non-root directories you want to use with Redis Software.

1. Mount `/etc/opt/redislabs` to one of the custom, non-root directories.

code: sudo ./install.sh --install-dir <path> --config-dir <path> --var-dir <path>

section_id: specify-file-locations

code: ln -s /var/opt/redislabs/data </path/to/data/mount/point>

code: ln -s /var/opt/redislabs/log </path/to/log/mount/point>

code: sudo ./install.sh --var-dir <path>

section_id: customize-storage-paths

code:
$ sudo chown -R redislabs:redislabs /path/to/custom/storage
   $ sudo chmod -R 755 /path/to/custom/storage

code:
$ df -h /path/to/custom/storage
   $ mount | grep /path/to/custom/storage

code: ls -l /path/to/custom/storage


title: Customize system user and group

summary: Specify the user and group who own all Redis Software processes.

title: Overview

text:
By default, Redis Software is installed with the user:group `redislabs:redislabs`.

During installation, you can specify the user and group that own all Redis Software processes.

title: Considerations

text:
- Custom installation user is supported on Red Hat Enterprise Linux and compatible distributions.

- You must create the user and group before installing Redis Software.

- You must install Redis Software on all nodes in the cluster with the same user and group.

- You can specify an LDAP user as the installation user.

- If you specify the user only, then installation is run with the primary group that the user belongs to.

title: Install with custom user or group

text:
To customize the user or group during [installation](), include the `--os-user` or `--os-group` [command-line options]() when you run the `install.sh` script.

[code example]

code: sudo ./install.sh --os-user <user> --os-group <group>

section_id: install-with-custom-user-or-group


title: Install Redis Software

summary: Install Redis Software on Linux.

summary: Plan a deployment of Redis Software.

title: Plan Redis Software deployment

summary: Prepare to install Redis Software.

title: Prepare to install Redis Software

summary: Install Redis Software on Linux.

title: Install Redis Software on Linux

summary: Command-line options for the install.sh script.

title: Installation script command-line options

summary: Describes Redis Software installation questions and how to answer them automatically.

title: Manage installation questions

title: Customize installation directories

title: Customize system user and group

summary: If you install Redis Software on a machine with no internet connection, you need to perform two tasks manually.

title: Offline installation

title: Overview

text:
After you [plan your deployment](), [download a Redis Software installation package](), and finish [installation preparation]():

1. [Install the Redis Software package]() on one of the nodes in the cluster.

1. Repeat this process for each node in the cluster.

For installation on machines without an internet connection, see [Offline installation]().

title: Permissions and access

role: security

text:
- Redis Software installation creates the `redislabs:redislabs` user and group.

    Assigning other users to the `redislabs` group is optional. Users belonging to the `redislabs` group have permission to read and execute (e.g. use the `rladmin` status command) but are not allowed to write (or delete) files or directories.

- Redis Software is certified to run with permissions set to `750`, an industry standard.

Do not reduce permissions to `700`. This configuration has not been tested and is not supported.

- Redis Software requires `umask` to be `0022` during installation to correctly set permissions for the installed directories and files.

title: More info and options

text:
If you've already installed Redis Software, you can also:

- [Upgrade an existing deployment]().

- [Uninstall an existing deployment]().

To learn more about customization and find answers to related questions, see:

- [CentOS/RHEL Firewall configuration]()
- [Change socket file location]()
- [Cluster DNS configuration]()
- [Cluster load balancer setup]()
- [File locations]()
- [Supported platforms]()
- [Manage installation questions]()
- [mDNS client prerequisites]()
- [User and group ownership]()

title: Next steps

text:
After your cluster is set up with nodes, you can:

- [Add users]() to the cluster with specific permissions.  To begin, start with [Access control]().
- [Create databases]() to use with your applications.


title: Install Redis Software on Linux

summary: Install Redis Software on Linux.

title: Overview

text:
After you [download a Redis Software installation package](), install it on one of the nodes in the cluster.

For installation on machines without an internet connection, see [Offline installation]().

title: Install on Linux

text:
To install Redis Software, use the command line:

1. Copy the installation package to the node.

1. On the node, change to the directory where the installation package is located and extract the installation files:

    [code example]

1.  _(Optional)_ Use the  to confirm the authenticity of Ubuntu/Debian or RHEL RPM packages:

    - For Ubuntu:
        1. Import the key:
        [code example]
        2. Verify the package signature:
        [code example]

    - For RHEL:
        1. Import the key:
        [code example]
        2. Verify the package signature:
         [code example]

1. To start the installation process, run the installation script. See [installation script options]() for a complete list of command-line options.

    **For default installation:**
    [code example]

    **For custom installation directories:**

    If you need to specify custom storage paths for persistent or ephemeral storage during cluster setup, you must install Redis Software to custom directories.

    [code example]

    For detailed information about custom installations, see [Customize installation directories]().

- The Redis Software files are installed in the default [file locations]() unless you specify custom directories.
- By default, Redis Software runs on the OS as the `redislabs` user and `redislabs` group. If needed, you can [specify a different user and group]() during the installation.
- You must either be the root user or use `sudo` to run the installation script.

1. Answer the [installation questions]() when shown to complete the installation process.

To skip the installation questions, use one of the following methods:

- Run `./install.sh -y` to answer yes to all of the questions.
- Create an [answer file]() to answer installation questions automatically.

1. When installation completes successfully, the output displays the Cluster Manager UI's IP address:

    [code example]

1. Repeat this process for each node in the cluster.

title: Redis Flex and Auto Tiering installation

text:
If you want to use Redis Flex or Auto Tiering for your databases, review the prerequisites, storage requirements, and [other considerations]() and prepare and format the flash memory.

After you install Redis Software, use the `prepare_flash` script to prepare and format flash memory:

[code example]

This script finds unformatted disks and mounts them as RAID partitions in `/var/opt/redislabs/flash`.

To verify the disk configuration, run:

[code example]

title: More info and options

text:
To learn more about customization and find answers to related questions, see:

- [CentOS/RHEL firewall configuration]()
- [Change socket file location]()
- [Cluster DNS configuration]()
- [Cluster load balancer setup]()
- [mDNS client prerequisites]()
- [File locations]()
- [Supported platforms]()

title: Limitations

text:
Several Redis Software installation reference files are installed to the directory `/etc/opt/redislabs/` even if you use [custom installation directories]().

As a workaround to install Redis Software without using any root directories, do the following before installing Redis Software:

1. Create all custom, non-root directories you want to use with Redis Software.

1. Mount `/etc/opt/redislabs` to one of the custom, non-root directories.

title: Next steps

text:
1. [Create]()
    or [join]() an existing Redis Software cluster.

1. [Create a database]().

    For geo-distributed Active-Active replication, create an [Active-Active]() database.

1. [Add users]() to the cluster with specific permissions.  To begin, start with [Access control]().

code: tar vxf <tarfile name>

section_id: install-on-linux

code: gpg --import <path to GPG key>

code: rpm --import <path to GPG key>

code: rpm --checksig </path-to/package.rpm>

code: sudo ./install.sh

code:
Summary:
    -------
    ALL TESTS PASSED.
    2017-04-24 10:54:15 [!] Please logout and login again to make
    sure all environment changes are applied.
    2017-04-24 10:54:15 [!] Point your browser at the following
    URL to continue:
    2017-04-24 10:54:15 [!] https://<your_ip_here>:8443

code: sudo lsblk


title: Content

text:
Run `./install.sh --help` to view command-line options supported by the installation script.

The following options are supported:

| Option | Description |
|--------|-------------|
| `-y` | Automatically answers `yes` to all install prompts, accepting all default values
See [Manage install questions]()|
| <nobr>`-c <answer file>`</nobr> | Specify answer file used to respond to install prompts
See [Manage install questions]()|
| <nobr>`-s <socket dir>`</s> | Specify directory for redislabs unix sockets  _(new installs only)_|
| <nobr>`--install-dir <dir>`</nobr> | Specifies installation directory _(new installs only)_
 See [Customize install locations]()|
| <nobr>`--config-dir <dir>` | Configuration file directory *(new installs only)*
See [Customize install locations]()|
| <nobr>`--var-dir <dir>`</nobr> | Var directory used for installation *(new installs only)*
See [Customize install locations]()|
| <nobr>`--os-user <user>`| Operating system user account associated with install; default: `redislabs`
See [Customize user and group]() *(new installs only)*|
|<nobr>`--os-group <group>` | Operating system group associated with install; default: `redislabs`
See [Customize user and group]() *(new installs only)* |
| `--skip-dns-port-verification` | Skip DNS port verification during installation |
| <nobr>`--update-env-path`</nobr> | Add paths related to Redis Software to root's PATH environment variable
See [Manage install questions]() |


title: Manage installation questions

title: Overview

text:
Several questions are displayed during the Redis Software installation process.

Here, you'll find a list of these questions and learn how to automatically answer these questions to perform a silent install.

title: Installation questions

text:
Several questions appear during installation:

- **Linux swap file** - `Swap is enabled. Do you want to proceed? [Y/N]?`

    We recommend that you [disable Linux swap]() in the operating system configuration
    to give Redis Software control of the memory allocation.

- **Automatic OS tuning** - `Do you want to automatically tune the system for best performance [Y/N]?`

    To allow the installation process to optimize the OS for Redis Software, answer `Y`.
    The installation process prompts you for additional information.

    The `/opt/redislabs/sbin/systune.sh` file contains details about the tuning process.

- **Network time** - `Do you want to set up NTP time synchronization now [Y/N]?`

    Redis Software requires that all cluster nodes have synchronized time.
    You can either let the installation process configure NTP
    or you can [configure NTP manually]().

- **Firewall ports** - `Would you like to open RedisLabs cluster ports on the default firewall zone [Y/N]?`

    Redis Software requires that all nodes have [specific network ports]() open.
    To open the ports, you can:

    - Answer `Y` to let the installation process open these ports.
    - Answer `N` and configure the firewall manually for [RHEL/CentOS firewall]().
    - Answer `N` and configure the firewall on the node manually for your OS.

- **Installation verification (rlcheck)** - `Would you like to run rlcheck to verify proper configuration? [Y/N]?`

    Run the `rlcheck` installation verification to make sure that the installation completed successfully.
    If you want to run this verification at a later time, you can run:

    [code example]

- **User already exists** - `The user 'redislabs' already exists, which may lead to problems if it wasn't configured correctly. Would you like to proceed with the installation? (Y/N)?`

- **Group already exists** - `The group 'redislabs' already exists, which may lead to problems if it wasn't configured correctly. Would you like to proceed with the installation? (Y/N)?`

- **Update PATH** - `Add Redis-Enterprise paths to $PATH variable (recommended) [Y/N]?`

title: Answer install questions automatically

text: To perform a silent (or automated) install, answer the questions when you start the [install]().

title: Answer yes to all questions

text:
To automatically answer `yes` to all questions (which accepts the default values), run the [installation script]() with the `-y` parameter:

[code example]

title: Configure file to answer

text:
Use an answer file to manage your response:

1. Create a text file to serve as an answer file.

    The answer file can contain any of the following installation question parameters. If a parameter is not included in the file, the installation script will ask for your answer.

    | Parameter | Values | Description |
    |-----------|--------|-------------|
    | `firewall` | `yes`
`no` | Configure firewall and open required Redis ports. |
    | `ignore_existing_osuser_osgroup` | `yes`
`no` | Proceed if redislabs user/group already exists. |
    | `ignore_master_version` | `yes`
`no` | Continue the upgrade even if the primary node isn't upgraded. If `no`, stops installation if the primary node hasn't been upgraded. |
    | `ignore_swap` | `yes`
`no` | Continue even if swap is enabled. If `no`, stops installation if swap is enabled. |
    | `ntp` | `yes`
`no` | Configure NTP for time synchronization. |
    | `rlcheck` | `yes`
`no` | Run `rlcheck` after installation to validate the system. |
    | `update_env_path` | `yes`
`no` | Add Redis Software paths to the PATH environment variable. |
    | `systune` | `yes`
`no` | Automatically tune system performance (CPU, sysctl). If `yes`, answers `yes` to all system tuning questions. |

    Example answer file:

    [code example]

1. Run the [installation script]() with the `-c` command-line option and add the path to the answer file.

    For example:

    [code example]

section_id: installation-questions

code: ./install.sh -y

section_id: answer-yes-to-all-questions

code:
ignore_swap=no
    systune=yes
    ntp=no
    firewall=no
    rlcheck=yes
    ignore_existing_osuser_osgroup=no
    update_env_path=no
    ignore_master_version=no

section_id: configure-file-to-answer

code: ./install.sh -c /home/user/answers


title: Offline installation

title: Overview

text:
By default, the installation process requires an internet connection to
enable installing dependency packages and for [synchronizing the
operating system clock]() against an NTP server.

If you install Redis Software on a machine without an
internet connection, you need to perform two tasks manually.

title: Install required dependency packages

text: When you install Redis Software on a machine that is not connected to the internet, the installation process fails and displays an error message informing you it failed to automatically install dependencies. Review the installation steps in the console to see which missing dependencies the process attempted to install. Install all these dependency packages and then run the installation again.

title: Set up NTP time synchronization

text: At the end of the installation, the process asks if you want to set up NTP time synchronization. If you choose `Yes` while you are not connected to the internet, the action fails and displays the appropriate error message, but the installation completes successfully. Despite the successful completion of the installation, you still have to configure all nodes for [NTP time synchronization]().


title: Configure AWS EC2 instances for Redis Software

summary: Considerations for installing and running Redis Software on Amazon Elastic Cloud Compute (EC2) instances.

title: Overview

text:
There are some special considerations for installing
and running Redis Software on Amazon Elastic Cloud Compute (EC2) instances.

These include:

- [Storage considerations](#storage)
- [Instance types](#instance-types)
- [Security group configuration](#security)

title: Storage considerations {#storage}

text:
AWS EC2 instances are ephemeral, but your persistent database storage should
not be. If you require a persistent storage location for your database,
the storage must be located outside of the instance. When you
set up an instance, make sure it has a properly sized EBS-backed volume
connected. When you set up Redis Software on the instance, make sure that [the
persistence storage]() is configured to use this volume.

After [installing the Redis Software package]() on the instance
and **before** running through [the setup process](),
you must give the group `redislabs` permission to the EBS volume by
running the following command from the OS command-line interface (CLI):
[code example]

Another feature that may be of importance to you is the use of
Provisioned IOPS for EBS-backed volumes. Provisioned IOPS guarantee a
certain level of disk performance. There are two features in Redis Software where
this feature could be critical to use:

1. When using [Redis Flex or Auto Tiering]()
1. When using AOF on every write and there is a high write load. In
    this case, the provisioned IOPS should be on the nodes used as
    replicas in the cluster.

title: Instance types {#instance-types}

text:
Choose an instance type that has (at minimum) enough free memory and
disk space to meet the Redis Software [hardware
requirements]().

In addition, some instance types are optimized for EBS-backed volumes
and some are not. If you are using persistent storage, you should use an
instance type that is, especially if disk drain rate matters to your database
implementation.

title: Security group configuration {#security}

text:
When configuring the security group:

- Define a custom TCP rule for port 8443 to allow web browser access
    to the Redis Software Cluster Manager UI from the IP address range you use to
    access the Cluster Manager UI.
- If you are using the DNS resolving option with Redis Software, define a DNS UDP
    rule for port 53 to allow access to the databases' endpoints by
    using the [DNS resolving mechanism]().
- To create a cluster that has multiple nodes all running as instances on AWS,
    you need to define a security group that has an All TCP rule for all ports, 0 - 65535,
    and add it to all instances that are part of the cluster.
    This ensures that all nodes are able to communicate with each other.
    To limit the number of open ports, you can open only the [ports used by Redis Software]().

After successfully launching the instances:

1. Install Redis Software from the [Linux package or AWS AMI]().
2. [Set up the cluster]().

code: chown redislabs:redislabs /< ebs folder name>

section_id: storage-considerations-storage


title: File locations

summary: Redis Software file installation locations.

title: Overview

text: To ensure that Redis Software functions properly, be careful with the files in the application directories. If you modify or delete the application files, Redis Software might not work as expected.

title: Application directories

text:
The directories that Redis Software installs into are:

| **Path** | **Description** |
|------------|-----------------|
| /opt/redislabs | Main installation directory for all Redis Software binaries |
| /opt/redislabs/bin | Binaries for all the utilities for command-line access and management, such as [`rladmin`]() or [`redis-cli`]() |
| /opt/redislabs/config | System configuration files |
| /opt/redislabs/lib | System library files |
| /opt/redislabs/sbin | System binaries for tweaking provisioning |

title: Configuration and data directories

text:
The default directories that Redis Software uses for data and metadata are:

| **Path** | **Description** |
|------------|-----------------|
| /var/opt/redislabs | Default storage location for the cluster data, system logs, backups, and ephemeral, persisted data |
| /var/opt/redislabs/log | System logs for Redis Software |
| /var/opt/redislabs/run | Socket files for Redis Software |
| /etc/opt/redislabs | Default location for cluster manager configuration and certificates |
| /tmp | The /tmp filesystem is for temporary files and should be sized according to this formula: `<number-of-cluster-nodes> * <size-of-/var/opt/redislabs/log-filesystem>`  |

You can change these file locations for:

- [Ephemeral and persistence storage]() during cluster setup
- [Socket files]() after cluster setup

To specify custom paths for ephemeral and persistent storage during cluster setup, you must install Redis Software using [custom installation directories](). If you use the default installation, you cannot specify custom storage paths and will receive a "path not mounted" error.


title: Hardware requirements

summary: Redis Software hardware requirements for development and production environments.

title: Sizing considerations

title: General database sizing {#general-sizing}

text:
Factors to consider when sizing your database.

- **Dataset size** – Your limit should be greater than your dataset size to leave room for overhead.
- **Database throughput** – High throughput needs more shards, leading to a higher memory limit.
- [**Modules**]() – Using modules with your database consumes more memory.
- [**Database clustering**]() – Allows you to spread your data into shards across multiple nodes.
- [**Database replication**]() – Enabling replication doubles memory consumption.

title: Active-Active database sizing {#active-active-sizing}

text:
Additional factors for sizing Active-Active databases:

- [**Active-Active replication**]() – Requires double the memory of regular replication, which can be up to two times (2x) the original data size per instance.
- [**Database replication backlog**]() – For synchronization between shards. By default, this is set to 1% of the database size.
- [**Active-Active replication backlog**]() – For synchronization between clusters. By default, this is set to 1% of the database size.

Active-Active databases have a lower threshold for activating the eviction policy, because it requires propagation to all participating clusters. The eviction policy starts to evict keys when one of the Active-Active instances reaches 80% of its memory limit.

title: Sizing databases with Auto Tiering enabled  {#redis-on-flash-sizing}

text:
Additional factors for sizing  databases with Auto Tiering enabled:

- [**Database persistence**]() – Auto Tiering uses dual database persistence where both the primary and replica shards persist to disk. This may add some processor and network overhead, especially in cloud configurations with network-attached storage.


title: Plan Redis Software deployment

summary: Plan a deployment of Redis Software.

title: Hardware requirements

title: Supported platforms

summary: Configure paths for persistent storage and ephemeral storage.

title: Persistent and ephemeral node storage

title: File locations

title: Overview

text:
Before installing Redis Software, you need to:

- Set up your hardware. See [Hardware requirements]() and [Persistent and ephemeral node storage
]() for more information.

- Choose your [deployment platform]().

    Redis Software supports a variety of platforms, including:

    - Multiple Linux distributions (Ubuntu, Red Hat Enterprise Linux (RHEL), IBM CentOS, Oracle Linux)
    - [Amazon AWS AMI]()
    - [Docker container]() (for development and testing only)
    - [Kubernetes]()

    For more details, see [Supported platforms]().

- Open appropriate [network ports]() in the firewall to allow connections to the nodes.

- Configure [cluster DNS]() so that cluster nodes can reach each other by DNS names.
- By default, the installation process requires an internet connection to install dependencies and synchronize the operating system clock. To learn more, see [Offline installation]().

- [Configure different mount points for data and log directories]().

title: Next steps

text:
After you finish planning your deployment, you can:

- [Download an installation package]().

- [Prepare to install]() Redis Software.

- [View installation questions]() and prepare answers before installation.


title: Persistent and ephemeral node storage

title: Overview

text:
For each node in the cluster, you can configure paths for both persistent
storage and ephemeral storage. To do so, the volume must have full permissions for user and group `redislabs` or users:group `redislabs:redislabs`. See the [Customize system user and group]() page for instructions.

The persistent storage and ephemeral storage discussed in this document are not related
to Redis persistence or AWS ephemeral drives.

title: Persistent storage

text:
Persistent storage is mandatory. The cluster uses persistent storage to store
information that needs to persist if a shard or a node fails,
such as server logs, configurations, and files.

To set the frequency of syncs, you can configure [persistence]()
options for a database.

The persistent volume must be a storage area network (SAN)
using an EXT4 or XFS file system and be connected as an external storage volume.

When using append-only file (AOF) persistence, use flash-based storage
for the persistent volume.

title: Ephemeral storage

text:
Ephemeral storage is optional. If configured, temporary information that does not need to be persisted is stored by the cluster in the ephemeral storage.
This improves performance and helps reduce the load on the persistent storage.

Ephemeral storage must be a locally attached volume on each node.

title: Disk size requirements

text:
For disk size requirements, see:

- [Hardware
    requirements]()
    for general guidelines regarding the ideal disk size for each type of
    storage.
- [Disk size requirements for extreme write
    scenarios]()
    for special considerations when dealing with a high rate of write
    commands.


title: Supported platforms

page_type: index


summary: Download a Redis Software installation package.

title: Content

text:
To download the installation package for any of the supported platforms:

1. Go to the [Redis download page](https://cloud.redis.io/#/rlec-downloads).
1. Sign in with your Redis credentials or create a new account.
1. In the **Downloads** section for Redis Software, select the installation package for your platform then select **Go**.

Before you install the Linux package or AWS AMI on an AWS EC2 instance,
review the [configuration requirements for AWS EC2 instances]().


title: Prepare to install Redis Software

summary: Prepare to install Redis Software.

title: Download a Redis Software installation package

summary: Make sure required ports are available.

title: Ensure port availability

title: Overview

text:
Before you install Redis Software:

- [Download an installation package]().

- [View installation questions]() and optionally prepare answers before installation.

- Review the [security considerations]() for your deployment.

- Check that you have root-level access to each node, either directly or with `sudo`.

- Check that all [required ports are available]().

- [Turn off Linux swap]() on all cluster nodes.

- If you require the `redislabs` UID (user ID) and GID (group ID) numbers to be the same on all the nodes, create the `redislabs` user and group with the required numbers on each node.

- If you want to use Auto Tiering for your databases, see [Auto Tiering installation]().

title: Next steps

text:
- View [installation script options]() before starting the installation.

- [Install Redis Software]().


title: Ensure port availability

summary: Make sure required ports are available.

title: Overview

text: Before [installing Redis Software](), make sure all required ports are available.

title: Update `sysctl.conf` to avoid port collisions

title: OS conflicts with port 53


title: Redis Software product lifecycle

title: Overview

text:
The Redis Software product lifecycle fully reflects the [subscription agreement](https://redis.io/legal/software-agreement/).
However, for any discrepancy between the two policies, the subscription agreement prevails.

Redis Software modules follow the [modules lifecycle]().

title: Redis Software cluster version lifecycle

text: This section describes the lifecycle policy for Redis Software cluster versions.

title: Cluster version release numbers

text:
Redis Software uses a four-place numbering scheme to designate released cluster versions.
The format is "Major1.Major2.Minor-Build".

- Major sections of the version number represents fundamental changes and additions in
    capabilities to Redis Software. The Major1 and Major2 part of the
    version number are incremented based on the size and scale of the changes in each
    release.
- The Minor section of the version number represents quality improvements, fixes to
    existing capabilities, and new capabilities which are typically minor, feature-flagged, or optional.
- Build number is incremented with any changes to the product. Build number is
    incremented with each build when any change is made to the binaries.

Redis Software typically gets two major releases every year but the product shipping cycles may vary.
Maintenance releases, typically available on the last minor release of the current major1.major2 release are typically made available on a monthly cadence, although cycles may vary.

title: Cluster version end-of-life schedule {#endoflife-schedule}

text:
For Redis Software cluster versions 6.2 and later, the end-of-life (EOL) for each major release occurs 24 months after the formal release of the subsequent major version. Monthly maintenance will be provided on the last minor release of the major1.major2 releases.
This update to the EOL policy allows a lead time of at least 24 months to upgrade to the new cluster version after it is available.

| Version - Release date | End of Life (EOL)  |
| ----------------------------------------- | ------------------ |
| 8.0 – October 2025				        | - |
| 7.22 – May 2025				            | October 30, 2027 |
| 7.8 – November 2024				        | May 30, 2027 |
| 7.4 – February 2024				        | November 30, 2026 |
| 7.2 – August 2023				            | February 28, 2026 |
| 6.4 – February 2023						| August 31, 2025 |
| 6.2 – August 2021                         | February 28, 2025  |
| 6.0 – May 2020                            | May 31, 2022  |
| 5.6 – April 2020                          | October 31, 2021  |
| 5.4 – December 2018                       | December 31, 2020  |
| 5.2 – June 2018                           | December 31, 2019  |

The following timeline chart visualizes the Redis Software product lifecycle, showing release dates and end-of-life dates for each major version:

[code example]

title: Supported cluster version upgrade paths

role: compatibility

text:
For detailed upgrade instructions, see [Upgrade a Redis Software cluster]().

Redis Enterprise for Kubernetes has its own support lifecycle, which accounts for the Kubernetes distribution lifecycle. For details, see [Supported Kubernetes distributions]().

language: timeline {title="Redis Software product lifecycle"}


title: Docker quickstart for Redis Software

summary: Set up a development or test deployment of Redis Software using Docker.

title: Overview

text:
Docker containers are currently only supported for development and test environments, not for production. Use [Redis Enterprise on Kubernetes]() for a supported containerized deployment.

For testing purposes, you can run Redis Software on Docker containers on
Linux, Windows, or MacOS.
The [Redis Software container](https://hub.docker.com/r/redislabs/redis/)
acts as a node in a cluster.

To get started with a single Redis Software container:

1. [Install Docker](#install-docker) for your operating system

2. [Run the Redis Software Docker container](#run-the-container)

3. [Set up a cluster](#set-up-a-cluster)

4. [Create a new database](#create-a-database)

5. [Connect to your database](#connect-to-your-database)

title: Install Docker

text:
Follow the Docker installation instructions for your operating system:

- [Linux](https://docs.docker.com/install/#supported-platforms)
- [MacOS](https://docs.docker.com/docker-for-mac/install/)
- [Windows](https://store.docker.com/editions/community/docker-ce-desktop-windows)

title: Run the container

text:
To download and start the Redis Software Docker container, run the following
[`docker run`](https://docs.docker.com/engine/reference/commandline/run/) command in the terminal or command line for your operating system.

On Windows, make sure Docker is configured to run Linux-based containers.

[code example]

The example command runs the Docker container with Redis Software on `localhost` and opens the following ports:

- Port 8443 for HTTPS connections

- Port 9443 for [REST API]() connections

- Port 12000 configured Redis database port allowing client connections

You can publish other [ports]()
with `-p <host_port>:<container_port>` or use the `--network host` option to open all ports to the host network.

title: Set up a cluster

title: Create a database

title: Connect to your database

text: After you create the Redis database, you can connect to it to begin storing data.

title: Use redis-cli inside Docker {#connect-inside-docker}

text:
Every installation of Redis Software includes the command-line tool [`redis-cli`]() to interact with your Redis database. You can use `redis-cli` to connect to your database from within the same Docker network.

Use [`docker exec`](https://docs.docker.com/engine/reference/commandline/exec/) to start an interactive `redis-cli` session in the running Redis Software container:

[code example]

To find the container name or ID, use [`docker ps`](https://docs.docker.com/reference/cli/docker/container/ls/) to list running containers.

title: Connect from the host environment {#connect-outside-docker}

text: The database you created uses port `12000`, which is also mapped from the Docker container back to the host environment. This lets you use any method you have available locally to [connect to a Redis database](). Use `localhost` as the `host` and `12000` as the port.

title: Test different topologies

text:
Docker containers are currently only supported for development and test environments, not for production. Use [Redis Enterprise on Kubernetes]() for a supported containerized deployment.

When deploying Redis Software using Docker for testing, several common topologies are available, according to your requirements:

- [Single-node cluster](#single-node) – For local development or functional testing

- [Multi-node cluster on a single host](#multi-node-one-host) – For a small-scale deployment that is similar to production

- [Multi-node cluster with multiple hosts](#multi-node-multi-host) – For more predictable performance or high availability compared to single-host deployments

title: Single node {#single-node}

text:
The simplest topology is to run a single-node Redis Software cluster with a single container on a single host machine. You can use this topology for local development or functional testing.

Single-node clusters have limited functionality. For example, Redis Software can't use replication or protect against failures if the cluster has only one node.

title: Multiple nodes on one host {#multi-node-one-host}

text:
You can create a multi-node Redis Software cluster by deploying multiple containers to a single host machine. The resulting cluster is scale minimized but similar to production deployments.

However, this will also have several limitations.  For example, you cannot map the same port on multiple containers on the same host.

title: Multiple nodes and hosts {#multi-node-multi-host}

text:
You can create a multi-node Redis Software cluster with multiple containers by deploying each container to a different host machine.

This topology minimizes interference between containers, allowing for the testing of more Redis Software features.

code: docker run -d --cap-add sys_resource --name RE -p 8443:8443 -p 9443:9443 -p 12000:12000 redislabs/redis

section_id: run-the-container

code:
$ docker exec -it <container_name_or_ID> redis-cli -h <host_or_IP> -p <port>
127.0.0.1:12000> SET key1 123
OK
127.0.0.1:12000> GET key1
"123"


title: Redis Software quickstarts

summary: Set up a test deployment of Redis Software for Linux.

title: Redis Software quickstart

title: Docker quickstart for Redis Software

title: Content

text:
Try out Redis Software using one of the following quickstarts:

- [Redis Software quickstart]()

- [Docker quickstart for Redis Software]()

Additional quickstart guides are available to help you:

- Set up a [Redis Flex or Auto Tiering cluster]() to optimize  memory resources.

- Set up an [Active-Active cluster]() to enable high availability.

- [Benchmark]() Redis Software performance.


title: Redis Software quickstart

title: Overview

text:
This guide helps you install Redis Software on a Linux host to test its capabilities.

When finished, you'll have a simple cluster with a single node:

1. [Ensure port availability](#ensure-port-availability)

1. [Install Redis Software](#install-redis-enterprise-software)

1. [Set up a Redis Software cluster](#set-up-a-cluster)

1. [Create a new Redis database](#create-a-database)

1. [Connect to your Redis database](#connect-to-your-database)

**This quickstart is designed for local testing only.**
For production environments, see the [install and setup]() guide for deployment options and instructions.

title: Ensure port availability

title: OS conflicts with port 53

title: Configuration for AWS and GCP

text:
For detailed configuration instructions, see your cloud provider's documentation.

1. Create a VPC that you can use with regional subnets.

1. Within this VPC, create firewall rules that allow external and internal access for Redis Software.

| Ingress/Egress   | Source                                             | Protocol  | Ports                                    | Other protocols  |
|------------------|----------------------------------------------------|-----------|------------------------------------------|------------------|
| Ingress          | 0.0.0.0/0                                          | TCP       | 21, 22, 53, 8001, 8443, 9443, 8070, <nobr>10000-19999</nobr> | ICMP             |
| Ingress          | 0.0.0.0/0                                          | UDP       | 53, 5353                                  |                  |
| Ingress          | 10.0.0.0/8  (if subnets use 10. ranges) | all       | all                                      |                  |

title: Install Redis Software

text:
To install Redis Software:

1. Download the installation files from the [Redis Software Download Center](https://redis.io/downloads/#Redis_Software)
and copy the download package to a machine with a Linux-based OS.

You are required to create a free account to access the download center.

1. Extract the installation files:

    [code example]

1. Run the `install.sh` script in the current directory:

    [code example]

title: Set up a cluster

text: To set up your machine as a Redis Software cluster:

title: Create a database

title: Connect to your database

text:
After you create the Redis database, you can connect to it and store data.
See [Test client connection]() for connection options and examples.

title: Supported web browsers

text:
To use the Redis Software Cluster Manager UI, you need a modern browser with JavaScript enabled.

The Cluster Manager UI is officially supported for the latest version of [Google Chrome](https://www.google.com/chrome/), as well as the three previous and three subsequent versions.

title: Continue learning with Redis University

code: tar vxf <downloaded tar file name>

section_id: install-redis-software

code: sudo ./install.sh -y


title: Uninstall Redis Software

title: Overview

text:
Use the script `rl_uninstall.sh` to uninstall Redis Software and remove its files from a node. The script also deletes all Redis data and configuration from the node.

The uninstall script does not remove the node from the cluster, but the node's status changes to down. For node removal instructions, see [Remove a cluster node]().

title: Uninstall Redis Software

text:
To uninstall Redis Software from a cluster node:

1. Navigate to the script's location, which is in `/opt/redislabs/bin/` by default.

1. Run the uninstall script as the root user:

    [code example]

When you run the uninstall script on a node, it only uninstalls Redis Software from that node. To uninstall Redis Software for the entire cluster, run the uninstall script on each cluster node.

code: sudo ./rl_uninstall.sh

section_id: uninstall-redis-software


title: Upgrade an existing Redis Software deployment

summary: Upgrade a cluster to a later version of Redis Software.

title: Upgrade a Redis Software cluster

summary: Upgrade a Redis Software database.

title: Upgrade a Redis Software database

summary: How to upgrade an Active-Active database.

title: Upgrade an Active-Active database

summary: Upgrade a Redis Software cluster's operating system to a later major version.

title: Upgrade a cluster's operating system

title: Upgrade Redis Software

text:
To upgrade Redis Software:

1. Verify appropriate [network ports]() are either open or used by Redis Software.

1. Complete all [prerequisites]() before starting the upgrade.

1. Upgrade the software on all nodes of the cluster using one of the following methods:

    - [In-place upgrade]() - Directly upgrade Redis Software on each node in the cluster. Although this method is simpler than the rolling upgrade method, it might cause brief service interruptions as each node is upgraded.

    - [Rolling upgrade]() - Minimize downtime by adding new nodes with an updated Redis Software version to the cluster, one at a time, while keeping the rest of the cluster operational. This method is recommended for production environments that require continuous availability.

title: Upgrade Redis database

text: [Upgrade each database]() in the cluster or [upgrade an Active-Active database]() to enable new features and important fixes.

title: Upgrade operating system

text:
To upgrade the cluster's operating system:

1. Complete all [prerequisites]()  before starting the upgrade.

2. Use one of the following rolling upgrade methods:

    - [Extra node method]() - Recommended if you have additional resources available.

    - [Replace node method]() - Recommended if you cannot temporarily allocate additional resources.


title: Upgrade an Active-Active database

title: Upgrade an Active-Active database

text:
To upgrade an [Active-Active (CRDB) database]():

1. [Upgrade Redis Software]() on each node in the clusters where the Active-Active instances are located.

1. [Check the status](#check-database-status) of all Active-Active database instances.

1. [Upgrade all Active-Active database instances](#upgrade-database-instances) to a later version of Redis.

1. If the status indicates `OLD CRDB FEATURESET VERSION`, [upgrade the featureset version](#upgrade-featureset-version). See [Feature version guidelines](#feature-version-guidelines) for more information.

1. If your Active-Active database uses modules, [update module information](#update-module-information). To check if your database uses modules, run [`rladmin status modules`]():

    [code example]

title: Check database status

text:
To check the status of an Active-Active database instance, run [`rladmin status`]():

[code example]

The statuses of the Active-Active instances on the node can indicate:

- `OLD REDIS VERSION`: The database instance is running a Redis version that is outdated or not fully compatible with the current Redis Software cluster version. You should [upgrade the database](#upgrade-database-instances) to a later version of Redis bundled with the cluster's current Redis Software version.

- `OLD CRDB PROTOCOL VERSION`: This instance uses an older CRDB protocol. Redis Software versions 5.4.2 and later use CRDB protocol version 1. You can upgrade the CRDB protocol version when you [upgrade the Active-Active database instances](#upgrade-database-instances). See [CRDB protocol version guidelines](#crdb-protocol-version-guidelines) for more information.

- `OLD CRDB FEATURESET VERSION`: The database feature set version is outdated. After all [Active-Active database instances are upgraded](#upgrade-database-instances), [upgrade the feature set version](#upgrade-featureset-version). See [Feature version guidelines](#feature-version-guidelines) for more information.

title: Upgrade database instances

text:
For each Active-Active database instance:

1. Upgrade the Redis database version and enabled modules with [`rladmin upgrade db`]():

    [code example]

1. If the CRDB protocol version is old, read the warning message carefully and confirm that you want to update the CRDB protocol. See [CRDB protocol version guidelines](#crdb-protocol-version-guidelines) for more information.

    After confirmation, the Active-Active instance will use the new Redis version and CRDB protocol version.

You can use the `keep_crdt_protocol_version` option to upgrade the database version without upgrading the CRDB protocol version. However, you must upgrade the CRDB protocol before you update the CRDB feature set version.

If you use `keep_crdt_protocol_version`, make sure that you upgrade the CRDB protocol soon after with the [`rladmin upgrade db`]() command.

title: CRDB protocol version guidelines

text:
Redis Software versions 5.4.2 and later use CRDB protocol version 1 to help support Active-Active features.

CRDB protocol version 1 is backward compatible, which means Redis Software v5.4.2 CRDB instances can understand write operations from instances using the earlier CRDB protocol version 0.

After you upgrade one instance's CRDB protocol to version 1:

- Any instances that use CRDB protocol version 1 can receive updates from both version 1 and version 0 instances.

- However, instances that still use CRDB protocol version 0 cannot receive write updates from version 1 instances.

- After you upgrade an instance from CRDB protocol version 0 to version 1, it automatically receives any missing write operations.

Follow these upgrade 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 perform global operations on the CRDB, such as removing instances and adding new instances.

- As of v6.0.20, protocol version 0 is deprecated and support will be removed in a future version.

- To avoid upgrade failures, update all Active-Active databases to protocol version 1 _before_ upgrading Redis Software to v6.0.20 or later.

title: Upgrade featureset version

text:
If the feature set version is old, as indicated by the `OLD CRDB FEATURESET VERSION` status:

1. [Upgrade all Active-Active database instances](#upgrade-database-instances) and make sure the CRDB protocol is not outdated.

1. Find the `<CRDB-GUID>` of your Active-Active database.

    You can use the [`crdb-cli crdb list`]() command:

    [code example]

    Look for the fully qualified domain name (`CLUSTER-FQDN`) of your cluster and use the associated `GUID`:

    [code example]

1. Update the feature set for each Active-Active database. See [Feature version guidelines](#feature-version-guidelines) for more information.

    [code example]

title: Feature version guidelines

text:
Starting with version 5.6.0, a new feature version (also called a _feature set version_) helps support new Active-Active features.

The featureset version is an internal version of the Active-Active feature that enables new capabilities and improvements across participating Active-Active clusters. When you update the feature version for an Active-Active database, the feature version is updated for all database instances.

Follow these upgrade guidelines:

- As of v6.0.20, feature version 0 is deprecated and support will be removed in a future version.

- To avoid upgrade failures, make sure all your Active-Active databases are configured with the latest feature set version before upgrading to Redis Software 6.0.20 or later.

title: Update module information

text:
If your Active-Active database uses modules:

1. Update module information in the CRDB configuration using the following command syntax:

    [code example]

1. `crdb-cli` will ask you to verify all Active-Active database instances and their modules have been updated before you enter `y` to continue:

    [code example]

code: rladmin status modules db { db:<ID> | <database-name> }

section_id: upgrade-an-active-active-database

code: rladmin status

section_id: check-database-status

code: rladmin upgrade db { db:<ID> | <database-name> }

section_id: upgrade-database-instances

code: crdb-cli crdb list

section_id: upgrade-featureset-version

code:
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

code: crdb-cli crdb update --crdb-guid <CRDB-GUID> --featureset-version yes

code: crdb-cli crdb update --crdb-guid <CRDB-GUID> --update-db-config-modules true

section_id: update-module-information

code:
Verify that all CRDB database instances and their modules have been updated.
    Do you want to continue? (y/n): y


title: Upgrade a Redis Software cluster

title: Overview

text:
Before you upgrade a cluster to a later Redis Software version, review the [supported upgrade paths](#supported-upgrade-paths) and [prerequisites](#upgrade-prerequisites).

To upgrade a cluster's Redis Software version, use one of the following methods:

- [In-place upgrade](#in-place-upgrade) - Directly upgrade Redis Software on each node in the cluster. Although this method is simpler than the rolling upgrade method, it might cause brief service interruptions as each node is upgraded.

- [Rolling upgrade](#rolling-upgrade) - Minimize downtime by adding new nodes with an updated Redis Software version to the cluster, one at a time, while keeping the rest of the cluster operational. This method is recommended for production environments that require continuous availability.

title: Supported upgrade paths

text:
See the [Redis Software product lifecycle]() for more information about release numbers and the end-of-life schedule.

Redis Enterprise for Kubernetes has its own support lifecycle, which accounts for the Kubernetes distribution lifecycle. For details, see [Supported Kubernetes distributions]().

title: Upgrade prerequisites

text:
Before upgrading a cluster:

- Verify access to [rlcheck]() and [rladmin]() commands.

- Run [rlcheck]() on each node and verify there are no issues:

    [code example]

- Verify [maintenance mode]() is not enabled:

    1. On a node in the cluster, run [`rladmin status`]():

        [code example]

    1. Review each node's `SHARDS` field. If the value is yellow, the node is in maintenance mode.

    1. To deactivate maintenance mode on a node, run the following [`rladmin node maintenance_mode off`]() command. See [Deactivate maintenance mode]() for additional details.

        [code example]

- Verify that you meet the upgrade path requirements for the target cluster version and review the relevant [release notes]() for any preparation instructions.

- Before you upgrade a cluster from Redis Software version 6.2.x to 7.8.x, you must follow these steps if the cluster has any databases with Redis version 6.0:

    1. Set the Redis upgrade policy to `latest`:

        [code example]

    1. [Upgrade Redis 6.0 databases]() to Redis 6.2.

- [Upgrade your databases]() to a version that is supported by the target Redis Software version before upgrading the cluster. We recommend you upgrade the databases to the latest supported version if possible. Make sure to test the upgrade in a non-production environment to determine any impact.

- Avoid changing the database configuration or performing other cluster management operations during the cluster upgrade process, as this might cause unexpected results.

- Upgrade the cluster's primary (master) node first. To identify the primary node, use one of the following methods:

    - **Nodes** screen in the new Cluster Manager UI (only available for Redis Software versions 7.2 and later)

    - [`rladmin status nodes`]() command

    - [`GET /nodes/status`]() REST API request

title: In-place upgrade

text:
Starting with the primary node, follow these steps for every node in the cluster. To ensure cluster availability, upgrade each node separately.

1. Complete all [prerequisites](#upgrade-prerequisites) before starting the upgrade.

1.  Verify node operation with the following commands:

    [code example]

Do not proceed if any shard, node, or endpoint is not `OK`.

1.  Download the Redis Software installation package to the machine running the node from the Download Center on [https://cloud.redis.io](https://cloud.redis.io).

1.  Extract the installation package:

    [code example]

You cannot change the installation path or the user during the upgrade.

1.  Run the install command. See [installation script options]() for a list of command-line options you can add to the following command. You cannot use options marked as "new installs only" during an in-place upgrade.

    [code example]

    The installation script automatically recognizes the upgrade and responds accordingly.

    The upgrade replaces all node processes, which might briefly interrupt any active connections.

1.  Verify the node was upgraded to the new version and is still operational:

    [code example]

1.  Visit the Cluster Manager UI.

    If the Cluster Manager UI was open in a web browser during the upgrade, refresh the browser to reload the console.

title: Rolling upgrade

text:
To perform a rolling upgrade of the cluster, use one of the following methods:

- [Extra node method](#extra-node-upgrade) - recommended if you have additional resources available

- [Replace node method](#replace-node-upgrade) - recommended if you cannot temporarily allocate additional resources

title: Extra node upgrade method {#extra-node-upgrade}

text:
1. Complete all [prerequisites](#upgrade-prerequisites) before starting the rolling upgrade.

1. [Install a later version of Redis Software]() on a new node.

1. [Add the new node]() to the cluster.

1. If the [cluster uses DNS](), add the new node’s IP address to the DNS records.

1. [Promote the first new node]() to become the primary node.

1. [Remove one node]() running the earlier Redis Software version from the cluster.

1. Repeat the previous steps until all nodes with the earlier Redis Software version are removed. If the final node to remove from the cluster is the primary node, [demote it]() to a secondary node before you remove it.

title: Replace node upgrade method {#replace-node-upgrade}

text:
1. Complete all [prerequisites](#upgrade-prerequisites) before starting the rolling upgrade.

1. [Remove a node]() with the earlier Redis Software version from the cluster.

1. Uninstall Redis Software from the removed node:

    [code example]

1. [Install a later version of Redis Software]() on the removed node or a new node.

1. [Add the new node]() to the cluster.

    If you want to reuse the removed node's ID when you add the node to the cluster, run [`rladmin cluster join`]() with the `replace_node` flag:

    [code example]

1. If the [cluster uses DNS](), add the new node’s IP address to the DNS records.

1. [Promote the first new node]() to become the primary node.

1. Verify node health:

    1. Run `rlcheck` on all nodes:

        [code example]

        The output lists the result of each verification test:

        [code example]

        For healthy nodes, the expected output is `ALL TESTS PASSED`.

    1. Run [`rladmin status`]() on the new node:

        [code example]

        The expected output is the `OK` status for the cluster, nodes, endpoints, and shards:

        [code example]

1. Repeat the previous steps until all nodes with the earlier Redis Software version are replaced. If the final node to remove from the cluster is the primary node, [demote it]() to a secondary node before you remove it.

title: After cluster upgrade

text:
After all nodes are upgraded, the cluster is fully upgraded. Certain features introduced in the new version of Redis Software only become available after upgrading the entire cluster.

After upgrading from version 6.0.x to 6.2.x, restart `cnm_exec` on each cluster node to enable more advanced state machine handling capabilities:

[code example]

code: rlcheck

section_id: upgrade-prerequisites

code: rladmin node <node_id> maintenance_mode off

code: rladmin tune cluster redis_upgrade_policy latest

code:
$ rlcheck
    $ rladmin status extra all

section_id: in-place-upgrade

code: tar vxf <tarfile name>

code: sudo ./install.sh

code: rladmin cluster join nodes <cluster_member_ip_address> username <username> password <password> replace_node <node_id>

code:
##### Welcome to Redis Software Cluster settings verification utility ####
        Running test: verify_bootstrap_status
		                PASS
        ...
        Running test: verify_encrypted_gossip
		                PASS
        Summary:
        -------
        ALL TESTS PASSED.

code: rladmin status extra all

code:
CLUSTER:
        OK. Cluster master: 2 (<IP.address>)
        Cluster health: OK, [0, 0.0, 0.0]
        failures/minute - avg1 0.00, avg15 0.00, avg60 0.00.
        ...

code: supervisorctl restart cnm_exec

section_id: after-cluster-upgrade


title: Upgrade a Redis Software database

summary: Upgrade a Redis Software database.

title: Default Redis database versions {#default-db-versions}

text:
When you upgrade an existing database, it uses the latest bundled Redis version unless you specify a different version with the `redis_version` option in the [REST API]() or [`rladmin upgrade db`]().

To view available Redis database versions:

- In the Cluster Manager UI, see **Redis database versions** on the **Cluster > Configuration** screen.

- Send a [`GET /nodes` REST API request]() and see `supported_database_versions` in the response.

The default Redis database version differs between Redis Software releases as follows:

| Redis
Software | Bundled Redis
DB versions | Default DB version
(upgraded/new databases) |
|-------|----------|-----|
| 8.0.10 | 6.2, 7.2, 7.4, 8.0, 8.2, 8.4 | 8.4 |
| 8.0.6 | 6.2, 7.2, 7.4, 8.0, 8.2 | 8.2 |
| 8.0.2 | 6.2, 7.2, 7.4, 8.0, 8.2 | 8.2 |
| 7.22.x | 6.2, 7.2, 7.4 | 7.4 |
| 7.8.x | 6.2, 7.2, 7.4 | 7.4 |
| 7.4.x | 6.0, 6.2, 7.2 | 7.2 |
| 7.2.4 | 6.0, 6.2, 7.2 | 7.2 |
| 6.4.2 | 6.0, 6.2 | 6.2 |
| 6.2.x | 6.0, 6.2 | 6.0 |

title: Upgrade prerequisites

text:
Before upgrading a database:

- Review the relevant [release notes]() for any preparation instructions.

- Verify that both the [current database version and the target database version are supported](#db-versions-table) by the cluster's Redis Software version.

    To determine the current database version:

    - Use the Cluster Manager UI to open the **Configuration** tab for the database and select  **About**.

    - _(Optional)_ Use the [`rladmin status extra all`]() command to display configuration details:

        [code example]

        When the database compatibility version is outdated, <nobr>`OLD REDIS VERSION`</nobr> appears in the command output.

- Verify the cluster is fully upgraded and operational.

    Use the Cluster Manager UI to display the **Configuration** tab for the cluster. The tab displays the cluster version information and the Redis database compatibility version.

- Check client compatibility with the database version.

    If you run Redis Stack commands with Go-Redis versions 9 and later or Lettuce versions 6 and later, set the client’s protocol version to RESP2 before upgrading your database to Redis version 7.2 to prevent potential application issues due to RESP3 breaking changes. See [Client prerequisites for Redis 7.2 upgrade]() for more details and examples.

- To avoid data loss during the upgrade, [back up your 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 primary (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.

title: Upgrade database

text:
To upgrade a database:

**Cluster Manager UI:**

1. Complete all [prerequisites](#upgrade-prerequisites) before starting the upgrade.

1. Optionally, back up the database to minimize the risk of data loss.

1. Upgrade the database and its modules from the **Databases** screen or an individual database's **Configuration** screen in the Cluster Manager UI. During the upgrade process, the database will restart without losing any data.

    To upgrade a database from the **Databases** screen:

    1. Expand the database in the **Databases** list to show details.

    1. Click **Upgrade**.

    1. For **Select version**, choose the Redis version for the database upgrade from the list.

    1. Click **Upgrade**.

    1. After the upgrade process finishes, check the expanded database details to verify that the Redis version is set to the expected value.

    To upgrade a database from its **Configuration** screen:

    1. Select the database from the **Databases** list and go to its **Configuration** screen.

    1. Click the **More actions** button (**⋮**).

    1. Select **Upgrade version** from the list.

    1. For **Select version**, choose the Redis version for the database upgrade from the list.

    1. Click **Upgrade**.

    1. After the upgrade process finishes, click the **About** button (ⓘ) and verify that the Redis version is set to the expected value.

**rladmin:**

1. Complete all [prerequisites](#upgrade-prerequisites) before starting the upgrade.

1. Optionally, back up the database to minimize the risk of data loss.

1. Upgrade the database using [`rladmin upgrade db`](). During the upgrade process, the database will restart without losing any data. Use the `preserve_roles` option to keep the database's current state, including primary shard placement, and prevent the cluster from becoming unbalanced.

    To upgrade a database and its modules:

    [code example]

    Example of a successful upgrade:

    [code example]

    To upgrade the database to a version other than the default version, use the `redis_version` parameter:

    [code example]

1. 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.

    [code example]

code: rladmin upgrade db <database name | database ID> preserve_roles

section_id: upgrade-database

code:
rladmin> upgrade db demo
    Monitoring d194c4a3-631c-4726-b799-331b399fc85c
    active - SMUpgradeBDB init
    active - SMUpgradeBDB wait_for_version
    active - SMUpgradeBDB configure_shards
    completed - SMUpgradeBDB
    Done

code: rladmin upgrade db <database name | database ID> redis_version <version> preserve_roles

code: rladmin status databases extra all


title: Upgrade a cluster's operating system

title: Overview

text: To upgrade the operating system (OS) on a Redis Software cluster to a later major version, perform a rolling upgrade. Because you upgrade one node at a time, you can upgrade your cluster's OS without downtime.

title: Prerequisites

text:
Before you upgrade a cluster's operating system:

1. [Upgrade all nodes in the cluster]() to a Redis Software version that supports the OS's current version and upgrade version.

    To learn which versions of Redis Software support specific OS versions, see [Supported platforms]().

1. If the cluster uses custom directories, make sure the OS upgrade version also supports custom directories, and specify the same custom directories during installation for all nodes. See [Customize installation directories]() for details.

title: Perform OS rolling upgrade

text:
To upgrade the cluster's operating system, use one of the following rolling upgrade methods:

- [Extra node method](#extra-node-upgrade) - recommended if you have additional resources available

- [Replace node method](#replace-node-upgrade) - recommended if you cannot temporarily allocate additional resources

text:
1. Complete all [prerequisites](#prerequisites) before starting the rolling upgrade.

1. Create a node with the OS upgrade version.

1. [Install the cluster's current Redis Software version]() on the new node using the installation package for the OS upgrade version.

1. [Add the new node]()  to the cluster.

1. If the [cluster uses DNS](), add the new node’s IP address to the DNS records.

1. [Remove one node]() running the earlier OS version from the cluster.

1. Repeat the previous steps until all nodes with the earlier OS version are removed. If the final node to remove from the cluster is the primary node, [demote it]() to a secondary node before you remove it.

text:
1. Complete all [prerequisites](#prerequisites) before starting the rolling upgrade.

1. [Remove a node]() with the earlier OS version from the cluster.

1. Uninstall Redis Software from the removed node:

    [code example]

1. Either upgrade the existing node to the OS upgrade version, or create a new node with the OS upgrade version.

1. [Install the cluster's current Redis Software version]() on the upgraded node using the installation package for the OS upgrade version.

1. [Add the new node]() to the cluster.

    If you want to reuse the removed node's ID when you add the node to the cluster, run [`rladmin cluster join`]() with the `replace_node` flag:

    [code example]

1. If the [cluster uses DNS](), add the new node’s IP address to the DNS records.

1. Verify node health:

    1. Run `rlcheck` on all nodes:

        [code example]

        The output lists the result of each verification test:

        [code example]

        For healthy nodes, the expected output is `ALL TESTS PASSED`.

    1. Run [`rladmin status`]() on the new node:

        [code example]

        The expected output is the `OK` status for the cluster, nodes, endpoints, and shards:

        [code example]

1. Repeat the previous steps until all nodes with the earlier OS version are replaced. If the final node to remove from the cluster is the primary node, [demote it]() to a secondary node before you remove it.

code: sudo ./rl_uninstall.sh

code:
##### Welcome to Redis Enterprise Cluster settings verification utility ####
        Running test: verify_bootstrap_status
		                PASS
        ...
        Running test: verify_encrypted_gossip
		                PASS
        Summary:
        -------
        ALL TESTS PASSED.


title: Check database availability for monitoring and load balancers

summary: Verify if a Redis Software database is available to perform read and write operations and can respond to queries from client applications.

title: Overview

text:
You can use the [database availability API]() to verify whether a Redis Software database is available to perform read and write operations and can respond to queries from client applications. Load balancers and automated monitoring tools can use this API to monitor database availability.

Database availability does not guarantee data availability.

text:
To monitor database availability, use the following REST API request:

[code example]

If the OSS Cluster API is enabled, this request verifies all endpoints for this database are available. Otherwise, it verifies the database has at least one available endpoint.

Returns the status code 200 OK if the database is available.

If the database is unavailable, returns an error status code and a JSON object that contains [`error_code` and `description` fields]().

title: Check local database endpoint availability for load balancers

text:
To check database availability when using a load balancer and the recommended `all-nodes` proxy policy, use the local database endpoints for each node:

[code example]

Returns HTTP status code 200 OK if all primary (master) shards are reachable from the local database endpoint.

If the local database endpoint is unavailable, returns an error status code and a JSON object that contains [`error_code` and `description` fields]().

title: Use lag-aware availability checks for disaster recovery {#lag-aware}

text: The database availability API supports lag-aware availability checks that consider replication lag tolerance. You can reduce the risk of data inconsistencies during disaster recovery by incorporating lag-aware availability checks into your disaster recovery solution and ensuring failover-failback flows only occur when databases are accessible and sufficiently synchronized.

title: Change default availability lag tolerance threshold

text:
The lag tolerance threshold is 100 milliseconds by default. Depending on factors such as workload, network conditions, and throughput, you might want to adjust the lag tolerance threshold.

To change the default threshold for the entire cluster, set `availability_lag_tolerance_ms` with an [update cluster]() request:

[code example]

title: Lag-aware database availability checks

text:
To perform a lag-aware database availability check using the cluster's default lag tolerance threshold:

[code example]

To perform a lag-aware database availability check and override the cluster's default lag tolerance threshold:

[code example]

title: Lag-aware endpoint availability checks

text:
To perform a lag-aware database endpoint availability check using the cluster's default lag tolerance threshold:

[code example]

To perform a lag-aware database endpoint availability check and override the cluster's default lag tolerance threshold:

[code example]

title: Availability by database status

text:
The following table shows the relationship between a database's status and availability. For more details about the database status values, see [BDB status field]().

| Database status | Availability |
|-----------------|--------------|
| active          | ✅ Available |
| active-change-pending | ✅ Available |
| creation-failed | :x: Not available |
| delete-pending  | :warning: Availability not guaranteed |
| import-pending  | ✅ Available |
| pending         | ✅ Available |
| recovery        | :x: Not available |

title: Known issues

text: - RS155734: Endpoint availability metrics do not work as expected due to a calculation error.

code: GET /v1/bdbs/<database_id>/availability

code:
PUT /v1/cluster
{ "availability_lag_tolerance_ms": 100 }

section_id: lag-aware-database-availability-checks

section_id: lag-aware-endpoint-availability-checks


title: Get started with monitoring Redis Software

summary: Collect and visualize Redis Software metrics.

title: Overview

text:
You can use Prometheus and compatible integrations to collect and visualize your Redis Software metrics.

Metrics are exposed at the cluster, node, database, shard, and proxy levels.

- [Prometheus](https://prometheus.io/) is an open source systems monitoring and alerting toolkit that aggregates metrics from different sources.

You can use Prometheus integrations to:
- Collect and display metrics not available in the Cluster Manager UI

- Set up automatic alerts for all resources

- Display Redis Software metrics alongside data from other systems

title: Prometheus integrations

text:
You can integrate Redis Software with Prometheus and one of the following tools to collect and visualize your deployment's metrics:

- [Grafana]()

- [Datadog]()

- [Dynatrace]()

- [New Relic]()

title: Prometheus quick start

text:
To get started with Prometheus:

1. Create a directory called `prometheus` on your local machine.

1. Within that directory, create a configuration file called `prometheus.yml`.

1. Add the following contents to the configuration file and replace `<cluster_name>` with your Redis Software cluster's FQDN:

    **v2 (metrics stream engine):**

[code example]

**v1:**

[code example]

1. Set up your Prometheus server.

We recommend running Prometheus in Docker only for development and testing.

    To set up Prometheus on Docker:

    1. Create a _docker-compose.yml_ file:

        [code example]

    1. To start the containers, run:

        [code example]

    1. To check that all of the containers are up, run:

        [code example]

    1. In your browser, sign in to Prometheus at `http://localhost:9090` to make sure the server is running.

    1. Select **Status** and then **Targets** to check that Prometheus is collecting data from your Redis Software cluster.

        If Prometheus is connected to the cluster, you can type **node_up** in the Expression field on the Prometheus home page to see the cluster metrics.

1. Integrate Redis Software and your Prometheus server with one of the [compatible tools](#prometheus-integrations). For help, see the integration guide and official documentation for your chosen tool.

1. Add dashboards for cluster, database, node, and shard metrics.

code:
global:
  scrape_interval: 15s
  evaluation_interval: 15s

# Attach these labels to any time series or alerts when communicating with
# external systems (federation, remote storage, Alertmanager).
  external_labels:
    monitor: "prometheus-stack-monitor"

# Load and evaluate rules in this file every 'evaluation_interval' seconds.
#rule_files:
# - "first.rules"
# - "second.rules"

scrape_configs:
# scrape Prometheus itself
  - job_name: prometheus
    scrape_interval: 10s
    scrape_timeout: 5s
    static_configs:
      - targets: ["localhost:9090"]

# scrape Redis Software
  - job_name: redis-enterprise
    scrape_interval: 30s
    scrape_timeout: 30s
    metrics_path: /v2
    scheme: https
    tls_config:
      insecure_skip_verify: true
    static_configs:
      - targets: ["<cluster_name>:8070"]

section_id: prometheus-quick-start

code:
global:
  scrape_interval: 15s
  evaluation_interval: 15s

# Attach these labels to any time series or alerts when communicating with
# external systems (federation, remote storage, Alertmanager).
  external_labels:
    monitor: "prometheus-stack-monitor"

# Load and evaluate rules in this file every 'evaluation_interval' seconds.
#rule_files:
# - "first.rules"
# - "second.rules"

scrape_configs:
# scrape Prometheus itself
  - job_name: prometheus
    scrape_interval: 10s
    scrape_timeout: 5s
    static_configs:
      - targets: ["localhost:9090"]

# scrape Redis Software
  - job_name: redis-enterprise
    scrape_interval: 30s
    scrape_timeout: 30s
    metrics_path: /
    scheme: https
    tls_config:
      insecure_skip_verify: true
    static_configs:
      - targets: ["<cluster_name>:8070"]

code:
version: '3'
        services:
            prometheus-server:
                image: prom/prometheus
                ports:
                    - 9090:9090
                volumes:
                    - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml

code: $ docker compose up -d

code: docker ps


title: Consolidated health report

summary: View the consolidated health report to get a read-only snapshot of a Redis Software cluster's current system health.

title: Overview

text:
The consolidated health report is a read-only, consolidated snapshot of a cluster's current system health, including:

- License and certificate status

- Nodes and services health

- Node memory breakdown, including free and provisioned memory

- Running actions status

- Active alerts

- Basic database status and version

- High availability health

The consolidated health report consolidates cluster and database health information that was previously scattered across multiple APIs and CLI commands, such as [`rladmin status extra all`]() and required SSH access to view.

As of Redis Software version 8.0.16, you can access the cluster and database health reports using the [Cluster manager UI](#view-health-overview) or [REST API requests](#health-rest-api-requests).

title: View health overview {#view-health-overview}

text:
You can access the cluster and database health reports using the **Overview** screen in the Cluster Manager UI.

You can view node health

title: Cluster info

text:
The **Cluster Info** section provides basic cluster details, including:

- Overall cluster status

- Redis Software cluster version

- License usage and expiration date

title: Cluster storage

text: The **Cluster Storage** section provides memory usage details, including used memory, free memory, and total memory for RAM, flash, persistent storage, and ephemeral storage on the cluster.

title: Nodes

text: The **Nodes** section shows the status of nodes in the cluster and indicates which node is the leader or primary node.

title: Databases

text: In the **Databases** section, you can check each database's status and Redis version. You can click the number listed by each field to display the relevant database names and click on the database links to view database details.

title: Certificates

text: The **Certificates** section shows whether the cluster's certificates are still valid. If a certificate appears as no longer valid, you can click the **Certificates** link to update the certificate.

title: Actions

text: In the **Actions** section, you can view currently running actions.

title: Alerts and services

text: If a configured alert threshold is reached or a running service stops, an alert will appear in the **Alerts & Services** section.

title: View node health {#view-node-health}

text: On the **Nodes** screen of the Cluster Manager UI, you can click on a node to go to its **Node configuration** tab and view node health details.

title: Verify nodes

text:
You can check if nodes are functioning properly using one of the following methods:

**Verify all nodes:**

On the **Nodes** screen, click **Verify all nodes**.

**Verify specific node:**

1. On the **Nodes** screen, find the node you want verify in the list and click the **More actions** button (**⋮**).

1. Select **Verify node** from the list.

<img src="../../../../images/rs/screenshots/nodes/primary-node-more-actions-8-0.png" alt="Click the more actions button for a node to access node actions.">

title: Node storage

text: The **Node storage** section of the **Node configuration** tab provides memory usage details, including used memory, free memory, and total memory for RAM, flash, persistent storage, and ephemeral storage on the node.

title: Services

text: In the **Services** section **Node configuration** tab, you can view the list of services running on the node and the most recent status of each.

title: Shards

text: When viewing a node's configuration, you can click the **Shards** tab to view a list of database shards running on the node and related details such as each shard's ID, current status, role, and slot range.

title: Health report REST API requests {#health-rest-api-requests}

title: Cluster health report requests

text:
[Cluster health report]() REST API requests provide overall health information for a cluster:

[code example]

title: Database health report requests

text:
[Database health report]() REST API requests provide detailed health information for a specific database:

[code example]

section_id: cluster-health-report-requests

section_id: database-health-report-requests


title: Monitoring with metrics and alerts

summary: Use the metrics that measure the performance of your Redis Software clusters, nodes, databases, and shards to track the performance of your databases.

summary: Monitor Redis Software clusters and databases using internal monitoring systems and external monitoring tools.

title: Metrics and alerts for monitoring v1

summary: The new metrics engine for monitoring Redis Software.

title: Monitoring v2

summary: Using monitoring and observability with Redis Software

title: Redis Software observability and monitoring guidance

title: Consolidated health report

title: Overview

text:
You can use the metrics that measure the performance of your Redis Software clusters, nodes, databases, and shards
to monitor the performance of your databases.

title: View metrics and configure alerts

text:
In the Redis Software Cluster Manager UI, you can view metrics, configure alerts, and send notifications based on alert parameters. You can also access metrics and configure alerts through the REST API.

See [Metrics and alerts for monitoring v1]() for more information.

title: Metrics stream engine

text:
The new metrics stream engine is generally available as of [Redis Software version 8.0]() This new engine exposes the v2 Prometheus scraping endpoint at `https://<IP>:8070/v2`, exports all time-series metrics to external monitoring tools, and enables real-time monitoring.

See [Metrics stream engine for monitoring v2]() for more information.

title: Integrate with external monitoring tools

text:
To integrate Redis Software metrics into your monitoring environment, see the following integration guides:

- [Grafana]()

- [Datadog]()

- [Dynatrace]()

- [New Relic]()

For a detailed tutorial to deploy a complete monitoring stack with Prometheus and Grafana, see [Redis Software Observability with Prometheus and Grafana](https://redis.io/learn/operate/observability/redis-software-prometheus-and-grafana).

Filter [Libraries and tools]() by "observability" for additional tools and guides.

title: Metrics reference

text:
Make sure you read the [definition of each metric]()
so that you understand exactly what it represents.


title: Transition cluster manager alerts to Prometheus alerts

summary: Transition from internal cluster manager alerts to external monitoring alerts using Prometheus.

title: Content

text:
As Redis Software transitions from the [deprecated monitoring system]() to the [new metrics stream engine](), some internal cluster manager alerts were deprecated in favor of external monitoring solutions.

You can use the following table to transition from the deprecated alerts and set up equivalent alerts in Prometheus with [PromQL (Prometheus Query Language)](https://prometheus.io/docs/prometheus/latest/querying/basics/):


title: Monitoring v2

summary: Transition from v1 metrics to v2 PromQL equivalents.

title: Transition from Prometheus v1 to Prometheus v2

summary: V2 metrics available to Prometheus as of Redis Software version 7.8.2.

title: Prometheus metrics v2

title: Overview

text:
The new metrics stream engine is generally available as of [Redis Software version 8.0]().

The new metrics stream engine:

- Exposes the v2 Prometheus scraping endpoint at `https://<IP>:8070/v2`.

- Exports all time-series metrics to external monitoring tools such as Grafana, DataDog, NewRelic, and Dynatrace using Prometheus.

- Enables real-time monitoring, including full monitoring during maintenance operations, which provides full visibility into performance during events such as shards' failovers and scaling operations.

title: Prometheus metrics v2

text:
For a list of all available v2 metrics, see [Prometheus metrics v2]().

The v2 scraping endpoint also exposes metrics for `node_exporter` version 1.8.1. For more information, see the [Prometheus node_exporter GitHub repository](https://github.com/prometheus/node_exporter).

text:
If you are already using the existing scraping endpoint for integration, do the following to transition from v1 metrics to v2 metrics:

1. Change the `metrics_path` in your Prometheus configuration file from `/` to `/v2` to use the new scraping endpoint.

    Here's an example of the updated scraping configuration in `prometheus.yml`:

    [code example]

1. Use the metrics tables in [this guide]() to transition from v1 metrics to equivalent v2 PromQL.

It is possible to scrape both existing and new endpoints simultaneously, allowing advanced dashboard preparation and a smooth transition.

code:
scrape_configs:
      # Scrape Redis Software
      - job_name: redis-enterprise
        scrape_interval: 30s
        scrape_timeout: 30s
        metrics_path: /v2
        scheme: https
        tls_config:
          insecure_skip_verify: true
        static_configs:
          - targets: ["<cluster_name>:8070"]