title: Change database upgrade configuration

summary: Configure cluster-wide policies that affect default database upgrades.

title: Overview

text: Database upgrade configuration includes cluster-wide policies that affect default database upgrades.

title: Edit upgrade configuration

text:
To edit database upgrade configuration using the Cluster Manager UI:

1. On the **Databases** screen, select  to open a list of additional actions.

1. Select **Upgrade configuration**.

1. Change database [upgrade configuration settings](#upgrade-config-settings).

1. Select **Save**.

title: Upgrade configuration settings {#upgrade-config-settings}

title: Database shard parallel upgrade

text:
To change the number of shards upgraded in parallel during database upgrades, use one of the following methods:

- Cluster Manager UI – Edit **Database shard parallel upgrade** in [**Upgrade configuration**](#edit-upgrade-configuration)

- [rladmin tune cluster]():

    [code example]

- [Update cluster policy]() REST API request:

    [code example]

title: RESP3 support

text:
The cluster-wide option `resp3_default` determines the default value of the `resp3` option, which enables or deactivates RESP3 for a database, upon upgrading a database to version 7.2 or later. `resp3_default` is set to `enabled` by default.

To change `resp3_default` to `disabled`, use one of the following methods:

- Cluster Manager UI – Edit **RESP3 support** in [**Upgrade configuration**](#edit-upgrade-configuration)

- [rladmin tune cluster]():

    [code example]

- [Update cluster policy]() REST API request:

    [code example]

code: rladmin tune cluster parallel_shards_upgrade { all | <integer> }

section_id: database-shard-parallel-upgrade

code:
PUT /v1/cluster/policy
    { "parallel_shards_upgrade": <integer> }

code: rladmin tune cluster resp3_default { enabled | disabled }

code:
PUT /v1/cluster/policy
    { "resp3_default": <boolean> }


title: Configure database settings

summary: Configure settings specific to each database.

summary: Cluster-wide policies that determine default settings when creating new databases.

title: Configure database defaults

title: Change database upgrade configuration

summary: Manage tags for databases in a Redis Software cluster.

title: Manage database tags

title: Enable OSS Cluster API

summary: How to configure database persistence with either an append-only file (AOF) or snapshots.

title: Configure database persistence

title: Configure proxy policy

summary: Configure high availability for replica shards so that the cluster automatically migrates the replica shards to an available node.

summary: Configure shard placement to improve performance.

title: Configure shard placement

page_type: content

title: Overview

role: overview

text:
You can manage your Redis Software databases with several tools:

- [Cluster Manager UI](#edit-database-settings) (the web-based user interface)

- Command-line tools:

    - [`rladmin`]() for standalone database configuration

    - [`crdb-cli`]() for Active-Active database configuration

    - [`redis-cli`]() for Redis Open Source configuration

- [REST API]()

title: Edit database settings

role: content

text:
You can change the configuration of a Redis Software database at any time.<!--more-->

To edit the configuration of a database using the Cluster Manager UI:

1. On the **Databases** screen, select the database you want to edit.

1. From the **Configuration** tab, select **Edit**.

1. Change any [configurable database settings](#config-settings).

For [Active-Active database instances](), most database settings only apply to the instance that you are editing.

1. Select **Save**.

title: Configuration settings {#config-settings}

role: configuration

title: General

text:
- [**Tags**]() - Add custom tags to categorize the database.

- **Database version** - Select the Redis version when you create a database.

- **Database name** - The database name requirements are:

    - Maximum of 63 characters

    - Only letters, numbers, or hyphens (-) are valid characters

    - Must start and end with a letter or digit

    - Case-sensitive

- **Endpoint port number** - You can define the port number that clients use to connect to the database. Otherwise, a port is randomly selected.

You cannot change the [port number]()
after the database is created.

title: Capacity

text:
- **Memory limit** - [Database memory limits]() include all database replicas and shards, including replica shards in database replication and database shards in database clustering.

    If the total size of the database in the cluster reaches the memory limit, the memory eviction policy for the database is enforced.

- **RAM limit** - If you create a database with Auto Tiering enabled, you also need to set the RAM-to-Flash ratio. Minimum RAM is 10%. Maximum RAM is 50%.

- [**Memory eviction**]() - By default, when the total size of the database reaches its memory limit, the database evicts keys according to the least recently used keys out of all keys with an "expire" field set to make room for new keys. You can select a different eviction policy.

title: Capabilities

text:
When you create a new in-memory database, you can enable multiple Redis Stack [**Capabilities**]().

Databases created with or upgraded to Redis version 8 or later automatically enable the capabilities (modules) bundled with Redis Software as follows:

For Auto Tiering databases, you can enable capabilities that support Auto Tiering. See [Redis Software and Redis Stack feature compatibility
]() for compatibility details.

To use Redis Stack capabilities, enable them when you create a new database.
You cannot enable them after database creation.

To add capabilities to the database:

1. In the **Capabilities** section, select one or more capabilities.

1. To customize capabilities, click **Parameters** and enter the optional custom configuration.

1. Click **Done**.

To change capabilities' parameters for an existing database using the Cluster Manager UI:

  1. In the **Capabilities** section, click **Edit Parameters**.

  1. After you finish editing the module's configuration parameters, click **Done** to close the parameter editor.

title: High Availability

text:
- [**Replication**]() - We recommend you use intra-cluster replication to create replica shards for each database for high availability.

    If the cluster is configured to support [rack-zone awareness](), you can also enable rack-zone awareness for the database.

- [**Replica high availability**]() - Automatically migrates replica shards to an available node if a replica node fails or is promoted to primary.

title: Clustering

text:
- **Enable sharding** - You can either:

    - Turn on sharding to enable [database clustering]() and select the number of database shards.

        When database clustering is enabled, databases are subject to limitations on [Multi-key commands]().

        You can increase the number of shards in the database at any time.

    - Turn off sharding to use only one shard so that you can use [Multi-key commands]() without the limitations.

- [**Shards placement**]() - Determines how to distribute database shards across nodes in the cluster.

    - _Dense_ places shards on the smallest number of nodes.

    - _Sparse_ spreads shards across many nodes.

- [**OSS Cluster API**]() - The OSS Cluster API configuration allows access to multiple endpoints for increased throughput.

    This configuration requires clients to connect to the primary node to retrieve the cluster topology before they can connect directly to proxies on each node.

    When you enable the OSS Cluster API, shard placement changes to _Sparse_, and the database proxy policy changes to _All primary shards_ automatically.

You must use a client that supports the cluster API to connect to a database that has the cluster API enabled.

- **Hashing policy** - You can accept the [standard hashing policy](), which is compatible with Redis Open Source, or define a [custom hashing policy]() to define where keys are located in the clustered database.

- [**Database proxy**]() - Determines the number and location of active proxies, which manage incoming database operation requests.

title: Durability

text:
- [**Persistence**]() - To protect against loss of data stored in RAM, you can enable data persistence and store a copy of the data on disk with snapshots or an append-only file.

- **Scheduled backup** - You can configure [periodic backups]() of the database, including the interval and backup location parameters.

title: TLS

text: You can require [**TLS**]() encryption and authentication for all communications, TLS encryption and authentication for Replica Of communication only, and TLS authentication for clients.

title: Access control

text:
- **Unauthenticated access** - You can access the database as the default user without providing credentials.

- **Password-only authentication** - When you configure a password for your database's default user, all connections to the database must authenticate with the [AUTH command]().

    If you also configure an access control list, connections can specify other users for authentication, and requests are allowed according to the Redis ACLs specified for that user.

    Creating a database without ACLs enables a *default* user with full access to the database. You can secure default user access by requiring a password.

- **Access Control List** - You can specify the [user roles]() that have access to the database and the [Redis ACLs]() that apply to those connections.

    To define an access control list for a database:

    1. In **Security > Access Control > Access Control List**, select **+ Add ACL**.

    1. Select a [role]() to grant database access.

    1. Associate a [Redis ACL]() with the role and database.

    1. Select the check mark to add the ACL.

title: Alerts

text:
Select [alerts]() to show in the database status and configure their thresholds.

You can also choose to [send alerts by email]() to relevant users.

title: Replica Of

text: With [**Replica Of**](), you can make the database a repository for keys from other databases.

title: RESP3 support

text:
[RESP]()  (Redis Serialization Protocol) is the protocol clients use to communicate with Redis databases. If you enable RESP3 support, the database will support the RESP3 protocol in addition to RESP2.

For more information about Redis Software's compatibility with RESP3, see [RESP compatibility with Redis Software]().

title: Internode encryption

text: Enable **Internode encryption** to encrypt data in transit between nodes for this database. See [Internode encryption]() for more information.


title: Enable OSS Cluster API

title: Overview

text: Review [OSS Cluster API]() to determine if you should enable this feature for your database.

title: Prerequisites

text:
The OSS Cluster API is supported only when a database meets specific criteria.

The database must:

- Use the standard [hashing policy]().
- Have the [proxy policy]() set to either _All primary shards_ or _All nodes_.

In addition, the database must _not_:

- Use node `include` or `exclude` in the proxy policy.
- Use [RedisTimeSeries]() or [RedisGears]() modules.

The OSS Cluster API setting applies to individual databases instead of the entire cluster.

For Kubernetes deployments, see [Enable cluster-aware clients (OSS Cluster API)]().

title: Enable OSS Cluster API support

text:
You can use the Cluster Manager UI, the `rladmin` utility, or the REST API to enable OSS Cluster API support for a database.

When you enable OSS Cluster API support for an existing database, the change applies to new connections but does not affect existing connections. Clients must close existing connections and reconnect to apply the change.

**Cluster Manager UI:**

When you use the Cluster Manager UI to enable the OSS Cluster API, it automatically configures the [prerequisites]().

To enable the OSS Cluster API for an existing database in the Cluster Manager UI:

1. From the database's **Configuration** tab, click **Edit**.

1. Expand the **Clustering** section.

1. Enable **Sharding**.

1. Select **OSS Cluster API**.

    <img src="../../../../../images/rs/screenshots/databases/config-clustering-oss-cluster-api-7-22.png" alt="Use the *OSS Cluster API* setting to enable the API for the selected database.">

1. Click **Save**.

You can also use the Cluster Manager UI to enable the setting when creating a new database.

**rladmin:**

You can use the [`rladmin` utility]() to enable the OSS Cluster API for Redis Software databases, including Replica Of databases.

For Active-Active (CRDB) databases, [use the crdb-cli utility](#active-active-databases).

Ensure the [prerequisites]() have been configured.  Then, enable the OSS Cluster API for a Redis database from the command line:

[code example]

To determine the current setting for a database from the command line, use `rladmin info db` to return the value of the `oss_cluster` setting.

[code example]

The OSS Cluster API setting applies to the specified database only; it does not apply to the cluster.

**REST API:**

You can enable the OSS Cluster API when you [create a database]() using the REST API:

[code example]

To enable the OSS Cluster API for an existing database, you can use an [update database configuration]() REST API request:

[code example]

title: Active-Active databases

text:
The OSS Cluster API setting applies to all instances of the Active-Active database across participating clusters. To enable the OSS Cluster API for Active-Active databases, use the [Cluster Manager UI](#cluster-manager-ui) or the [`crdb-cli`]() utility.

**Cluster Manager UI:**

When you use the Cluster Manager UI to enable the OSS Cluster API, it automatically configures the [prerequisites]().

To enable the OSS Cluster API for an existing Active-Active database in the Cluster Manager UI:

1. From the database's **Configuration** tab, click **Edit**.

1. Expand the **Clustering** section.

1. Sharding must be enabled during Active-Active database creation.

1. Select **OSS Cluster API**.

    <img src="../../../../../images/rs/screenshots/databases/config-clustering-oss-cluster-api-active-active-7-22.png" alt="Use the *OSS Cluster API* setting to enable the API for the selected database.">

1. Click **Save**.

You can also use the Cluster Manager UI to enable the setting when creating a new database.

**crdb-cli:**

To create an Active-Active database and enable the OSS Cluster API with `crdb-cli`:

[code example]

See the [`crdb-cli crdb create`]() reference for more options.

To enable the OSS Cluster API for an existing Active-Active database with `crdb-cli`:

1. Obtain the `CRDB-GUID` for the new database:

    [code example]

1. Use the `CRDB-GUID` to enable the OSS Cluster API:

    [code example]

title: Change preferred IP type

text:
By default, using [`CLUSTER SLOTS`]() and [`CLUSTER SHARDS`]() in a Redis Software cluster exposes the internal IP addresses for databases with the OSS Cluster API enabled.

To use external IP addresses instead of internal IP addresses, run the following [`rladmin tune db`]() command for each affected database:

[code example]

title: Turn off OSS Cluster API support

text:
To deactivate OSS Cluster API support for a database, use one of the following methods:

**Cluster Manager UI:**

To turn off the OSS Cluster API for standard databases or Active-Active databases in the Cluster Manager UI:

1. From the database's **Configuration** tab, click **Edit**.

1. Expand the **Clustering** section.

1. Clear the **OSS Cluster API** checkbox.

1. Click **Save**.

**rladmin:**

For standard databases, including Replica Of, you can use `rladmin` to turn off the OSS Cluster API:

[code example]

**crdb-cli:**

For Active-Active databases, you can use `crdb-cli` to turn off the OSS Cluster API:

[code example]

When you turn off OSS Cluster API support for an existing database, the change applies to new connections but does not affect existing connections. Clients must close existing connections and reconnect to apply the change.

title: Multi-key command support

text:
When you enable the OSS Cluster API for a database,
[multi-key commands]() are only allowed when all keys are mapped to the same slot.

To verify that your database meets this requirement, make sure that the `CLUSTER KEYSLOT` reply is the same for all keys affected by the multi-key command.  To learn more, see [multi-key operations]().

code: $ rladmin tune db <database name or ID> oss_cluster enabled

section_id: enable-oss-cluster-api-support

code:
$ rladmin info db test | grep oss_cluster:
  oss_cluster: enabled

code:
POST /v1/bdbs
{
  "oss_cluster": true,
  // Other database configuration parameters
}

code:
PUT /v1/bdbs/<database-id>
{ "oss_cluster": true }

code:
$ crdb-cli crdb create --name <name> \
    --memory-size 10g --port <port> \
    --sharding true --shards-count 2  \
    --replication true --oss-cluster true --proxy-policy all-master-shards \
    --instance fqdn=<fqdn>,username=<user>,password=<pass> \
    --instance fqdn=<fqdn>,username=<user>,password=<pass> \
    --instance fqdn=<fqdn>,username=<user>,password=<pass>

section_id: active-active-databases

code:
$ crdb-cli crdb list
    CRDB-GUID    NAME   REPL-ID  CLUSTER-FQDN
    <CRDB-GUID>  Test   4        cluster1.local

code:
$ crdb-cli crdb update --crdb-guid <CRDB-GUID> \
        --oss-cluster true

code: $ rladmin tune db db:<database-id> oss_cluster_api_preferred_ip_type external

section_id: change-preferred-ip-type

code: $ rladmin tune db <name or ID> oss_cluster disabled

section_id: turn-off-oss-cluster-api-support

code:
$ crdb-cli crdb update --crdb-guid <CRDB-GUID> \
        --oss-cluster false


title: Configure proxy policy

title: Overview

text:
Redis Software provides high-performance data access
through a proxy process that manages and optimizes access to shards
within the Redis Software cluster. Each node contains a single proxy process.
Each proxy can be active and take incoming traffic or it can be passive
and wait for failovers.

title: Proxy policies

text:
A database can have one of the following proxy policies:

| Proxy policy | Description | Recommended use cases | Advantages | Disadvantages |
|--------------|-------------|-----------------------|-----------|-----------------|
| Single | Only a single proxy is bound to the database. This is the default database configuration. | Most use cases without high traffic or load | Lower resource usage, fewer application-to-cluster connections | Higher latency, more network hops |
| All primary shards | Multiple proxies are bound to the database, one on each node that hosts a database primary shard. | Most use cases that require multiple endpoints, such as when using the [OSS Cluster API]() | Lower latency, fewer network hops, higher throughput | Higher resource usage, more application-to-proxy connections |
| All nodes | Multiple proxies are bound to the database, one on each node in the cluster, regardless of whether or not there is a shard from this database on the node. | When using [load balancers]() for environments without DNS | Higher throughput | Highest resource usage |

title: View proxy policy

text:
You can use the Cluster Manager UI, [`rladmin`](), or the [REST API]() to view proxy configuration settings.

The [`rladmin info cluster`]() command returns the current proxy policy for sharded and non-sharded (single shard) databases.

[code example]

title: Configure database proxy policy

text:
You can use the [Cluster Manager UI](#cluster-manager-ui-method), the [REST API](#rest-api-method), or [`rladmin`](#command-line-method) to configure a database's proxy policy.

Any configuration update that unbinds existing proxies can disconnect existing client connections.

title: Cluster Manager UI method

text:
You can change a database's proxy policy when you [create]() or [edit]() a database using the Cluster Manager UI:

1. While in edit mode on the database's configuration screen, expand the **Clustering** section.

1. Select a policy from the **Database proxy** list.

1. Click **Create** or **Save**.

title: REST API method

text:
You can specify a proxy policy when you [create a database]() using the REST API:

[code example]

To change the proxy policy of an existing database and endpoint, you can use an [update database configuration]() REST API request:

[code example]

title: Command-line method

role: syntax

text:
You can configure a database's proxy policy using [`rladmin bind`]().

The following example changes the bind policy for a database named "db1" with an endpoint ID "1:1" to "All primary shards" proxy policy:

[code example]

The next command performs the same task using the database ID instead of the name. The ID of this database is "1".

[code example]

You can find the endpoint ID for the endpoint argument by running `rladmin status`. Look for the endpoint ID information under
the `ENDPOINT` section of the output.

title: Reapply policies after topology changes

text:
If you want to reapply the policy after topology changes, such as node restarts,
failovers and migrations, run this command to reset the policy:

[code example]

This is not required with single policies.

#### Other implications

During the regular operation of the cluster different actions might take
place, such as automatic migration or automatic failover, which change
what proxy needs to be bound to what database. When such actions take
place the cluster attempts, as much as possible, to automatically change
proxy bindings to adhere to the defined policies. That said, the cluster
attempts to prevent any existing client connections from being
disconnected, and hence might not entirely enforce the policies. In such
cases, you can enforce the policy using the appropriate rladmin
commands.

title: Multiple active proxies

text:
Each database you create in a Redis Software cluster has an endpoint, which consists of a unique URL and port on the FQDN. This endpoint receives all the traffic for all operations for that database. By default, Redis Software binds this database endpoint to one of the proxies on a single node in the cluster. This proxy becomes an active proxy and receives all the operations for the given database. If the node with the active proxy fails, a new proxy on another node takes over as part of the failover process automatically.

In most cases, a single proxy can handle a large number of operations
without consuming additional resources. However, under high load,
network bandwidth, or a high rate of packets per second (PPS) on the
single active proxy can become a bottleneck to how fast database
operations can be performed. In such cases, having multiple active proxies across multiple nodes, mapped to the same external database
endpoint, can significantly improve throughput.

You can configure a database to have multiple internal proxies, which can improve performance in some cases.
Even though multiple active proxies can help improve the throughput of database
operations, configuring multiple active proxies may cause additional
latency in operations as the shards and proxies are spread across
multiple nodes in the cluster.

When the network on a single active proxy becomes the bottleneck, consider enabling multiple NIC support in Redis Software. With nodes that have multiple physical NICs (Network Interface Cards), you can configure Redis Software to separate internal and external traffic onto independent physical NICs. For more details, refer to [Multi-IP & IPv6]().

Having multiple proxies for a database can improve Redis Software's ability for fast failover in case of proxy or node failure. With multiple proxies for a database, a client doesn't need to wait for the cluster to spin up another proxy and a DNS change in most cases. Instead, the client uses the next IP address in the list to connect to another proxy.

code:
$ rladmin info cluster
cluster configuration:
   ...
   default_non_sharded_proxy_policy: single
   default_sharded_proxy_policy: single
   ...

section_id: view-proxy-policy

code:
POST /v1/bdbs
{
  "proxy_policy": "single | all-master-shards | all-nodes",
  // Other database configuration parameters
}

section_id: rest-api-method

code:
PUT /v1/bdbs/<database-id>
{
  "proxy_policy": "single | all-master-shards | all-nodes",
  "endpoint": <endpoint_uid>
}

code: rladmin bind db db1 endpoint 1:1 policy all-master-shards

section_id: command-line-method

code: rladmin bind db db:1 endpoint 1:1 policy all-master-shards

code: rladmin bind db db:<ID> endpoint <endpoint id> policy <all-master-shards|all-nodes>

section_id: reapply-policies-after-topology-changes


title: Configure high availability for replica shards

title: Overview

text:
When you enable [database replication](),
Redis Software creates a replica of each primary shard.  The replica shard will always be
located on a different node than the primary shard to make your data highly available.  If the primary shard
fails or if the node hosting the primary shard fails, then the replica is promoted to primary.

Without replica high availability (_replica\_ha_) enabled, the promoted primary shard becomes a single point of failure
as the only copy of the data.

Enabling _replica\_ha_ configures the cluster to automatically replicate the promoted replica on an available node.
This automatically returns the database to a state where there are two copies of the data:
the former replica shard which has been promoted to primary and a new replica shard.

An available node:

1. Meets replica migration requirements, such as [rack-awareness]().
1. Has enough available RAM to store the replica shard.
1. Does not also contain the primary shard.

In practice, replica migration creates a new replica shard and copies the data from the primary shard to the new replica shard.

For example:

1. Node:2 has a primary shard and node:3 has the corresponding replica shard.
1. Either:

    - Node:2 fails and the replica shard on node:3 is promoted to primary.
    - Node:3 fails and the primary shard is no longer replicated to the replica shard on the failed node.

1. If replica HA is enabled, a new replica shard is created on an available node.
1. The data from the primary shard is replicated to the new replica shard.

- Replica HA follows all prerequisites of replica migration, such as [rack-awareness]().
- Replica HA migrates as many shards as possible based on available DRAM in the target node. When no DRAM is available, replica HA stops migrating replica shards to that node.

text:
If replica high availability is enabled for both the cluster and a database,
the database's replica shards automatically migrate to another node when a primary or replica shard fails.
If replica HA is not enabled at the cluster level,
replica HA will not migrate replica shards even if replica HA is enabled for a database.

Replica high availability is enabled for the cluster by default.

When you create a database using the Cluster Manager UI, replica high availability is enabled for the database by default if you enable replication.

To use replication without replication high availability, clear the **Replica high availability** checkbox.

You can also enable or turn off replica high availability for a database using `rladmin` or the REST API.

For Active-Active databases, replica HA is enabled for the database by default to make sure that replica shards are available for Active-Active replication.

title: Configure cluster policy for replica HA

text:
To enable or turn off replica high availability by default for the entire cluster, use one of the following methods:

- [rladmin tune cluster]():

    [code example]

- [Update cluster policy]() REST API request:

    [code example]

title: Turn off replica HA for a database

text:
To turn off replica high availability for a specific database using `rladmin`, run:

[code example]

You can use the database name in place of `db:<ID>` in the preceding command.

title: Configuration options

text:
You can see the current configuration options for replica HA with:

[code example]

title: Grace period

text:
By default, replica HA has a 10-minute grace period after node failure and before new replica shards are created.

The default grace period is 30 minutes for containerized applications using [Redis Enterprise Software for Kubernetes]().

For Kubernetes deployments, if ReplicaHA (previously SlaveHA) is enabled at the cluster level, you must also manually enable it at the database level for each RedisEnterpriseDatabase (REDB) using the UI or `rladmin`. Without manual database-level configuration, databases will show `slave_ha: disabled (database)` even when cluster-level ReplicaHA is enabled.

To configure this grace period from rladmin, run:

[code example]

title: Shard priority

text:
Replica shard migration is based on priority.  When memory resources are limited, the most important replica shards are migrated first:

1. `slave_ha_priority` - Replica shards with higher
    integer values are migrated before shards with lower values.

    To assign priority to a database, run:

    [code example]

    You can use the database name in place of `db:<ID>` in the preceding command.

1. Active-Active databases - Active-Active database synchronization uses replica shards to synchronize between the replicas.
1. Database size - It is easier and more efficient to move replica shards of smaller databases.
1. Database UID - The replica shards of databases with a higher UID are moved first.

title: Cooldown periods

text:
Both the cluster and the database have cooldown periods.

After node failure, the cluster cooldown period (`slave_ha_cooldown_period`) prevents another replica migration due to another node failure for any
database in the cluster until the cooldown period ends. The default is one hour.

After a database is migrated with replica HA,
it cannot go through another migration due to another node failure until the cooldown period for the database (`slave_ha_bdb_cooldown_period`) ends. The default is two hours.

To configure cooldown periods, use [`rladmin tune cluster`]():

- For the cluster:

    [code example]

- For all databases in the cluster:

    [code example]

title: Alerts

text:
The following alerts are sent during replica HA activation:

- Shard migration begins after the grace period.
- Shard migration fails because there is no available node (sent hourly).
- Shard migration is delayed because of the cooldown period.

title: Limitations

role: limits

text:
- If two nodes that host a primary shard and its corresponding replica shard go down at the same time, both shards will be lost and replica high availability will not be able to create a new replica shard for any primary shard still running.

This limitation applies only when cluster quorum is maintained after two nodes fail, such as clusters with at least five nodes. If two nodes fail simultaneously in a cluster with only three nodes, the entire cluster is lost and must be recovered.

code: rladmin tune cluster slave_ha { enabled | disabled }

section_id: configure-cluster-policy-for-replica-ha

code:
PUT /v1/cluster/policy
    { "slave_ha": <boolean> }

code: rladmin tune db db:<ID> slave_ha disabled

section_id: turn-off-replica-ha-for-a-database

code: rladmin info cluster

section_id: configuration-options

code: rladmin tune cluster slave_ha_grace_period <time_in_seconds>

section_id: grace-period

code: rladmin tune db db:<ID> slave_ha_priority <positive integer>

section_id: shard-priority

code: rladmin tune cluster slave_ha_cooldown_period <time_in_seconds>

section_id: cooldown-periods

code: rladmin tune cluster slave_ha_bdb_cooldown_period <time_in_seconds>


title: Configure shard placement

title: Overview

text:
In Redis Software, the location of master and replica shards on the cluster nodes can impact the database and node performance.
Master shards and their corresponding replica shards are always placed on separate nodes for data resiliency.
The [shard placement policy]() helps to maintain optimal performance and resiliency.

title: Default shard placement policy

text:
When you create a new cluster, the cluster configuration has a `dense` default shard placement policy.
When you create a database, this default policy is applied to the new database.

To see the current default shard placement policy, run `rladmin info cluster`:

To change the default shard placement policy so that new databases are created with the `sparse` shard placement policy, run:

[code example]

title: Shard placement policy for a database

text:
To see the shard placement policy for a database in `rladmin status`.

To change the shard placement policy for a database, run:

[code example]

code: rladmin tune cluster default_shards_placement [ dense | sparse ]

section_id: default-shard-placement-policy

code: rladmin tune db { db:<ID> | <database-name> } shards_placement { dense | sparse }

section_id: shard-placement-policy-for-a-database


title: Connect to a database

summary: Learn how to connect your application to a Redis database hosted by Redis Enterprise Software and test your connection.

summary: Info about Redis client libraries and supported clients when using the discovery service.

title: Supported connection clients

title: Test client connection

summary: Troubleshoot issues with Redis Software, including connectivity issues between the database and clients or applications.

title: Troubleshooting pocket guide for Redis Software

title: Overview

text:
After you [set up a cluster]() and [create a Redis database](), you can connect to your database.

To connect to your database, you need the database endpoint, which includes the cluster name (FQDN) and the database port. To view and copy public and private endpoints for a database in the cluster, see the database’s **Configuration > General** section in the Cluster Manager UI.

If you try to connect with the FQDN, and the database does not respond, try connecting with the IP address. If this succeeds, DNS is not properly configured. To set up DNS, see [Configure cluster DNS]().

If you want to secure your connection, set up [TLS]().

title: Connect to a database

text:
Use one of the following connection methods to connect to your database:

- [`redis-cli`]() utility

- [Redis Insight](https://redis.com/redis-enterprise/redis-insight/)

- [Redis client]() for your preferred programming language

For examples, see [Test client connection]().

title: Continue learning with Redis University

text: See the [Connect to a database on Redis Software](https://university.redis.io/course/zyxx6fdkcm5ahd) for the course.


title: Supported connection clients

title: Overview

text: You can connect to Redis Software databases programmatically using client libraries.

title: Redis client libraries

text:
To connect an application to a Redis database hosted by Redis Software, use a [client library]() appropriate for your programming language.

You can also use the `redis-cli` utility to connect to a database from the command line.

For examples of each approach, see the [Redis Software quickstart]().

Note: You cannot use client libraries to configure Redis Software.  Instead, use:

- The Redis Software [Cluster Manager UI]()
- The [REST API]()
- Command-line utilities, such as [`rladmin`]()

title: Discovery service

text:
We recommend the following clients when using a [discovery service]() based on the Redis Sentinel API:

- [redis-py]() (Python client)
- [NRedisStack]() (.NET client)
- [Jedis]() (synchronous Java client)
- [Lettuce]() (asynchronous Java client)
- [go-redis]() (Go client)
- [Hiredis](https://github.com/redis/hiredis) (C client)

If you need to use another client, you can use [Sentinel Tunnel](https://github.com/RedisLabs/sentinel_tunnel)
to discover the current Redis master with Sentinel and create a TCP tunnel between a local port on the client and the master.


title: Test client connection

title: Overview

text:
In various scenarios, such as after creating a new cluster or upgrading
the cluster, you should verify clients can connect to the
database.

To test client connectivity:

1. After you [create a Redis database](), copy the database endpoint, which contains the cluster name (FQDN).

    To view and copy endpoints for a database in the cluster, see the database’s **Configuration > General** section in the Cluster Manager UI:

1. Try to connect to the database endpoint from your client of choice,
    and run database commands.

1. If the database does not respond, try to connect to the database
    endpoint using the IP address rather than the FQDN. If you
    succeed, then DNS is not properly configured. For
    additional details, see
    [Configure cluster DNS]().

If any issues occur when testing database connections, [contact
support](https://redis.com/company/support/).

title: Test database connections

text:
After you create a Redis database, you can connect to your
database and store data using one of the following methods:

- [`redis-cli`](), the built-in command-line tool

- [Redis Insight](https://redis.com/redis-enterprise/redis-insight/), a free Redis GUI that is available for macOS, Windows, and Linux

- An application using a Redis client library, such as [`redis-py`](https://github.com/redis/redis-py) for Python. See the [client list]() to view all Redis clients by language.

title: Connect with redis-cli

text:
Connect to your database with `redis-cli` (located in the `/opt/redislabs/bin` directory), then store and retrieve a key:

[code example]

For more `redis-cli` connection examples, see the [`redis-cli` reference]().

title: Connect with Redis Insight

text:
Redis Insight is a free Redis GUI that is available for macOS, Windows, and Linux.

1. [Install Redis Insight]().

1. Open Redis Insight and select **Add Redis Database**.

1. Enter the host and port in the **Host** and **Port** fields.

1. Select **Use TLS** if [TLS]() is set up.

1. Select **Add Redis Database** to connect to the database.

See the [Redis Insight documentation]() for more information.

title: Connect with Python

text:
Python applications can connect
to the database using the `redis-py` client library. For installation instructions, see the
[`redis-py` README](https://github.com/redis/redis-py#readme) on GitHub.

1. From the command line, create a new file called
`redis_test.py`:

    [code example]

1. Paste the following code in `redis_test.py`, and replace `<host>` and `<port>` with your database's endpoint details:

    [code example]

1. Run the application:

    [code example]

1. If the application successfully connects to your database, it outputs:

    [code example]

title: Connect with discovery service

text:
You can also connect a Python application to the database using the discovery service, which complies with the Redis Sentinel API.

In the IP-based connection method, you only need the database name, not the port number.
The following example uses the discovery service that listens on port 8001 on all nodes of the cluster
to discover the endpoint for the database named "db1".

[code example]

For more `redis-py` connection examples, see the [`redis-py` developer documentation](https://redis.readthedocs.io/en/stable/examples/connection_examples.html).

section_id: connect-with-redis-cli

code: vi redis_test.py

section_id: connect-with-python

code:
import redis

    # Connect to the database
    r = redis.Redis(host='<host>', port=<port>)

    # Store a key
    print("set key1 123")
    print(r.set('key1', '123'))

    # Retrieve the key
    print("get key1")
    print(r.get('key1'))

code: python redis_test.py

code:
set key1 123
    True
    get key1
    123

code:
from redis.sentinel import Sentinel

# with IP based connections, a list of known node IP addresses is constructed
# to allow connection even if any one of the nodes in the list is unavailable.
sentinel_list = [
('10.0.0.44', 8001),
('10.0.0.45', 8001),
('10.0.0.46', 8001)
]

# change this to the db name you want to connect
db_name = 'db1'

sentinel = Sentinel(sentinel_list, socket_timeout=0.1)
r = sentinel.master_for(db_name, socket_timeout=0.1)

# set key "foo" to value "bar"
print(r.set('foo', 'bar'))
# set value for key "foo"
print(r.get('foo'))

section_id: connect-with-discovery-service


title: Overview

text: If your client or application cannot connect to your database, verify the following.

title: Identify Redis host issues

text:
#### Check resource usage

- Used disk space should be less than `90%`. To check the host machine's disk usage, run the [`df`](https://man7.org/linux/man-pages/man1/df.1.html) command:

    [code example]

- RAM and CPU utilization should be less than `80%`, and host resources must be available exclusively for Redis Software. You should also make sure that swap memory is not being used or is not configured.

    1. Run the [`free`](https://man7.org/linux/man-pages/man1/free.1.html) command to check memory usage:

        [code example]

    1. Used CPU should be less than `80%`. To check CPU usage, use `top` or `vmstat`.

        Run [`top`](https://man7.org/linux/man-pages/man1/top.1.html):

        [code example]

        Run [`vmstat`](https://man7.org/linux/man-pages/man8/vmstat.8.html):

        [code example]

    1. If CPU or RAM usage is greater than 80%, ask your system administrator which process is the culprit. If the process is not related to Redis, terminate it.

#### Sync clock with time server

It is recommended to sync the host clock with a time server.

Verify that time is synchronized with the time server using one of the following commands:

- `ntpq -p`

- `chronyc sources`

- [`timedatectl`](https://man7.org/linux/man-pages/man1/timedatectl.1.html)

#### Remove https_proxy and http_proxy variables

1. Run [`printenv`](https://man7.org/linux/man-pages/man1/printenv.1.html) and check if `https_proxy` and `http_proxy` are configured as environment variables:

    [code example]

1. If `https_proxy` or `http_proxy` exist, remove them:

    [code example]
    [code example]

#### Review system logs

Review system logs including the syslog or journal for any error messages, warnings, or critical events. See [Logging]() for more information.

title: Identify issues caused by security hardening

text:
- Temporarily deactivate any security hardening tools (such as selinux, cylance, McAfee, or dynatrace), and check if the problem is resolved.

- The user `redislabs` must have read and write access to `/tmp` directory. Run the following commands to verify.

    1. Create a test file in `/tmp` as the `redislabs` user:
        [code example]

    1. Verify the file was created successfully:
        [code example]

- Using a non-permissive file mode creation mask (`umask`) can cause issues.

    1. Check the output of `umask`:

        [code example]

    1. If `umask`'s output differs from the default value `0022`, it might prevent normal operation. Consult your system administrator and revert to the default `umask` setting.

title: Identify cluster issues

text:
- Use `supervisorctl status` to verify all processes are in a `RUNNING` state:

    [code example]

- Run `rlcheck` and verify no errors appear:

    [code example]

- Run [`rladmin status issues_only`]() and verify that no issues appear:

    [code example]

- Run [`rladmin status shards`](). For each shard, `USED_MEMORY` should be less than 25 GB.

    [code example]

- Run [`rladmin cluster running_actions`]() and confirm that no tasks are currently running (active):

    [code example]

title: Troubleshoot connectivity

role: errors

text:
#### Database endpoint resolution

1. On the client machine, check if the database endpoint can be resolved:

    [code example]

1. If endpoint resolution fails on the client machine, check on one of the cluster nodes:

    [code example]

1. If endpoint resolution succeeds on the cluster node but fails on the client machine, review the DNS configuration and fix any errors.

1. If the endpoint can’t be resolved on the cluster node, [contact support](https://redis.com/company/support/).

#### Client application issues

1. To identify possible client application issues, test connectivity from the client machine to the database using [`redis-cli`]():

    [`INFO`]():

    [code example]

    [`PING`]():

    [code example]

    or if TLS is enabled:

    [code example]

1. If the client machine cannot connect, try to connect to the database from one of the cluster nodes:

    [code example]

1. If the cluster node is also unable to connect to the database, [contact Redis support](https://redis.com/company/support/).

1. If the client fails to connect, but the cluster node succeeds, perform health checks on the client and network.

#### Firewall access

1. Run one of the following commands to verify that database access is not blocked by a firewall on the client machine or cluster:

    [code example]

    [code example]

    [code example]

1. To resolve firewall issues:

    1. If a firewall is configured for your database, add the client IP address to the firewall rules.

    1. Configure third-party firewalls and external proxies to allow the cluster FQDN, database endpoint IP address, and database ports.

title: Troubleshoot latency

text:
#### Server-side latency

- Make sure the database's used memory does not reach the configured database max memory limit. For more details, see [Database memory limits]().

- Try to correlate the time of the latency with any surge in the following metrics:

    - Number of connections

    - Used memory

    - Evicted keys

    - Expired keys

- Run [`SLOWLOG GET`]() using [`redis-cli`]() to identify slow commands such as [`KEYS`]() or [`HGETALL`](:

    [code example]

    Consider using alternative commands such as [`SCAN`](), [`SSCAN`](), [`HSCAN`]() and [`ZSCAN`]()

- Keys with large memory footprints can cause latency. To identify such keys, compare the keys returned by [`SLOWLOG GET`]() with the output of the following commands:

    [code example]

    [code example]

- For additional diagnostics, see:

    - [Diagnosing latency issues]()

    - [View Redis slow log]()

#### Client-side latency

Verify the following:

- There is no memory or CPU pressure on the client host.

- The client uses a connection pool instead of frequently opening and closing connections.

- The client does not erroneously open multiple connections that can pressure the client or server.

code:
$ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    overlay          59G   23G   33G  41% /
    /dev/vda1        59G   23G   33G  41% /etc/hosts

section_id: identify-redis-host-issues

code:
$ top
        Tasks:  54 total,   1 running,  53 sleeping,   0 stopped,   0 zombie
       %Cpu(s):  1.7 us,  1.4 sy,  0.0 ni, 96.8 id,  0.0 wa,  0.0 hi,  0.1 si,  0.0 st
       KiB Mem :  6087028 total,   988672 free,  1958060 used,  3140296 buff/cache
       KiB Swap:  1048572 total,  1048572 free,        0 used.  3437460 avail Mem

code: printenv | grep -i proxy

code: unset https_proxy

code: unset http_proxy

code: $ su - redislabs -s /bin/bash -c 'touch /tmp/test'

code:
$ ls -l /tmp/test
        -rw-rw-r-- 1 redislabs redislabs 0 Aug 12 02:06 /tmp/test

code:
$ umask
        0022

code: supervisorctl status

section_id: identify-cluster-issues

code: rlcheck

code:
$ rladmin status issues_only
    CLUSTER NODES:
    NODE:ID ROLE ADDRESS EXTERNAL_ADDRESS HOSTNAME SHARDS CORES FREE_RAM PROVISIONAL_RAM VERSION STATUS

    DATABASES:
    DB:ID  NAME        TYPE  STATUS  SHARDS  PLACEMENT   REPLICATION    PERSISTENCE    ENDPOINT

    ENDPOINTS:
    DB:ID               NAME             ID          NODE             ROLE             SSL

    SHARDS:
    DB:ID      NAME     ID        NODE     ROLE     SLOTS      USED_MEMORY            STATUS

code:
$ rladmin status shards
    SHARDS:
    DB:ID    NAME         ID          NODE      ROLE      SLOTS       USED_MEMORY       STATUS
    db:1     db1          redis:1     node:1    master    0-16383     2.13MB            OK

code:
$ rladmin cluster running_actions
    No active tasks

code: dig <endpoint>

section_id: troubleshoot-connectivity

code: dig @localhost <endpoint>

code: redis-cli -h <endpoint> -p <port> -a <password> INFO

code: redis-cli -h <endpoint> -p <port> -a <password> PING

code: redis-cli -h <endpoint> -p <port> -a <password> --tls --insecure --cert --key PING

code: redis-cli -h <node IP or hostname> -p <port> -a <password> PING

code: iptables -L

code: ufw status

code: firewall-cmd –list-all

code: redis-cli -h <endpoint> -p <port> -a <password> SLOWLOG GET <number of entries>

section_id: troubleshoot-latency

code: redis-cli -h <endpoint> -p <port> -a <password> --memkeys

code: redis-cli -h <endpoint> -p <port> -a <password> --bigkeys


title: Create a Redis Software database

summary: Create a database with Redis Software.

title: Overview

text: Redis Software lets you create databases and distribute them across a cluster of nodes using the [Cluster Manager UI](#cluster-manager-ui-method) or the [REST API](#rest-api-method).

title: Cluster Manager UI method

text:
To create a new database using the Cluster Manager UI:

1. Sign in to the Cluster Manager UI at `https://<hostname>:8443`

1. Use one of the following methods to create a new database:

    - [Quick database](#quick-database)

    - [Create database with additional configuration](#create-db-ui)

1. If you did not specify a port number for the database, you can find the port number in the **Endpoint** field in the **Databases > Configuration > General** section.

1. [Test client connectivity]().

For databases with Active-Active replication for geo-distributed locations,
see [Create an Active-Active database](). To create and manage Active-Active databases, use the legacy UI.

title: Quick database

text:
To quickly create a database and skip additional configuration options during initial creation:

1. On the **Databases** screen, select **Quick database**.

1. Select a Redis version from the **Database version** list.

1. Configure settings that are required for database creation but can be changed later:

    - Database name

    - Memory limit (GB)

2. Configure optional settings that can't be changed after database creation:

    - Endpoint port (set by the cluster if not set manually)

    - Capabilities (previously modules) to enable

        Databases created with Redis version 8 or later automatically enable the capabilities (modules) bundled with Redis Software as follows:

1. Optionally select **Full options** to configure [additional settings]().

1. Select **Create**.

title: Create database with additional configuration {#create-db-ui}

text:
To create a new database and configure additional settings:

1. Open the **Create database** menu with one of the following methods:

    - Click the **+** button next to **Databases** in the navigation menu:

    - Go to the **Databases** screen and select **Create database**:

1. Select the database type:

    - **Single Region**

    - **Active-Active database** - Multiple participating Redis Software clusters can host instances of the same [Active-Active database]() in different geographic locations. Every instance can receive write operations, which are synchronized across all instances without conflict.

For Active-Active databases, see [Create an Active-Active geo-replicated database]().

1. Select a Redis version from the **Database version** list.

1. Enter a **Database name**.

    - Maximum of 63 characters

    - Only letters, numbers, or hyphens (-) are valid characters

    - Must start and end with a letter or digit

    - Case-sensitive

1. To configure additional database settings, expand each relevant section to make changes.

    See [Configuration settings]() for more information about each setting.

1. Select **Create**.

title: REST API method

text:
To [create a database]() using a REST API request:

[code example]

For additional database configuration fields, see the [BDB object]() reference.

title: Continue learning with Redis University

code:
POST https://<host>:<port>/v1/bdbs
{
    "name": "test-database",
    "type": "redis",
    "memory_size": 1073741824,
    // Additional fields
}

section_id: rest-api-method


title: Delete databases

summary: Delete a database from the Cluster Manager UI.

title: Content

text:
When you delete a database, both the database configuration and data are removed.

To delete a database from the Cluster Manager UI:

1. From the **Databases** list, select the database, then select **Configuration**.

1. Select  **Delete**.

1. In the **Delete database** dialog, confirm deletion.


title: Database clustering

summary: Clustering to allow customers to spread the load of a Redis process over multiple cores and the RAM of multiple servers.

title: Overview

text:
Source available [Redis](https://redis.io/docs/latest/get-started/) is a single-threaded process
to provide speed and simplicity.
A single Redis process is bound by the CPU core that it is running on and available memory on the server.

Redis Software supports database clustering to allow customers
to spread the load of a Redis process over multiple cores and the RAM of multiple servers.
A database cluster is a set of Redis processes where each process manages a subset of the database keyspace.

The keyspace of a Redis Software cluster is partitioned into database shards.
Each shard resides on a single node and is managed by that node.
Each node in a Redis database cluster can manage multiple shards.
The key space in the shards is divided into hash slots.
The slot of a key is determined by a hash of the key name or part of the key name.

Database clustering is transparent to the Redis client that connects to the database.
The Redis client accesses the database through a single endpoint that automatically routes all operations to the relevant shards.
You can connect an application to a single Redis process or a clustered database without any difference in the application logic.

title: Terminology

text:
In clustering, these terms are commonly used:

- Tag or Hash Tag - A part of the key that is used in the hash calculation.
- Slot or Hash Slot - The result of the hash calculation.
- Shard - Redis process that is part of the Redis clustered database.

title: When to use clustering (sharding)

text:
Clustering is an efficient way of scaling Redis that should be used when:

- The dataset is large enough to benefit from using the RAM resources of more than one node.
    When a dataset is more than 25 GB (50 GB for RoF), we recommend that you enable clustering to create multiple shards of the database
    and spread the data requests across nodes.
- The operations performed against the database are CPU-intensive, resulting in performance degradation.
    By having multiple CPU cores manage the database's shards, the load of operations is distributed among them.

title: Number of shards

text:
When enabling database clustering, you can set the number of database
shards. The minimum number of shards per database is 2 and the maximum
depends on the subscription you purchased.

After you enable database clustering and set the number of shards, you cannot deactivate database clustering or reduce the number of
shards. You can only increase the number of shards by a multiple of the
current number of shards. For example, if the current number of shards
is 3, you can increase the number of shards to 6, 9, or 12.

title: Supported hashing policies

role: compatibility

title: Standard hashing policy

text:
When using the standard hashing policy, a clustered Redis Software database behaves similarly to a standard [Redis Open Source cluster](#hash-tags), except when using multiple hash tags in a key's name. We recommend using only a single hash tag in a key name for hashing in Redis Software.

- **Keys with a hash tag**: a key's hash tag is any substring between
    `{` and `}` in the key's name. When a key's name
    includes the pattern `{...}`, the hash tag is used as input for the
    hashing function.

    For example, the following key names have the same
    hash tag and map to the same hash slot: `foo{bar}`,
    `{bar}baz`, and `foo{bar}baz`.

- **Keys without a hash tag**: when a key does not contain the `{...}`
    pattern, the entire key's name is used for hashing.

You can use a hash tag to store related keys in the same hash
slot so multi-key operations can run on these keys. If you do not use a hash tag in the key's name, the keys are distributed evenly across the keyspace's shards.
If your application does not perform multi-key operations, you do not
need to use hash tags.

title: Custom hashing policy

text:
You can configure a custom hashing policy for a clustered database. A
custom hashing policy is required when different keys need to be kept
together on the same shard to allow multi-key operations. The custom
hashing policy is provided through a set of Perl Compatible Regular
Expressions (PCRE) rules that describe the dataset's key name patterns.

To configure a custom hashing policy, enter the regular expression
(RegEx) rules that identify the substring in the key's name - hash tag
-- on which hashing is done. The hash tag is denoted in the
RegEx by the use of the \`tag\` named subpattern. Different keys that
have the same hash tag are stored and managed in the same slot.

After you enable the custom hashing policy, the following default RegEx
rules are implemented. Update these rules to fit your specific logic:

|  RegEx Rule | Description |
|  ------ | ------ |
|  .\*{(?\<tag\>.\*)}.\* | Hashing is done on the substring between the curly braces. |
|  (?\<tag\>.\*) | The entire key's name is used for hashing. |

You can modify existing rules, add new ones, delete rules, or change
their order to suit your application's requirements.

title: Custom hashing policy notes and limitations

text:
1. You can define up to 32 RegEx rules, each up to 256 characters.
2. RegEx rules are evaluated in order, and the first rule matched
    is used. Therefore, you should place common key name patterns at the
    beginning of the rule list.
3. Key names that do not match any of the RegEx rules trigger an
    error.
4. The '.\*(?\<tag\>)' RegEx rule forces keys into a single slot
    because the hash key is always empty. Therefore, when used,
    this should be the last, catch-all rule.
5. The following flag is enabled in the regular expression parser:
    PCRE_ANCHORED: the pattern is constrained to match only at the
    start of the string being searched.

title: Change the hashing policy

text:
The hashing policy of a clustered database can be changed. However,
most hashing policy changes trigger the deletion (FLUSHDB) of the
data before they can be applied.

Examples of such changes include:

- Changing the hashing policy from standard to custom or conversely,
    custom to standard.
- Changing the order of custom hashing policy rules.
- Adding new rules in the custom hashing policy.
- Deleting rules from the custom hashing policy.

The recommended workaround for updates that are not enabled,
or require flushing the database,
is to back up the database and import the data to a newly configured database.

title: Multi-key operations {#multikey-operations}

text:
Operations on multiple keys in a clustered database are supported with
the following limitations:

- **Multi-key commands**: Redis offers several commands that accept
    multiple keys as arguments. In a clustered database, most multi-key
    commands are not allowed across slots. The following multi-key
    commands **are allowed** across slots: DEL, MSET, MGET, EXISTS, UNLINK, TOUCH

    In Active-Active databases, multi-key write commands (DEL, MSET, UNLINK) can only be run on keys that are in the same slot. However, the following multi-key commands **are allowed** across slots in Active-Active databases: MGET, EXISTS, and TOUCH.

    Commands that affect all keys or keys that match a specified pattern are allowed
    in a clustered database, for example: FLUSHDB, FLUSHALL, KEYS

When using these commands in a sharded setup,
the command is distributed across multiple shards
and the responses from all shards are combined into a single response.

- **Geo commands**: For the [GEORADIUS]() and
    [GEORADIUSBYMEMBER]() commands, the
    STORE and STOREDIST options can only be used when all affected keys
    reside in the same slot.
- **Transactions**: All operations within a WATCH / MULTI / EXEC block
    should be performed on keys that are mapped to the same slot.
- **Lua scripts**: All keys used by a Lua script must be mapped to the same
    slot and must be provided as arguments to the EVAL / EVALSHA commands
    (as per the Redis specification). Using keys in a Lua script that
    were not provided as arguments might violate the sharding concept
    but do not result in the proper violation error being returned.
- **Renaming/Copy keys**: The use of the RENAME / RENAMENX / COPY commands is
    allowed only when the key's original and new values are mapped to
    the same slot.


title: Consistency during replication

summary: Explains the order write operations are communicated from app to proxy to shards for both non-blocking Redis write operations and blocking write operations on replication.

title: Overview

text:
Redis Software comes with the ability to replicate data
to another database instance for high availability and persist in-memory data on
disk permanently for durability. With the [`WAIT`]() command, you can
control the consistency and durability guarantees for the replicated and
persisted database.

title: Non-blocking Redis write operation

text:
Any updates that are issued to the database are typically performed with the following flow:

1. The application issues a write.
2. The proxy communicates with the correct primary (also known as master) shard in the system that contains the given key.
3. The shard writes the data and sends an acknowledgment to the proxy.
4. The proxy sends the acknowledgment back to the application.
5. The write is communicated from the primary shard to the replica.
6. The replica acknowledges the write back to the primary shard.
7. The write to a replica is persisted to disk.
8. The write is acknowledged within the replica.

title: Blocking write operation on replication

text:
With the [`WAIT`]() or [`WAITAOF`]() commands, applications can ask to wait for
acknowledgments only after replication or persistence is confirmed on
the replica. The flow of a write operation with `WAIT` or `WAITAOF` is:

1. The application issues a write.
2. The proxy communicates with the correct primary shard in the system that contains the given key.
3. Replication communicates the update to the replica shard.
4. If using `WAITAOF` and the AOF every write setting, the replica persists the update to disk before sending the acknowledgment.
5. The acknowledgment is sent back from the replica all the way to the proxy with steps 5 to 8.

The application only gets the acknowledgment from the write after durability is achieved with replication to the replica for `WAIT` or `WAITAOF` and to the persistent storage for `WAITAOF` only.

The `WAIT` command always returns the number of replicas that acknowledged the write commands sent by the current client before the `WAIT` command, both in the case where the specified number of replicas are reached, or when the timeout is reached. In Redis Software, the number of replicas for HA enabled databases is always 1.

See the [`WAITAOF`]() command for details for enhanced data safety and durability capabilities introduced with Redis 7.2.


title: Discovery service

title: Overview

text:
The Discovery Service provides an IP-based connection management service
used when connecting to Redis Software databases. When used
in conjunction with Redis Software's other high availability
features, the Discovery Service assists an application scope with
topology changes such as adding, removing of nodes, node failovers and
so on. It does this by providing your application with the ability to
easily discover which node hosts the database endpoint. The API used for
discovery service is compliant with the Redis Sentinel API.

Discovery Service is an alternative for applications that do not want to
depend on DNS name resolution for their connectivity. Discovery Service
and DNS based connectivity are not mutually exclusive. They can be used
side by side in a given cluster where some clients can use Discovery
Service based connection while others can use DNS name resolution when
connecting to databases.

title: How discovery service works

text:
The Discovery Service is available for querying on each node of the
cluster, listening on port 8001. To employ it, your application utilizes
a [Redis Sentinel enabled client
library]()
to connect to the Discovery Service and request the endpoint for the
given database. The Discovery Service replies with the database's
endpoint for that database. In case of a node failure, the Discovery
Service is updated by the cluster manager with the new endpoint and
clients unable to connect to the database endpoint due to the failover,
can re-query the discovery service for the new endpoint for the
database.

The Discovery Service can return either the internal or external
endpoint for a database. If you query the discovery service for the
endpoint of a database named "db1", the Discovery Service returns
the external endpoint information by default. If only an internal
endpoint exists with no external endpoint the default behavior is to
return the internal endpoint. The "\@internal" is added to the end of
the database name to explicitly ask for the internal endpoint. to query
the internal endpoint explicitly with database name "db1", you can pass
in the database name as "db1\@internal".

If you'd like to examine the metadata returned from Redis Software Discovery Service you can connect to port 8001 with redis-cli
utility and execute "SENTINEL masters". Following is a sample output
from one of the nodes of a Redis Software cluster:

[code example]

It is important to note that, the Discovery Service is not a full
implementation of the [Redis Sentinel
protocol](). There are aspects of the
protocol that are not applicable or would be duplication with existing
technology in Redis Software. The Discovery Service
implements only the parts required to provide applications with easy
High Availability, be compatible with the protocol, and not rely on DNS
to derive which node in the cluster to communicate with.

To use Redis Sentinel, every database name must be unique across the cluster.

title: Redis client support

text:
We recommend these clients that are tested for use with the [Discovery Service]() that uses the Redis Sentinel API:

Redis Sentinel API can return endpoints for both master and replica
endpoints.
Discovery Service only supports master endpoints and does not
support returning replica endpoints for a database.

section_id: how-discovery-service-works


title: Durability and high availability

summary: Overview of Redis Software durability features such as replication, clustering, and rack-zone awareness.

title: Database clustering

title: Consistency during replication

title: Discovery service

title: Database replication

title: Overview

text: Redis Software comes with several features that make your data more durable and accessible. The following features can help protect your data in cases of failures or outages and help keep your data available when you need it.

title: Replication

text: When you [replicate your database](), each database instance (primary shard) is copied to a replica shard. When a primary shard fails, the cluster automatically promotes a replica shard to primary.

title: Clustering

text: [Clustering]() (or sharding) breaks your database into individual instances (shards) and spreads them across several nodes. Clustering lets you add resources to your cluster to scale your database and prevents node failures from causing availability loss.

title: Database persistence

text: [Database persistence]() gives your database durability against process or server failures by saving data to disk at set intervals.

title: Active-Active geo-distributed replication

text: [Active-Active Redis Software databases]() allow reading and writing to the same dataset from multiple clusters in different geographic locations. This increases the durability of your database by reducing the likelihood of data or availability loss. It also reduces data access latency by serving requests from the nearest cluster.

title: Rack-zone awareness

text: [Rack-zone awareness]() maps each node in your Redis Software cluster to a physical rack or logical zone. The cluster uses this information to distribute primary shards and their replica shards in different racks or zones. This ensures data availability if a rack or zone fails.

title: Discovery service

text: The [discovery service]() provides an IP-based connection management service used when connecting to Redis Software databases. It lets your application discover which node hosts the database endpoint. The discovery service API complies with the [Redis Sentinel API](#sentinel-api).


title: Database replication

title: Overview

text:
Database replication helps ensure high availability.
When replication is enabled, your dataset is replicated to a replica shard,
which is constantly synchronized with the primary shard. If the primary
shard fails, an automatic failover happens and the replica shard is promoted.  That is, it becomes the new primary shard.

When the old primary shard recovers, it becomes
the replica shard of the new primary shard. This auto-failover mechanism
guarantees that data is served with minimal interruption.

You can tune your high availability configuration with:

- [Rack/Zone
Awareness]() - When rack-zone awareness is used additional logic ensures that master and replica shards never share the same rack, thus ensuring availability even under loss of an entire rack.
- [High Availability for Replica Shards]() - When high availability
for replica shards is used, the replica shard is automatically migrated on node failover to maintain high availability.

Enabling replication has implications for the total database size,
as explained in [Database memory limits]().

title: Auto Tiering replication considerations

text:
We recommend that you set the sequential replication feature using
`rladmin`. This is due to the potential for relatively slow replication
times that can occur with Auto Tiering enabled databases. In some
cases, if sequential replication is not set up, you may run out of memory.

While it does not cause data loss on the
primary shards, the replication to replica shards may not succeed as long
as there is high write-rate traffic on the primary and multiple
replications at the same time.

The following `rladmin` command sets the number of primary shards eligible to
be replicated from the same cluster node, as well as the number of replica
shards on the same cluster node that can run the replication process at
any given time.

The recommended sequential replication configuration is two, i.e.:

[code example]

This means that at any given time,
only one primary and one replica can be part of a full sync replication process.

title: Database replication backlog

text:
Redis databases that use [replication for high availability]() maintain a replication backlog (per shard) to synchronize the primary and replica shards of a database.
By default, the replication backlog is set to one percent (1%) of the database size divided by the database number of shards and ranges between 1MB to 250MB per shard.
Use the [`rladmin`]() and the [`crdb-cli`]() utilities to control the size of the replication backlog. You can set it to `auto` or set a specific size.

The syntax varies between regular and Active-Active databases.

For a regular Redis database:
[code example]

For an Active-Active database:
[code example]

title: Active-Active replication backlog

text:
In addition to the database replication backlog, Active-Active databases maintain a backlog (per shard) to synchronize the database instances between clusters.
By default, the Active-Active replication backlog is set to one percent (1%) of the database size divided by the database number of shards, and ranges between 1MB to 250MB per shard.
Use the [`crdb-cli`]() utility to control the size of the CRDT replication backlog. You can set it to `auto` or set a specific size:

[code example]

**For Redis Software versions earlier than 6.0.20:**
The replication backlog and the CRDT replication backlog defaults are set to 1MB and cannot be set dynamically with 'auto' mode.
To control the size of the replication log, use [`rladmin`]() to tune the local database instance in each cluster.
[code example]

code: rladmin tune cluster max_redis_forks 1 max_slave_full_syncs 1

section_id: auto-tiering-replication-considerations

code: rladmin tune db <db:id | name> repl_backlog <Backlog size in MB | 'auto'>

section_id: database-replication-backlog

code: crdb-cli crdb update --crdb-guid <crdb_guid> --default-db-config "{\"repl_backlog_size\": <size in MB | 'auto'>}"

code: crdb-cli crdb update --crdb-guid <crdb_guid> --default-db-config "{\"crdt_repl_backlog_size\": <size in MB | 'auto'>}"

section_id: active-active-replication-backlog

code: rladmin tune db <db:id | name> repl_backlog <Backlog size in MB (or if ending with bytes, KB or GB, in the respective unit)>


title: Redis Flex and Auto Tiering

summary: Redis Flex and Auto Tiering enable your data to span both RAM and dedicated flash memory.

summary: Get started with Redis Flex and Auto Tiering quickly, creating a cluster and database using flash storage.

title: Redis Flex and Auto Tiering quick start

summary: Manage the storage engine used for your database with auto tiering enabled.

title: Manage Auto Tiering storage engine

title: Overview

text:
Redis Flex and Auto Tiering in Redis Software enable databases to use solid state drives (SSDs) to extend beyond DRAM capacity.
Developers can build applications that require large datasets using the same Redis API.
Using SSDs can significantly reduce the infrastructure costs compared to only DRAM deployments.

Frequently used data, called hot data, belongs in the fastest memory level to deliver a real-time user experience.
Data that is accessed less frequently, called warm data, can be kept in a slightly slower memory tier.
Redis Flex maintains hot data in DRAM, keeps warm data in SSDs, and transfers data between tiers automatically.

Redis Flex is based on a high-performance storage engine (Speedb) that manages the complexity of using SSDs and DRAM as the total available memory for databases in a Redis Software cluster. This implementation offers a performance boost of up to 10k operations per second per core of the database, doubling the performance of Redis on Flash.

Just like all-RAM databases, Redis Flex databases are compatible with existing Redis applications.

Redis Flex is also supported on [Redis Cloud]() and [Redis Enterprise Software for Kubernetes]().

title: Redis Flex versus Auto Tiering

text:
Redis Flex is the enhanced successor to Auto Tiering, generally available as of Redis Software version 8.0.2.

Redis database versions support Redis Flex and Auto Tiering as follows:

| Redis database version | Redis Flex | Auto Tiering |
|------------------------|------------|--------------|
| 8.0 and later | ✅ | ❌ |
| 7.4 | ✅ | ✅|
| 7.2 and earlier | ❌ | ✅ |

Redis Flex requires the Speedb driver, while Auto Tiering can use either RocksDB or Speedb. See [Manage Auto Tiering storage engine]() for more information.

title: Use cases

text:
The benefits associated with Redis Flex are dependent on the use case.

Redis Flex is ideal when your:

- working set is significantly smaller than your dataset (high RAM hit rate)
- average key size is smaller than average value size
- most recent data is the most frequently used (high RAM hit rate)

Redis Flex is not recommended for:

- Broad access patterns (any value could be pulled into RAM)
- Large working sets (working set is stored in RAM)
- Frequently moved data (moving to and from RAM too often can impact performance)

Redis Flex is not intended to be used for persistent storage. Redis Software database persistent and ephemeral storage should be on different disks, either local or attached.

title: Where is my data?

text:
When using Redis Flex, RAM storage holds:
- Key indexes
- Dictionaries
- Hot data (working set), including frequently accessed keys and values

All data is accessed through RAM. If a key or value in flash memory is accessed, it becomes part of the working set and is moved to RAM. This data is referred to as "hot data".

Inactive or infrequently accessed data is referred to as "warm data" and stored in flash memory. When more space is needed in RAM, warm keys and values are moved from RAM to flash storage.

 When using Auto Tiering with Redis Search, indexes are also stored in RAM. Redis Flex does not support Redis Search.

title: RAM to Flash ratio

text:
Redis Software allows you to configure and tune the ratio of RAM-to-Flash for each database independently, optimizing performance for your specific use case.
While this is an online operation requiring no downtime for your database, it is recommended to perform it during maintenance windows as data might move between tiers (RAM <-> Flash).

The RAM limit cannot be smaller than 10% of the total memory. We recommend you keep at least 20% of all values in RAM. Do not set the RAM limit to 100%.

title: Flash memory

text:
Implementing Redis Flex requires pre planning around memory and sizing. Considerations and requirements for Redis Flex include:

- Flash memory must be locally attached. Using network-attached storage (NAS), storage area networks (SAN), or solutions such as AWS Elastic Block Storage (EBS) is not supported.
- Flash memory must be dedicated to Redis Flex and not shared with other parts of the database, such as durability, binaries, or persistence.
- For the best performance, the SSDs should be NVMe based, but SATA can also be used.
- The available flash space must be greater than or equal to the total database size (RAM+Flash). The extra space accounts for write buffers and [write amplification](https://en.wikipedia.org/wiki/Write_amplification).

 The Redis Software database persistent and ephemeral storage should be on different disks, either local or attached.

After these requirements are met, you can create and manage both Redis Flex databases and
all-RAM databases in the same cluster.

When you begin planning the deployment of a Redis Flex database in production,
we recommend working closely with the Redis technical team for sizing and performance tuning.

title: Cloud environments

text:
When running in a cloud environment:

- Flash memory is on the ephemeral SSDs of the cloud instance (for example the local NVMe of AWS i4i instances and Azure Lsv2 and Lsv3 series).
- Persistent database storage needs to be network attached (for example, AWS EBS for AWS).

We specifically recommend "[Storage Optimized I4i - High I/O Instances](https://aws.amazon.com/ec2/instance-types/#storage-optimized)" because of the performance of NVMe for flash memory.

title: On-premises environments

text:
When you begin planning the deployment of Redis Flex in production, we recommend working closely with the Redis technical team for sizing and performance tuning.

On-premises environments support more deployment options than other environments.

The following table shows which data types and features are supported for Flex and Auto Tiering:

| Data type/feature | Flex support | Auto Tiering support |
|-------------------|--------------|----------------------|
| [Active-Active databases]() | ❌ |✅ Requires Redis
technical team's approval |
| [JSON]() | ✅ | ✅ |
| [Probabilistic data structures]() | ✅ | ✅ |
| [Redis Search]() | ❌ | ✅ |
| Standard [Redis data types]() | ✅ | ✅ |
| [Time series]() | ❌ | ✅ |

 Redis Flex is not supported running on network attached storage (NAS), storage area network (SAN), or with local HDD drives.

title: Size limits for keys and values

text:
Redis Flex databases cannot store keys or values larger than 4GB in flash storage.

Keys or values larger than 4GB will be stored in RAM only, and warnings will appear in the Redis logs similar to:

[code example]

title: Next steps

text:
- [Redis Flex metrics]()
- [Redis Flex quick start]()

- [Ephemeral and persistent storage]()
- [Hardware requirements]()

code: # WARNING: key too big for disk driver, size: 4703717276, key: subactinfo:htable

section_id: size-limits-for-keys-and-values


title: Redis Flex and Auto Tiering quick start

title: Overview

text:
This page guides you through a quick setup of [Redis Flex and Auto Tiering]() with a single node for testing and demo purposes.

For production environments, you can find more detailed installation instructions in the [install and setup]() section.

The steps to set up a Redis Software cluster using Redis Flex
with a single node are:

1. Install Redis Software or run it in a Docker
    container.
1. Set up a Redis Software cluster with Redis Flex.
1. Create a new database with Redis Flex enabled.
1. Connect to your new database.

title: Install Redis Software

role: setup

title: Bare metal, VM, Cloud instance

text:
To install on bare metal, a virtual machine, or an instance:

1. Download the binaries from the [Redis Software download center](https://cloud.redis.io/#/sign-up/software?direct=true).

1. Upload the binaries to a Linux-based operating system.

1. Extract the image:

    [code example]

1. After the `tar` command completes, you can find a new `install.sh` script in the current directory:

    [code example]

title: Docker-based installation {#dockerbased-installation}

text:
For testing purposes, you can run a Redis Software
Docker container on Windows, MacOS, and Linux.

[code example]

title: Prepare and format flash memory

text:
After you [install Redis Software](#install-redis-enterprise-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: Set up a cluster and enable Redis Flex

text:
1. Direct your browser to `https://localhost:8443` on the host machine to
see the Redis Software Cluster Manager UI.

Depending on your browser, you may see a certificate error.
Choose "continue to the website" to go to the setup screen.

1. Select **Create new cluster**.

1. Set up account credentials for a cluster administrator, then select **Next** to proceed to cluster setup.

1. Enter your cluster license key if you have one. Otherwise, the cluster uses the trial version.

1. Provide a cluster FQDN such as `mycluster.local`, then select **Next**.

1. In the **Storage configuration** section, turn on the **Enable flash storage** toggle.

1. Select **Create cluster**.

1. Select **OK** to confirm that you are aware of the replacement of the HTTPS TLS
certificate on the node, and proceed through the browser warning.

title: Create a database

text:
On the **Databases** screen:

1. Select **Quick database**.

1. Verify **Flash** is selected for **Runs on**.

1. Enter `12000` for the endpoint **Port** number.

1. _(Optional)_ Select **Full options** to see available alerts.

1. Select **Create**.

You now have a database with Redis Flex enabled!

title: Connect to your database

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

title: Next steps

text: To see the true performance and scale of Redis Flex, you must tune your I/O path and set the flash path to the mounted path of SSD or NVMe flash memory as that is what it is designed to run on. For more information, see [Redis Flex and Auto Tiering]().

code: tar -vxf <downloaded tar file name>

section_id: bare-metal-vm-cloud-instance

code: sudo ./install.sh -y

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

section_id: prepare-and-format-flash-memory

code: sudo lsblk


title: Manage Auto Tiering storage engine

title: Manage the storage engine

text:
Auto Tiering supports two storage engines:

- Speedb: Redis proprietary storage engine. The default and recommended storage engine as of Redis Software version 7.2.4.

- [RocksDB](https://rocksdb.org/): Used up to Redis version 6.2. Deprecated for later Redis versions.

Redis Flex supports Speedb only.

Switching between storage engines requires guidance by Redis Support or your Account Manager.

title: Change the storage engine

text:
1. Change the cluster level configuration for default storage engine.

  * API:

      [code example]

  * CLI:

      [code example]

2. Restart the each database on the cluster one by one.

     [code example]

 We recommend restarting your database at times with low usage and avoiding peak hours. For databases without persistence enabled, we also recommend using export to backup your database first.

title: Monitor the storage engine

text:
To get the current cluster level default storage engine run:

* Use the `rladmin info cluster` command look for ‘bigstore_driver’.

* Use the REST API:

     [code example]

Versions of Redis Software 7.2 and later provide a metric called `bdb_bigstore_shard_count` to help track the shard count per database, filtered by `bdb_id` and by storage engine as shown below:

  [code example]

For more about metrics for Redis Software’s integration with Prometheus, see [Prometheus integration]().

code: curl -k -u <username>:<password> -X PUT -H "Content-Type: application/json" -d '{"bigstore_driver":"speedb"}' https://localhost:9443/v1/cluster

section_id: change-the-storage-engine

code: rladmin cluster config bigstore_driver {speedb | rocksdb}

code: rladmin restart db { db:<id> | <name> }

code: curl -k -u <username>:<password> -X GET -H "Content-Type: application/json" https://localhost:9443/v1/cluster

section_id: monitor-the-storage-engine

code:
bdb_bigstore_shard_count{bdb="1",cluster="mycluster.local",driver="rocksdb"} 1.0
  bdb_bigstore_shard_count{bdb="1",cluster="mycluster.local",driver="speedb"} 2.0


title: Export data from a database

summary: You can export data to import it into a new database or to make a backup. This article shows how to do so.

title: Overview

text:
You can export the data from a specific database at any time.  The following destinations are supported:

- FTP server
- SFTP server
- Amazon AWS S3
- Local mount point
- Azure Blob Storage
- Google Cloud Storage

If you export a database configured for database clustering, export files are created for each shard.

title: Storage space requirements

text:
Before exporting data, verify that you have enough space available in the storage destination and on the local storage associated with the node hosting the database.

Export is a two-step process: a temporary copy of the data is saved to the local storage of the node and then copied to the storage destination.  (The temporary file is removed after the copy operation.)

Export fails when there isn't enough space for either step.

title: Export database data

text:
To export data from a database using the Cluster Manager UI:

1. On the **Databases** screen, select the database from the list, then select **Configuration**.

1. Click  to open a list of additional actions.

1. Select **Export**.

1.  Select the tab that corresponds to your storage location type and enter the location details.

    See [Supported storage locations](#supported-storage-locations) for more information about each storage location type.

1.  Select **Export**.

title: Supported storage locations {#supported-storage-locations}

text:
Data can be exported to a local mount point, transferred to [a URI](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier) using FTP/SFTP, or stored on cloud provider storage.

When saved to a local mount point or a cloud provider, export locations need to be available to [the group and user]() running Redis Software, `redislabs:redislabs` by default.

Redis Software needs the ability to view permissions and update objects in the storage location. Implementation details vary according to the provider and your configuration. To learn more, consult the provider's documentation.

The following sections provide general guidelines.  Because provider features change frequently, use your provider's documentation for the latest info.

title: FTP server

text:
Before exporting data to an FTP server, verify that:

- Your Redis Software cluster can connect and authenticate to the FTP server.
- The user specified in the FTP server location has permission to read and write files to the server.

To export data to an FTP server, set **Path** using the following syntax:

[code example]

Where:

- *protocol*: the server's protocol, can be either `ftp` or `ftps`.
- *username*: your username, if needed.
- *password*: your password, if needed.
- *hostname*: the hostname or IP address of the server.
- *port*: the port number of the server, if needed.
- *path*: the export destination path, if needed.

Example: `ftp://username:password@10.1.1.1/home/exports/`

title: Local mount point

text:
Before exporting data to a local mount point, verify that:

- The node can connect to the server hosting the mount point.
- The `redislabs:redislabs` user has permission to read and write files to the local mount point and to the destination server.
- The export location has enough disk space for your exported data.

To export to a local mount point:

1. On each node in the cluster, create the mount point:
    1. Connect to the node's terminal.
    1. Mount the remote storage to a local mount point.

        For example:

        [code example]

1. In the path for the export location, enter the mount point.

    For example: `/mnt/Public`

title: SFTP server

text:
Before exporting data to an SFTP server, make sure that:

- Your Redis Software cluster can connect and authenticate to the SFTP server.
- The user specified in the SFTP server location has permission to read and write files to the server.
- The SSH private keys are specified correctly.  You can use the key generated by the cluster or specify a custom key.

    To use the cluster auto generated key:

    1. Go to **Cluster > Security > Certificates**.

    1. Expand **Cluster SSH Public Key**.

    1. Download or copy the cluster SSH public key to the appropriate location on the SFTP server.

        Use the server documentation to determine the appropriate location for the SSH public key.

To export data to an SFTP server, enter the SFTP server location in the format:

[code example]

Where:

- *username*: your username, if needed.
- *password*: your password, if needed.
- *hostname*: the hostname or IP address of the server.
- *port*: the port number of the server, if needed.
- *path*: the export destination path, if needed.

For example: `sftp://username:password@10.1.1.1/home/exports/`

title: AWS Simple Storage Service

text:
To export data to an [Amazon Web Services](https://aws.amazon.com/) (AWS) Simple Storage Service (S3) bucket:

1. Sign in to the [AWS console](https://console.aws.amazon.com/).

1. [Create an S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-buckets-s3.html) if you do not already have one.

1. [Create an IAM User](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) with permission to add objects to the bucket.

1. [Create an access key](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) for that user if you do not already have one.

1. In the Redis Software Cluster Manager UI, when you enter the export location details:

    - Select **AWS S3**.

    - In the **Path** field, enter the path of your bucket.

    - In the **Access key ID** field, enter the access key ID.

    - In the **Secret access key** field, enter the secret access key.

You can also connect to a storage service that uses the S3 protocol but is not hosted by Amazon AWS. The storage service must have a valid SSL certificate.

To connect to an S3-compatible storage location:

1. Configure the S3 URL with [`rladmin cluster config`]():

    [code example]

    Replace `<URL>` with the hostname or IP address of the S3-compatible storage location.

1. Configure the S3 CA certificate:

    [code example]

    Replace `<filepath>` with the location of the S3 CA certificate `ca.pem`.

title: Google Cloud Storage

text:
To export to a [Google Cloud](https://developers.google.com/console/) storage bucket:

1. Sign in to the Google Cloud console.

1. [Create a JSON service account key](https://cloud.google.com/iam/docs/creating-managing-service-account-keys#creating) if you do not already have one.

1. [Create a bucket](https://cloud.google.com/storage/docs/creating-buckets#create_a_new_bucket) if you do not already have one.

1. [Add a principal](https://cloud.google.com/storage/docs/access-control/using-iam-permissions#bucket-add) to your bucket:

    - In the **New principals** field, add the `client_email` from the service account key.

    - Select "Storage Legacy Bucket Writer" from the **Role** list.

1. In the Redis Software Cluster Manager UI, when you enter the export location details:

    - Select **Google Cloud Storage**.

    - In the **Path** field, enter the path of your bucket.

    - In the **Client ID** field, enter the `client_id` from the service account key.

    - In the **Client Email** field, enter the `client_email` from the service account key.

    - In the **Private Key ID** field, enter the `private_key_id` from the service account key.

    - In the **Private key** field, enter the `private_key` from the service account key.
      Replace `\n` with new lines.

title: Azure Blob Storage

text:
To export to Microsoft Azure Blob Storage, sign in to the Azure portal and then:

1. [Create an Azure Storage account](https://docs.microsoft.com/en-us/azure/storage/common/storage-account-create) if you do not already have one.

1. [Create a container](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-quickstart-blobs-portal#create-a-container) if you do not already have one.

1. [Manage storage account access keys](https://docs.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage) to find the storage account name and account keys.

1. In the Redis Software Cluster Manager UI, when you enter the export location details:

    - Select **Azure Blob Storage**.

    - In the **Path** field, enter the path of your bucket.

    - In the **Account name** field, enter your storage account name.

    - In the **Account key** field, enter the storage account key.

To learn more, see [Authorizing access to data in Azure Storage](https://docs.microsoft.com/en-us/azure/storage/common/storage-auth).

section_id: ftp-server

code: sudo mount -t nfs 192.168.10.204:/DataVolume/Public /mnt/Public

section_id: local-mount-point

section_id: sftp-server

code: rladmin cluster config s3_url <URL>

section_id: aws-simple-storage-service

code: rladmin cluster config s3_ca_cert <filepath>