Overview

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.

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.

Configure cluster policy for replica HA

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]

Turn off replica HA for a database

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.

Configuration options

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

[code example]

Grace period

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]

Shard priority

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.

Cooldown periods

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]

Alerts

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.

Limitations

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

rladmin tune cluster slave_ha { enabled | disabled }

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

rladmin tune db db:<ID> slave_ha disabled

rladmin tune cluster slave_ha_grace_period <time_in_seconds>

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

rladmin tune cluster slave_ha_cooldown_period <time_in_seconds>

rladmin tune cluster slave_ha_bdb_cooldown_period <time_in_seconds>


Configure shard placement

Summary: Configure shard placement to improve performance.

Overview

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.

Default shard placement policy

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]

Shard placement policy for a database

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

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

[code example]

rladmin tune cluster default_shards_placement [ dense | sparse ]

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


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.

Supported connection clients

Test client connection

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

Troubleshooting pocket guide for Redis Software

Overview

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]().

Connect to a database

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]().

Continue learning with Redis University

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


Supported connection clients

Overview

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

Redis client libraries

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`]()

Discovery service

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.


Test client connection

Overview

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/).

Test database connections

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.

Connect with redis-cli

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]().

Connect with Redis Insight

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.

Connect with Python

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]

Connect with discovery service

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

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'))

set key1 123
    True
    get key1
    123

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'))


Overview

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

Identify Redis host issues

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

Identify issues caused by security hardening

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

Identify cluster issues

- 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]

Troubleshoot connectivity

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

Troubleshoot latency

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

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

$ 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

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

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

$ 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

$ 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

$ rladmin cluster running_actions
    No active tasks

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

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

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

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

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

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

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


Create a Redis Software database

Summary: Create a database with Redis Software.

Overview

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

Cluster Manager UI method

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.

Quick database

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

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

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

REST API method

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

[code example]

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

Continue learning with Redis University

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


Delete databases

Summary: Delete a database from the Cluster Manager UI.

Content

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.


Database clustering

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

Overview

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.

Terminology

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.

When to use clustering (sharding)

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.

Number of shards

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.

Supported hashing policies

Standard hashing policy

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.

Custom hashing policy

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.

Custom hashing policy notes and limitations

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.

Change the hashing policy

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.

Multi-key operations {#multikey-operations}

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.


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.

Overview

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.

Non-blocking Redis write operation

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.

Blocking write operation on replication

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.


Discovery service

Overview

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.

How discovery service works

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.

Redis client support

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.


Durability and high availability

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

Database clustering

Consistency during replication

Discovery service

Database replication

Overview

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.

Replication

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.

Clustering

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

Database persistence

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

Active-Active geo-distributed replication

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

Rack-zone awareness

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

Discovery service

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


Database replication

Overview

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]().

Auto Tiering replication considerations

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.

Database replication backlog

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]

Active-Active replication backlog

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]

rladmin tune cluster max_redis_forks 1 max_slave_full_syncs 1

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

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

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

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


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.

Redis Flex and Auto Tiering quick start

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

Manage Auto Tiering storage engine

Overview

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]().

Redis Flex versus Auto Tiering

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.

Use cases

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.

Where is my data?

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.

RAM to Flash ratio

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

Flash memory

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.

Cloud environments

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.

On-premises environments

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.

Size limits for keys and values

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]

Next steps

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

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

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


Redis Flex and Auto Tiering quick start

Overview

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.

Install Redis Software

Bare metal, VM, Cloud instance

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]

Docker-based installation {#dockerbased-installation}

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

[code example]

Prepare and format flash memory

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]

Set up a cluster and enable Redis Flex

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.

Create a database

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!

Connect to your database

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

Next steps

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]().

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


Manage Auto Tiering storage engine

Manage the storage engine

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.

Change the storage engine

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.

Monitor the storage engine

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]().

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

rladmin cluster config bigstore_driver {speedb | rocksdb}

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

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


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.

Overview

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.

Storage space requirements

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.

Export database data

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

Supported storage locations {#supported-storage-locations}

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.

FTP server

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/`

Local mount point

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`

SFTP server

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/`

AWS Simple Storage Service

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

Google Cloud Storage

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.

Azure Blob Storage

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

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

rladmin cluster config s3_ca_cert <filepath>


Flush database data

Summary: To delete the data in a database without deleting the database, you can use Redis CLI to flush it from the database. Learn how to flush data from standard databases, OSS Cluster API databases, and Active-Active databases using Redis CLI, the Cluster Manager UI, and the Redis Software REST API.

Overview

To delete the data in a database without deleting the database configuration,
you can flush the data from the database.

You can use the Cluster Manager UI to flush data from Active-Active databases.

The flush command deletes ALL in-memory and persistence data in the database.
We recommend that you [back up your database]() before you flush the data.

Flush data from a database

From the command line, you can flush a database with the redis-cli command or with your favorite Redis client.

To flush data from a database with the redis-cli, run:

[code example]

Example:

[code example]

Port 9443 is the default [port configuration]().

Flush data from an OSS Cluster API database

When using the OSS Cluster API, the `FLUSHDB` command only flushes the keys of the shard you're connected to, not all keys in the database. To flush all data from an OSS Cluster API database, you need to connect to each endpoint IP address and run the flush command.

Follow these steps to flush all data from an OSS Cluster API database:

1. Find all IP addresses associated with the database endpoint using the `dig` command:

   [code example]

2. Connect to each IP address using [`redis-cli`]() and run the [`FLUSHDB`]() command:

   [code example]

Example

1. Find all IP addresses for the database endpoint:

   [code example]

2. Connect to each IP address and flush the data:

   [code example]

This ensures that all shards in the OSS Cluster API database are flushed properly.

Flush data from an Active-Active database

When you flush an Active-Active database (formerly known as CRDB), all of the replicas flush their data at the same time.

To flush data from an Active-Active database, use one of the following methods:

- Cluster Manager UI

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

    1. Click  to open a list of additional actions.

    1. Select **Flush database**.

    1. Enter the name of the Active-Active database to confirm that you want to flush the data.

    1. Click **Flush**.

- Command line

    1. To find the ID of the Active-Active database, run:

        [code example]

        For example:

        [code example]

    1. To flush the Active-Active database, run:

        [code example]

        The command output contains the task ID of the flush task, for example:

        [code example]

    1. To check the status of the flush task, run:

        [code example]

        For example:

        [code example]

- REST API

    1. To find the ID of the Active-Active database, use [`GET /v1/crdbs`]():

        [code example]

    1. To flush the Active-Active database, use [`PUT /v1/crdbs/{guid}/flush`]():

        [code example]

        The command output contains the task ID of the flush task.

    1. To check the status of the flush task, use [`GET /v1/crdb_tasks`]():

        [code example]

redis-cli -h <hostname> -p <portnumber> -a <password> flushall

redis-cli -h redis-12345.cluster.local -p 9443 -a xyz flushall

redis-cli -h <ip-address> -p <port> flushdb

$ dig +noall +answer redis-19674.test2f4e15b0.cs.redislabs.com
   redis-19674.test2f4e15b0.cs.redislabs.com. 5 IN A 192.0.2.0
   redis-19674.test2f4e15b0.cs.redislabs.com. 5 IN A 198.51.100.0

$ crdb-cli crdb list
        CRDB-GUID                                NAME                 REPL-ID CLUSTER-FQDN
        a16fe643-4a7b-4380-a5b2-96109d2e8bca     crdb1                1       cluster1.local
        a16fe643-4a7b-4380-a5b2-96109d2e8bca     crdb1                2       cluster2.local
        a16fe643-4a7b-4380-a5b2-96109d2e8bca     crdb1                3       cluster3.local

crdb-cli crdb flush --crdb-guid <CRDB-GUID>

$ crdb-cli crdb flush --crdb-guid a16fe643-4a7b-4380-a5b2-96109d2e8bca
        Task 63239280-d060-4639-9bba-fc6a242c19fc created
        ---> Status changed: queued -> started

crdb-cli task status --task-id <Task-ID>

$ crdb-cli task status --task-id 63239280-d060-4639-9bba-fc6a242c19fc
        Task-ID: 63239280-d060-4639-9bba-fc6a242c19fc
        CRDB-GUID: -
        Status: finished


Import data into a database

Summary: You can import export or backup files of a specific Redis Software database to restore data. You can either import from a single file or from multiple files, such as when you want to import from a backup of a clustered database.

Overview

You can import, [export](),
or [backup]()
files of a specific Redis Software database to restore data.
You can either import from a single file or from multiple files,
such as when you want to import from a backup of a clustered database.

Importing data erases all existing content in the database.

Import data into a database

Cluster Manager UI method

To import data into 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 **Import**.
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 **Import**.

REST API method

To import data into a database using the REST API, send an [import database request]():

[code example]

- Replace `<database-id>` with the destination database's ID.

- Replace the data source's `<location-type>` with the relevant value from the following options:

    | Location type | "type" value |
    |---------------|--------------|
    | FTPS | "url" |
    | SFTP | "sftp" |
    | Amazon S3 | "s3" |
    | Google Cloud Storage | "gs" |
    | Microsoft Azure Storage | "abs" |
    | NAS/Local Storage | "mount_point" |

See the following storage location sections for REST API request examples for each location type.

Supported storage locations {#supported-storage-services}

Data can be imported from 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 importing from a local mount point or a cloud provider, import locations need to be available to [the group and user]() running Redis Software, `redislabs:redislabs` by default.

Redis Software needs the ability to view 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.

FTP server

Before importing data from an FTP server, make sure that:

- Your Redis Software cluster can connect and authenticate to the FTP server.
- The user that you specify in the FTP server location has permission to read files from the server.

To import data from an FTP server, set **RDB file path/s** 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 file's location path.
- *filename*: the name of the file.

Example: `ftp://username:password@10.1.1.1/home/backups/<filename>.rdb`

Select **Add path** to add another import file path.

Example [import database REST API request]():

[code example]

Local mount point

Before importing data from a local mount point, make sure that:

- The node can connect to the server hosting the mount point.

- The `redislabs:redislabs` user has permission to read files on the local mount point and on the destination server.

- You must mount the storage in the same path on all cluster nodes. You can also use local storage, but you must copy the imported files manually to all nodes because the import source folders on the nodes are not synchronized.

To import from 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 import location, enter the mount point.

    For example: `/mnt/Public/<filename>.rdb`

As of version 6.2.12, Redis Software reads files directly from the mount point using a [symbolic link](https://en.wikipedia.org/wiki/Symbolic_link) (symlink) instead of copying them to a temporary directory on the node.

Select **Add path** to add another import file path.

Example [import database REST API request]():

[code example]

SFTP server

Before importing data from an SFTP server, make sure that:

- Your Redis Software cluster can connect and authenticate to the SFTP server.
- The user that you specify in the SFTP server location has permission to read files from 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 import data from an SFTP server, enter the SFTP server location in the format:

[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 file's location path.
- *filename*: the name of the file.

Example: `sftp://username:password@10.1.1.1/home/backups/[filename].rdb`

Select **Add path** to add another import file path.

Example [import database REST API request]():

[code example]

AWS Simple Storage Service {#aws-s3}

Before you choose to import data from an [Amazon Web Services](https://aws.amazon.com/) (AWS) Simple Storage Service (S3) bucket, make sure you have:

- The path to the file in your bucket in the format: `s3://[bucketname]/[path]/[filename].rdb`
- [Access key ID and Secret access key](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) for an [IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console) with permission to read files from the bucket.

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

- Select **AWS S3**.

- In the **RDB file path/s** field, enter the path of your bucket. Select **Add path** to add another import file path.

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

Example [import database REST API request]():

[code example]

Google Cloud Storage

Before you import data from a [Google Cloud](https://developers.google.com/console/) storage bucket, make sure you have:

- Storage location path in the format: `/bucket_name/[path]/[filename].rdb`
- A [JSON service account key](https://cloud.google.com/iam/docs/creating-managing-service-account-keys#creating) for your account
- A [principal](https://cloud.google.com/storage/docs/access-control/using-iam-permissions#bucket-add) for your bucket with the `client_email` from the service account key and a [role](https://cloud.google.com/storage/docs/access-control/iam-roles) with permissions to get files from the bucket (such as the **Storage Legacy Object Reader** role, which grants `storage.objects.get` permissions)

In the Redis Software Cluster Manager UI, when you enter the import location details:

- Select **Google Cloud Storage**.

- In the **RDB file path/s** field, enter the path of your file. Select **Add path** to add another import file path.

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

Example [import database REST API request]():

[code example]

Azure Blob Storage

Before you choose to import from Azure Blob Storage, make sure that you have:

- Storage location path in the format: `/container_name/[path/]/<filename>.rdb`
- Account name
- An authentication token, either an account key or an Azure [shared access signature](https://docs.microsoft.com/en-us/rest/api/storageservices/delegate-access-with-shared-access-signature) (SAS).

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

    Azure SAS support requires Redis Software version 6.0.20.  To learn more about Azure SAS, see [Grant limited access to Azure Storage resources using shared access signatures](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview).

In the Redis Software Cluster Manager UI, when you enter the import location details:

- Select **Azure Blob Storage**.

- In the **RDB file path/s** field, enter the path of your file. Select **Add path** to add another import file path.

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

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

Example [import database REST API request]():

[code example]

Importing into an Active-Active database

When importing data into an Active-Active database, there are two options:

- [Flush all data]() from the Active-Active database, then import the data into the database.
- Import data but merge it into the existing database.

Because Active-Active databases have a numeric counter data type,
when you merge the imported data into the existing data RS increments counters by the value that is in the imported data.
The import through the Redis Software Cluster Manager UI handles these data types for you.

You can import data into an Active-Active database [from the Cluster Manager UI](#import-data-into-a-database).
When you import data into an Active-Active database, there is a special prompt warning that the imported data will be merged into the existing database.

Continue learning with Redis University

POST /v1/bdbs/<database-id>/actions/import
{
  "dataset_import_sources": [
    {
      "type": "<location-type>",
      // additional fields, depending on location_type
    },
    {
      "type": "<location-type>",
      // additional fields, depending on location_type
    }
  ]
}

POST /v1/bdbs/<database-id>/actions/import
{
  "dataset_import_sources": [
    {
      "type": "url",
      "url": "ftp://<ftp_user>:<ftp_password>@example.com/<path>/<filename>.rdb.gz"
    }
  ]
}

POST /v1/bdbs/<database-id>/actions/import
{
  "dataset_import_sources": [
    {
      "type": "mount_point",
      "path": "/<path>/<filename>.rdb.gz"
    }
  ]
}

POST /v1/bdbs/<database-id>/actions/import
{
  "dataset_import_sources": [
    {
      "type": "sftp",
      "sftp_url": "sftp://<sftp_user>@example.com/<path>/<filename>.rdb"
    }
  ]
}

POST /v1/bdbs/<database-id>/actions/import
{
  "dataset_import_sources": [
    {
      "type": "s3",
      "bucket_name": "backups",
      "subdir": "test-db",
      "filename": "<filename>.rdb",
      "access_key_id": "XXXXXXXXXXXXX",
      "secret_access_key": "XXXXXXXXXXXXXXXX"
    }
  ]
}

POST /v1/bdbs/<database-id>/actions/import
{
  "dataset_import_sources": [
    {
      "type": "gs",
      "bucket_name": "backups",
      "client_id": "XXXXXXXX",
      "client_email": "cloud-storage-client@my-project-id.iam.gserviceaccount.com",
      "subdir": "test-db",
      "filename": "<filename>.rdb",
      "private_key_id": "XXXXXXXXXXXXX",
      "private_key": "XXXXXXXXXXXXXXXX"
    }
  ]
}

POST /v1/bdbs/<database-id>/actions/import
{
  "dataset_import_sources": [
    {
      "type": "abs",
      "container": "backups",
      "subdir": "test-db",
      "filename": "<filename>.rdb",
      "account_name": "name",
      "account_key": "XXXXXXXXXXXXXXXX" // Or you can use "sas_token": "XXXXXXXXXXXXXXXXXX" instead
    }
  ]
}


Import and export data

Summary: How to import, export, flush, and migrate your data.

Import data into a database

Export data from a database

Flush database data

Summary: Schedule backups of your databases to make sure you always have valid backups.

Schedule periodic backups

Summary: Use Replica Of to migrate your database to an Active-Active database.

Migrate a database to Active-Active

Summary: Replica Of provides read-only access to replicas of the dataset from different geographical locations.

Replica Of geo-distributed Redis


Migrate a database to Active-Active

Overview

If you have data in a single-region Redis Software database that you want to migrate to an [Active-Active database](),
you'll need to create a new Active-Active database and migrate the data into the new database as a [Replica Of]() the existing database.
This process will gradually populate the data in the Active-Active database.

Before data migration starts, all data is flushed from the Active-Active database.
The data is migrated to the Active-Active instance where you configured migration, and the data from that instance is copied to the other Active-Active instances.

When data migration is finished, turn off migration and connect your applications to the Active-Active database.

Prerequisites

- During the migration, any applications that connect to the Active-Active database must be **read-only** to ensure the dataset is identical to the source database during the migration process. However, you can continue to write to the source database during the migration process.

- If you used the mDNS protocol for the cluster name (FQDN),
the [client mDNS prerequisites]() must be met in order to communicate with other clusters.

Migrate from a Redis Software cluster

You can migrate a Redis Software database from the [same cluster](#migrate-from-the-same-cluster) or a [different cluster](#migrate-from-a-different-cluster).

Migrate from the same cluster

To migrate a database to Active-Active in the same Redis Software cluster:

1. Create a new Active-Active database. For prerequisites and detailed instructions, see [Create an Active-Active geo-replicated database]().

1. After the Active-Active database is active, click **Edit** on the **Configuration** screen.

1. Expand the **Migrate to Active-Active** section:

1. Click **+ Add source database**.

1. In the **Migrate to Active-Active** dialog, select **Current cluster**:

1. Select the source database from the list.

1. Click **Add source**.

1. Click **Save**.

Migrate from a different cluster

For a source database on a different Redis Software cluster,
you can [compress the replication data]() to save bandwidth.

To migrate a database to Active-Active in different Redis Software clusters:

1. Sign in to the Cluster Manager UI of the cluster hosting the source database.

    1. In **Databases**, select the source database and then select the **Configuration** tab.

    1. In the **Replica Of** section, select **Use this database as a source for another database**.

    1. Copy the Replica Of source URL.

        To change the internal password, select **Regenerate password**.

        If you regenerate the password, replication to existing destinations fails until their credentials are updated with the new password.

1. Sign in to the Cluster Manager UI of the destination database’s cluster.

1. Create a new Active-Active database. For prerequisites and detailed instructions, see [Create an Active-Active geo-replicated database]().

1. After the Active-Active database is active, click **Edit** on the **Configuration** screen.

1. Expand the **Migrate to Active-Active** section:

1. Click **+ Add source database**.

1. In the **Migrate to Active-Active** dialog, select **External**:

1. For **Source database URL**, enter the Replica Of source URL you copied in step 1.

1. Click **Add source**.

1. Click **Save**.

Migrate from Redis Open Source

To migrate a Redis Open Source database to Active-Active:

1. Create a new Active-Active database. For prerequisites and detailed instructions, see [Create an Active-Active geo-replicated database]().

1. After the Active-Active database is active, click **Edit** on the **Configuration** screen.

1. Expand the **Migrate to Active-Active** section:

1. Click **+ Add source database**.

1. In the **Migrate to Active-Active** dialog, select **External**:

1. Enter the **Source database URL**:

    - If the database has a password:

        [code example]

        Where the password is the Redis password represented with URL encoding escape characters.

    - If the database does not have a password:

        [code example]

1. Click **Add source**.

1. Click **Save**.

Stop sync after migration

1. Wait until the migration is complete, indicated by the **Status** _Synced_.

Migration can take minutes to hours to complete depending on the dataset size and network quality.

1. On the Active-Active database's **Configuration** screen, click **Edit**.

1. In the **Migrate to Active-Active** section, click **Stop sync**:

1. In the **Stop synchronization** dialog, click **Stop** to proceed.

1. Redirect client connections to the Active-Active database after **Status** changes to _Sync stopped_:


Create a database with Replica Of

Summary: Create Replica Of database

Overview

Replica databases copy data from source databases (previously known as _master_), which enable read-only connections from apps and clients located in different geographic locations.

To create a replica connection, you define a database as a replica of a source database.  Replica Of databases (also known as _Active-Passive databases_) synchronize in the background.

Sources databases can be:

- Located in the same Redis Software cluster
- Located in a different Redis Software cluster
- Hosted by a different deployment, e.g. Redis Cloud
- Redis Open Source databases

Your apps can connect to the source database to read and write data; they can also use any replica for read-only access.

Replica Of can model a variety of data relationships, including:

- One-to-many relationships, where multiple replicas copy a single source database.
- Many-to-one relationships, where a single replica collects data from multiple source databases.

When you change the replica status of a database by adding, removing, or changing sources, the replica database is synchronized to the new sources.

Configure Replica Of

You can configure a database as a Replica Of, where the source database is in one of the following clusters:

- [Same Redis Software cluster](#same-cluster)

- [Different Redis Software cluster](#different-cluster)

- [Redis Open Source cluster](#source-available-cluster)

The order of the multiple Replica Of sources has no material impact on replication.

For best results when using the [Multicast DNS](https://en.wikipedia.org/wiki/Multicast_DNS) (mDNS) protocol to resolve the fully-qualified domain name (FQDN) of the cluster, verify that your client connections meet the [client mDNS prerequisites]().

As long as Replica Of is enabled, data in the target database will not expire and will not be evicted regardless of the set [data eviction policy]().

Same Redis Software cluster {#same-cluster}

To configure a Replica Of database in the same Redis Software cluster as the source database:

1. [Create a new database]() or select an existing database from the **Databases** screen.

1. For an existing database, select **Edit** from the **Configuration** tab.

1. Expand the **Replica Of** section.

1. Select **+ Add source database**.

1. In the **Connect a Replica Of source database** dialog, select **Current cluster**.

1. Select the source database from the list.

1. Select **Add source**.

1. Select **Save**.

Different Redis Software cluster {#different-cluster}

To configure a Replica Of database in a different Redis Software cluster from the source database:

1. Ensure the source database's port is allowed through firewalls between the clusters and can be accessed by the destination cluster's nodes.

Ports 10000-19999 are reserved for database traffic. See [Network port configurations]() for more information about ports.

1. Sign in to the Cluster Manager UI of the cluster hosting the source database.

    1. In **Databases**, select the source database and then select the **Configuration** tab.

    1. In the **Replica Of** section, select **Use this database as a source for another database**.

    1. Copy the Replica Of source URL.

        To change the internal password, select **Regenerate password**.

        If you regenerate the password, replication to existing destinations fails until their credentials are updated with the new password.

1. Sign in to the Cluster Manager UI of the destination database's cluster.

1. [Create a new database]() or select an existing database from the **Databases** screen.

1. For an existing database, select **Edit** from the **Configuration** tab.

1. Expand the **Replica Of** section.

1. Select **+ Add source database**.

1. In the **Connect a Replica Of source database** dialog, select **External**.

1. Enter the URL of the source database endpoint.

1. Select **Add source**.

1. Select **Save**.

For source databases on different clusters, you can [compress replication data]() to save bandwidth.

Redis Open Source cluster {#source-available-cluster}

To use a database from a Redis Open Source cluster as a Replica Of source:

1. [Create a new database]() or select an existing database from the **Databases** screen.

1. For an existing database, select **Edit** from the **Configuration** tab.

1. Expand the **Replica Of** section.

1. Select **+ Add source database**.

1. In the **Connect a Replica Of source database** dialog, select **External**.

1. Enter the URL of the source endpoint in one of the following formats:

    - For databases with passwords:

        [code example]

        Where the password is the Redis password represented with URL encoding escape characters.

    - For databases without passwords:

        [code example]

1. Select **Add source**.

1. Select **Save**.

Configure TLS for Replica Of

When you enable TLS for Replica Of, the Replica Of synchronization traffic uses TLS certificates to authenticate the communication between the source and destination clusters.

To encrypt Replica Of synchronization traffic, configure encryption for the [source database](#encrypt-source-database-traffic) and the destination [replica database](#encrypt-replica-database-traffic).

Encrypt source database traffic

Encrypt replica database traffic

To enable TLS for Replica Of in the destination database:

1. From the Cluster Manager UI of the cluster hosting the source database:

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

    1. Expand the **Server authentication (Proxy certificate)** section.

     1. Download or copy the proxy certificate.

1. From the **Configuration** tab of the Replica Of destination database, select **Edit**.

1. Expand the **Replica Of** section.

1. Point to the source database entry and select  to edit it.

1. Paste or upload the source proxy certificate, then select **Done**.

1. Select **Save**.