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

title: Overview

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

title: Flush data from a database

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

title: Flush data from an OSS Cluster API database

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

title: Example

role: example

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

title: Flush data from an Active-Active database

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

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

section_id: flush-data-from-a-database

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

code: dig +noall +answer <database-endpoint>

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

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

section_id: example

code: crdb-cli crdb list

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

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

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

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

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

code: GET https://[host][:port]/v1/crdbs


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

page_type: content

title: Overview

role: overview

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

title: Import data into a database

role: content

title: Cluster Manager UI method

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

title: REST API method

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

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

role: compatibility

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

title: FTP server

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

title: Local mount point

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

title: SFTP server

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

title: AWS Simple Storage Service {#aws-s3}

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

title: Google Cloud Storage

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

title: Azure Blob Storage

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

title: Importing into an Active-Active database

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

title: Continue learning with Redis University

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

section_id: rest-api-method

section_id: ftp-server

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

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

section_id: local-mount-point

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

section_id: sftp-server

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

code: rladmin cluster config s3_url <URL>

code: rladmin cluster config s3_ca_cert <filepath>

code:
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"
    }
  ]
}

code:
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"
    }
  ]
}

section_id: google-cloud-storage

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

section_id: azure-blob-storage


title: Import and export data

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

title: Import data into a database

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

title: Export data from a database

title: Flush database data

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

title: Schedule periodic backups

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

title: Migrate a database to Active-Active

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

title: Replica Of geo-distributed Redis

page_type: index


title: Migrate a database to Active-Active

title: Overview

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

title: Prerequisites

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

title: Migrate from a Redis Software cluster

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

title: Migrate from the same cluster

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

title: Migrate from a different cluster

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

title: Migrate from Redis Open Source

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

title: Stop sync after migration

text:
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_:

section_id: migrate-from-redis-open-source


title: Create a database with Replica Of

summary: Create Replica Of database

title: Overview

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

title: Configure Replica Of

role: configuration

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

title: Same Redis Software cluster {#same-cluster}

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

title: Different Redis Software cluster {#different-cluster}

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

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

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

title: Configure TLS for Replica Of

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

title: Encrypt source database traffic

title: Encrypt replica database traffic

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


title: Replica Of geo-distributed Redis

summary: Create Replica Of database

title: Create a database with Replica Of

summary: Troubleshoot when the Replica Of process repeatedly fails and restarts.

title: Replica Of Repeatedly Fails

title: Overview

text:
In Redis Software, the Replica Of feature provides active-passive geo-distribution to applications  for read-only access
to replicas of the dataset from different geographical locations.
The Redis Software implementation of active-passive replication is called Replica Of.

In Replica Of, an administrator designates a database as a replica (destination) of one or more databases (sources).
After the initial data load from source to destination is completed,
all write commands are synchronized from the sources to the destination.
Replica Of lets you distribute the read load of your application across multiple databases or
synchronize the database, either within Redis Software or external to Redis Software, to another database.

You can [create Active-Passive]() databases on Redis Software or Redis Cloud.

[Active-Active Geo-Distribution (CRDB)]()
provides these benefits and also provides write access to all of the database replicas.

Configuring a database as a replica of the database that it replicates
creates a cyclical replication and is not supported.

The Replica Of is defined in the context of the destination database
by specifying the source databases.

A destination database can have a maximum of thirty-two (32) source
databases.

If only one source is defined, then the command execution order in the
source is kept in the destination. However, when multiple sources are
defined, commands that are replicated from the source databases are
executed in the order in which they reach the destination database. As a
result, commands that were executed in a certain order when compared
across source databases might be executed in a different order on the
destination database.

The Replica Of feature should not be confused with the
in-memory [Database
replication]()
feature, which is used for creating a master / replica configuration that
enables ensuring database high-availability.

title: Replication process

text:
When a database is defined as a replica of another database, all its
existing data is deleted and replaced by data that is loaded from the
source database.

Once the initial data load is completed, an ongoing synchronization
process takes place to keep the destination always synchronized with its
source. During the ongoing synchronization process, there is a certain
delay between the time when a command was executed on the source and
when it is executed on the destination. This delay is referred to as the
**Lag**.

When there is a **synchronization error**, **the process might stop** or
it might continue running on the assumption that the error automatically
resolves. The result depends on the error type. See more details below.

In addition, **the user can manually stop the synchronization process**.

When the process is in the stopped state - whether stopped by the user
or by the system - the user can restart the process. **Restarting the
process causes the synchronization process to flush the DB and restart
the process from the beginning**.

title: Replica Of status

text:
The replication process can have the following statuses:

- **Syncing** - indicates that the synchronization process has
    started from scratch. Progress is indicated in percentages (%).
- **Synced** - indicates that the initial synchronization process was
    completed and the destination is synchronizing changes on an ongoing
    basis. The **Lag** delay in synchronization with the source is
    indicated as a time duration.
- **Sync stopped** - indicates that the synchronization process is
    currently not running and the user needs to restart it in order for
    it to continue running. This status happens if the user stops the
    process, or if certain errors arose that prevent synchronization
    from continuing without manual intervention. See more details below.

The statuses above are shown for the source database. In addition, a
timestamp is shown on the source indicating when the last command from
the source was executed on the destination.

The system also displays the destination database status as an aggregate
of the statuses of all the sources.

If you encounter issues with the Replica Of process, refer
to the troubleshooting section [Replica Of repeatedly
fails]().

title: Synchronization errors

text:
Certain errors that occur during the synchronization process require
user intervention for their resolution. When such errors occur, the
synchronization process is automatically stopped.

For other errors, the synchronization process continues running on the
assumption that the error automatically resolves.

Examples of errors that require user intervention for their resolution
and that stop the synchronization process include:

- Error authenticating with the source database.
- Cross slot violation error while executing a command on a sharded
    destination database.
- Out-of-memory error on a source or on the destination
    database.

Example of an error that does not cause the synchronization process to
stop:

- Connection error with the source database. A connection error might
    occur occasionally, for example as result of temporary network
    issues that get resolved. Depending on the connection error and its
    duration the process might be able to start syncing from the last
    point it reached (partial sync) or require a complete
    resynchronization from scratch across all sources (full sync).

title: Encryption

text:
Replica Of supports the ability to encrypt uni-directional replication
communications between source and destination clusters utilizing TLS 1.2
based encryption.

title: Data compression for Replica Of

text:
When the Replica Of is defined across different Redis Software
Software clusters, it may be beneficial to compress the data that flows
through the network (depending on where the clusters physically reside
and the available network).

Compressing the data reduces the traffic and can help:

- Resolve throughput issues
- Reduce network traffic costs

Compressing the data does have trade-offs, which is why it should not
always be turned on by default. For example:

- It uses CPU and disk resources to compress the data before sending
    it to the network and decompress it on the other side.
- It takes time to compress and decompress the data which can increase
    latency.
- Replication is disk-based and done gradually, shard by shard in the
    case of a multi-shard database. This may have an impact on
    replication times depending on the speed of the disks and load on
    the database.
- If traffic is too fast and the compression takes too much time it
    can cause the replication process to fail and be restarted.

It is advised that you test compression out in a lower environment
before enabling it in production.

In the Redis Software Cluster Manager UI, when designating a
Replica Of source from a different Redis Software cluster,
there is also an option to enable compression. When enabled, gzip
compression with level -6 is utilized.

title: Database clustering (sharding) implications

text:
If a **source** database is sharded, that entire database is treated as
a single source for the destination database.

If the **destination** database is sharded, when the commands replicated
from the source are executed on the destination database, the
destination database's hashing function is executed to determine to
which shard/s the command refers.

The source and destination can have different shard counts and functions
for placement of keys.

title: Synchronization in Active-Passive Replication

text:
In Active-Passive databases, one cluster hosts the source database that receives read-write operations
and the other clusters host destination databases that receive synchronization updates from the source database.

When there is a significant difference between the source and destination databases,
the destination database flushes all of the data from its memory and starts synchronizing the data again.
This process is called a **full sync**.

For example, if the database updates for the destination databases
that are stored by the destination database in a synchronization backlog exceed their allocated memory,
the source database starts a full sync.

When you failover to the destination database for write operations,
make sure that you disable **Replica Of** before you direct clients to the destination database.
This avoids a full sync that can overwrite your data.

title: Active-Passive replication backlog

text:
In addition to the [database replication backlog](), active-passive databases maintain a replication backlog (per shard) to synchronize the database instances between clusters.
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`]() utility to control the size of the replication backlog. You can set it to `auto` or set a specific size.

For an Active-Passive database:
[code example]

On an Active-Passive database, the replication backlog configuration applies to both the replication backlog for shards synchronization and for synchronization of database instances between clusters.

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

section_id: active-passive-replication-backlog


title: Replica Of Repeatedly Fails

title: Content

text:
**Problem**: The Replica Of process repeatedly fails and restarts

**Diagnostic**: A log entry in the Redis log of the source database shows repeated failures and restarts.

**Cause**: The Redis "client-output-buffer-limit" setting on the source database
is configured to a relatively small value, which causes the connection drop.

**Resolution**: Reconfigure the buffer on the source database to a bigger value:

- If the source is a Redis database on a Redis Software cluster,
    increase the replica buffer size of the **source database** with:

    `rladmin tune db < db:id | name > slave_buffer < value >`

- If the source is a Redis database not on a Redis Software cluster,
    use the [config set](http://redis.io/commands/config-set) command through
    `redis-cli` to increase the client output buffer size of the **source database** with:

    `config set client-output-buffer-limit "slave <hard_limit> <soft_limit> <soft_seconds>"`

**Additional information**: [Top Redis Headaches for DevOps - Replication Buffer](https://redis.io/blog/top-redis-headaches-for-devops-replication-buffer/)


title: Schedule periodic backups

title: Overview

text:
Periodic backups provide a way to restore data with minimal data loss.  With Redis Software, you can schedule periodic backups to occur once a day (every 24 hours), twice a day (every twelve hours), every four hours, or every hour.

As of v6.2.8, you can specify the start time in UTC for 24-hour or 12-hour backups.

To make an on-demand backup, [export your data]().

You can schedule backups to a variety of locations, including:

- FTP server
- SFTP server
- Local mount point
- Amazon Simple Storage Service (S3)
- Azure Blob Storage
- Google Cloud Storage

The backup process creates compressed (.gz) RDB files that you can [import into a database](). If the database name is longer than 30 characters, only the first 30 are used in backup file names.

When you back up a database configured for database clustering,
Redis Software creates a backup file for each shard in the configuration.  All backup files are copied to the storage location.

- Make sure that you have enough space available in your storage location.
    If there is not enough space in the backup location, the backup fails.
- The backup configuration only applies to the database it is configured on.
- To limit the parallel backup for shards, set both [`tune cluster max_simultaneous_backups`]() and [`tune node max_redis_forks`](). `max_simultaneous_backups` is set to 4 by default.

title: Schedule periodic backups

text:
Before scheduling periodic backups, verify that your storage location exists and is available to the user running Redis Software (`redislabs` by default).  You should verify that:

- Permissions are set correctly.
- The user running Redis Software is authorized to access the storage location.
- The authorization credentials work.

Storage location access is verified before periodic backups are scheduled.

To schedule periodic backups for a database:

1. Sign in to the Redis Software Cluster Manager UI using admin credentials.

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

1. Select the **Edit** button.

1. Expand the **Durability** section.

1. In the **Scheduled backup** section, click **Add backup path** to open the **Path configuration** dialog.

1. Select the tab that corresponds to your storage location type, enter the location details, and select **Done**.

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

1. Set the backup **Interval** and **Starting time**.

    | Setting | Description |
    |--------------|-------------|
    | **Interval** | Specifies the frequency of the backup; that is, the time between each backup snapshot.

Supported values include _Every 24 hours_, _Every 12 hours_, _Every 4 hours_, and _Every hour_. |
    | **Starting time** | _v6.2.8 or later: _ Specifies the start time in UTC for the backup; available when **Interval** is set to _Every 24 hours_ or _Every 12 hours_.

If not specified, defaults to a time selected by Redis Software. |

7. Select **Save**.

Access to the storage location is verified when you apply your updates.  This means the location, credentials, and other details must exist and function before you can enable periodic backups.

title: Default backup start time

text:
If you do _not_ specify a start time for twenty-four or twelve hour backups, Redis Software chooses a random starting time in UTC for you.

This choice assumes that your database is deployed to a multi-tenant cluster containing multiple databases.  This means that default start times are staggered (offset) to ensure availability.  This is done by calculating a random offset which specifies a number of seconds added to the start time.

Here's how it works:

- Assume you're enabling the backup at 4:00 pm (1600 hours).
- You choose to back up your database every 12 hours.
- Because you didn't set a start time, the cluster randomly chooses an offset of 4,320 seconds (or 72 minutes).

This means your first periodic backup occurs 72 minutes after the time you enabled periodic backups (4:00 pm + 72 minutes).  Backups repeat every twelve hours at roughly same time.

The backup time is imprecise because they're started by a trigger process that runs every five minutes.  When the process wakes, it compares the current time to the scheduled backup time.  If that time has passed, it triggers a backup.

If the previous backup fails, the trigger process retries the backup until it succeeds.

In addition, throttling and resource limits also affect backup times.

For help with specific backup issues, [contact support](https://redis.com/company/support/).

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

text:
Database backups can be saved 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, backup locations need to be available to [the group and user]() running Redis Software, `redislabs:redislabs` by default.

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

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

title: FTP server

text:
Before enabling backups 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 read and write privileges.

To store your backups on an FTP server, set its **Backup Path** using the following syntax:

`ftp://[username]:[password]@[host]:[port]/[path]/`

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 backup path, if needed.

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

The user account needs permission to write files to the server.

title: SFTP server

text:
Before enabling backups 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 read and write privileges.
- 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 backup to an SFTP server, enter the SFTP server location in the format:

[code example]

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

title: Local mount point

text:
Before enabling periodic backups to a local mount point, verify that:

- The node can connect to the destination server, the one hosting the mount point.
- The `redislabs:redislabs` user has read and write privileges on the local mount point
and on the destination server.
- The backup location has enough disk space for your backup files. Backup files
are saved with filenames that include the timestamp, which means that earlier backups are not overwritten.

To back up to a local mount point:

1. On each node in the cluster, create the mount point:
    1. Connect to a shell running on Redis Software server hosting the node.
    1. Mount the remote storage to a local mount point.

        For example:

        [code example]

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

    For example: `/mnt/Public`

1. Verify that the user running Redis Software has permissions to access and update files in the mount location.

title: AWS Simple Storage Service

text:
To store backups in an Amazon Web Services (AWS) Simple Storage Service (S3) [bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-buckets-s3.html):

1.  Sign in to the [AWS Management 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 backup location details:

    - Select the **AWS S3** tab on the **Path configuration** dialog.

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

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

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

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

To connect to an S3-compatible storage location:

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

    [code example]

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

1. Configure the S3 CA certificate:

    [code example]

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

title: Google Cloud Storage

text:
For [Google Cloud](https://developers.google.com/console/) subscriptions, store your backups in a Google Cloud Storage bucket:

1. Sign in to the Google Cloud Platform 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 backup location details:

    - Select the **Google Cloud Storage** tab on the **Path configuration** dialog.

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

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

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

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

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

title: Azure Blob Storage

text:
To store your backup in Microsoft Azure Blob Storage, sign in to the Azure portal and then:

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 backup location details:

    - Select the **Azure Blob Storage** tab on the **Path configuration** dialog.

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

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

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

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

section_id: aws-simple-storage-service


title: Manage databases

summary: This page will help you find database management information in the Databases section.

summary: Create a database with Redis Software.

title: Create a Redis Software database

summary: Configure settings specific to each database.

title: Configure database settings

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

title: Connect to a database

title: Import and export data

summary: How to migrate database shards to other nodes in a Redis Software cluster.

title: Migrate database shards

summary: Recover a database after the cluster fails or the database is corrupted.

title: Recover a failed database

summary: Delete a database from the Cluster Manager UI.

title: Delete databases

summary: Overview of the Active-Active database in Redis Software

title: Active-Active geo-distributed Redis

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

title: Redis Flex and Auto Tiering

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

title: Durability and high availability

summary: Learn more about managing your memory and optimizing performance for your database.

title: Memory and performance

title: Content

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

- Cluster Manager UI (the web-based user interface)
- Command-line tools ([`rladmin`](), [`redis-cli`](), [`crdb-cli`]())
- [REST API]()


title: Eviction policy

title: Overview

text:
The eviction policy determines what happens when a database reaches its memory limit.

To make room for new data, older data is _evicted_ (removed) according to the selected policy.

To prevent this from happening, make sure your database is large enough to hold all desired keys.

| **Eviction Policy** | **Description** |
|------------|-----------------|
|  noeviction | New values aren't saved when memory limit is reached

When a database uses replication, this applies to the primary database |
|  allkeys-lru | Keeps most recently used keys; removes least recently used (LRU) keys |
|  allkeys-lfu | Keeps frequently used keys; removes least frequently used (LFU) keys |
|  allkeys-random | Randomly removes keys |
|  volatile-lru | Removes least recently used keys with `expire` field set to true |
|  volatile-lfu | Removes least frequently used keys with `expire` field set to true |
|  volatile-random | Randomly removes keys with `expire` field set to true |
|  volatile-ttl | Removes keys with `expire` field set to true and the shortest remaining time-to-live (TTL) value |

title: Eviction policy defaults

text:
`volatile-lru` is the default eviction policy for most databases.

The default policy for [Active-Active databases]() is _noeviction_ policy.

title: Active-Active database eviction

text:
The eviction policy mechanism for Active-Active databases kicks in earlier than for standalone databases because it requires propagation to all participating clusters.
The eviction policy starts to evict keys when one of the Active-Active instances reaches 80% of its memory limit. If memory usage continues to rise while the keys are being evicted, the rate of eviction will increase to prevent reaching the Out-of-Memory state.
As with standalone Redis Software databases, Active-Active eviction is calculated per shard.
To prevent over eviction, internal heuristics might prevent keys from being evicted when the shard reaches the 80% memory limit.  In such cases, keys will get evicted only when shard memory reaches 100%.

In case of network issues between Active-Active instances, memory can be freed only when all instances are in sync. If there is no communication between participating clusters, it can result in eviction of all keys and the instance reaching an Out-of-Memory state.

Data eviction policies are not supported for Active-Active databases with Auto Tiering .

title: Avoid data eviction

text:
To avoid data eviction, make sure your database is large enough to hold required values.

For larger databases, consider using [Redis Flex or Auto Tiering ]().

Auto Tiering stores actively-used data (also known as _hot data_) in RAM and the remaining data in flash memory (SSD).
This lets you retain more data while ensuring the fastest access to the most critical data.


title: Memory and performance

summary: The eviction policy determines what happens when a database reaches its memory limit.

title: Eviction policy

summary: When you set a database's memory limit, you define the maximum size the database can reach.

title: Database memory limits

summary: Detailed info about the shard placement policy.

title: Shard placement policy

title: Overview

text:
Redis Software has multiple mechanisms in its
architecture to help optimize storage and performance.

title: Memory limits

text:
Database memory limits define the maximum size your database can reach across all database replicas and [shards]() on the cluster. Your memory limit will also determine the number of shards you'll need.

Besides your dataset, the memory limit must also account for replication, Active-Active overhead, and module overhead, and a number of other factors. These can significantly increase your database size, sometimes increasing it by four times or more.

For more information on memory limits, see [Database memory limits]().

title: Eviction policies

text:
When a database exceeds its memory limit, eviction policies determine which data is removed. The eviction policy removes keys based on frequency of use, how recently used, randomly, expiration date, or a combination of these factors. The policy can also be set to `noeviction` to return a memory limit error when trying to insert more data.

The default eviction policy for databases is `volatile-lru` which evicts the least recently used keys out of all keys with the `expire` field set. The default for Active-Active databases is `noeviction`.

For more information, see [eviction policies]().

title: Database persistence

text:
Both RAM memory and flash memory are at risk of data loss if a server or process fails. Persisting your data to disk helps protect it against loss in those situations. You can configure persistence at the time of database creation, or by editing the database’s configuration.

There are two main types of persistence strategies in Redis Software: append-only files (AoF) and snapshots.

Append-only files (AoF) keep a record of data changes and writes each change to the end of a file, allowing you to recover the dataset by replaying the writes in the append-only log.

Snapshots capture all the data as it exists in one moment in time and writes it to disk, allowing you to recover the entire dataset as it existed at that moment in time.

For more info on data persistence see [Database persistence with Redis Software]() or [Durable Redis](https://redis.com/redis-enterprise/technology/durable-redis/).

title: Auto Tiering

text:
By default, Redis Software stores your data entirely in [RAM](https://en.wikipedia.org/wiki/Random-access_memory) for improved performance. [Redis Flex and Auto Tiering]() enable your data to span both RAM and [SSD](https://en.wikipedia.org/wiki/Solid-state_drive) storage ([flash memory](https://en.wikipedia.org/wiki/Flash_memory)). Redis Flex tiers both keys and values to flash storage, ensuring that warm (infrequently accessed) data does not consume RAM. Auto Tiering stores keys in RAM but manages the location of their values. Frequently used (hot) data is stored in RAM, but infrequently used (warm) data is moved to flash memory. This saves on expensive RAM space, which gives you comparable performance at a lower cost for large datasets.

For more info, see [Redis Flex and Auto Tiering]().

title: Shard placement

text:
The location of the primary and replica shards on the cluster nodes can impact your database performance.
Primary shards and their corresponding replica shards are always placed on separate nodes for data resiliency and high availability.
The shard placement policy helps to maintain optimal performance and resiliency.

Redis Software has two shard placement policies available:

- **dense**: puts as many shards as possible on the smallest number of nodes
- **sparse**: spread the shards across as many nodes as possible

For more info about the shard placement policy, see [Shard placement policy]()

title: Metrics

text:
From the Redis Software Cluster Manager UI, you can monitor the performance of your clusters, nodes, databases, and shards with real-time metrics. You can also enable alerts for node, cluster, or database events such as high memory usage or throughput.

With the Redis Software API, you can also integrate Redis Software metrics into other monitoring environments, such as Prometheus.

For more info about monitoring with Redis Software, see [Monitoring with metrics and alerts](), and [Memory statistics]().

title: Scaling databases

text:
Each Redis Software cluster can contain multiple databases. In Redis,
databases represent data that belong to a single application, tenant, or
microservice. Redis Software is built to scale to 100s of databases
per cluster to provide flexible and efficient multi-tenancy models.

Each database can contain few or many Redis shards. Sharding is
transparent to Redis applications. Master shards in the database process
data operations for a given subset of keys. The number of shards per
database is configurable and depend on the throughput needs of the
applications. Databases in Redis Software can be resharded into more
Redis shards to scale throughput while maintaining sub-millisecond
latencies. Resharding is performed without downtime.

Redis Software places master shards and replicas in separate
nodes, racks, and zones, and uses in-memory replication to protect data
against failures.

In Redis Software, each database has a quota of RAM. The quota cannot
exceed the limits of the RAM available on the node. However, with Redis
Enterprise Flash, RAM is extended to the local flash drive (SATA, NVMe
SSDs etc). The total quota of the database can take advantage of both
RAM and Flash drive. The administrator can choose the RAM vs Flash ratio
and adjust that anytime in the lifetime of the database without
downtime.

With Auto Tiering, instead of storing all keys and data for a
given shard in RAM, less frequently accessed values are pushed to flash.
If applications need to access a value that is in flash, Redis
Enterprise automatically brings the value into RAM. Depending on the
flash hardware in use, applications experience slightly higher latency
when bringing values back into RAM from flash. However subsequent
accesses to the same value is fast, once the value is in RAM.

title: Client-side caching

text:
Client-side caching allows Redis clients to store a subset of data in a local cache and avoid sending repeated requests to the Redis database. When used to cache frequently accessed data, this technique can improve performance by decreasing network traffic, latency, and load on the database. For more information about client-side caching, see the [client-side caching introduction]().

Redis Software supports client-side caching for databases with Redis versions 7.4 and later. See [Client-side caching compatibility with Redis Software]() for more information about compatibility and configuration options.


title: Database memory limits

title: Overview

text:
When you set a database's memory limit, you define the maximum size the
database can reach in the cluster, across all database replicas and
shards, including both primary and replica shards.

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

title: Factors for sizing

text:
Factors to consider when sizing your database:

- **dataset size**: you want your limit to be above your dataset size to leave room for overhead.
- **database throughput**: high throughput needs more shards, leading to a higher memory limit.
- [**modules**](): using modules with your database consumes more memory.
- [**database clustering**](): enables you to spread your data into shards across multiple nodes.
- [**database replication**](): enabling replication doubles memory consumption.

Additional factors for Active-Active databases:

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

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

Additional factors for  databases with Auto Tiering enabled:

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

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

title: What happens when Redis Software is low on RAM?

text:
Redis Software manages node memory so that data is entirely in RAM (unless using Auto Tiering). If not enough RAM is available, Redis Software prevents adding more data into the databases.

Redis Software protects the existing data and prevents the database from being able to store data into the shards.

You can configure the cluster to move the data to another node, or even discard it according to the [eviction policy]() set on each database by the administrator.

[Redis Flex and Auto Tiering]()
manage memory so that you can also use flash memory (SSD) to store data.

title: Order of events for low RAM

text:
1. If there are other nodes available, your shards migrate to other nodes.
2. If the eviction policy allows eviction, shards start to release memory,
which can result in data loss.
3. If the eviction policy does not allow eviction, you'll receive
out of memory (OOM) messages.
4. If shards can't free memory, Redis Software relies on the OS processes to stop replicas,
but tries to avoid stopping primary shards.

We recommend that you have a [monitoring platform]() that alerts you before a system gets low on RAM.
You must maintain sufficient free memory to make sure that you have a healthy Redis Software installation.

title: Adaptive memory allocation

text:
In rare cases during high-velocity data ingestion, databases can temporarily reach up to 200% of their configured memory limit. This adaptive memory allocation strategy allows large amounts of data to be written to the database quickly without rejecting valid transactions.

For example, when pushing data at approximately 100 MB/sec into a 2 GB database:
- A database with 2 shards could reach 199% of its configured memory limit.
- A database with 4 shards could reach around 220% of its configured memory limit.

Databases should return to their configured memory limits after data is removed according to the [eviction policy]() and [time-to-live (TTL)]().

If you observe this behavior, consider [monitoring]() memory usage and controlling the traffic load on the application side.

title: Resharding duration factors

text: Resharding enables you to increase database capacity by adding shards and utilizing more cluster memory. Understanding resharding duration helps you plan maintenance operations and minimize database risk.

title: Resharding overview

text:
Resharding follows a three-stage process for each new shard:

1. **Shard creation**: Creates a new shard and performs partial synchronization based on assigned hash slots
2. **Key trimming**: Removes keys from the original shard according to new hash slot assignments
3. **Defragmentation**: Executes failovers to optimize new shard performance

When resharding multiple shards (for example, expanding from 4 to 8 shards), this process runs serially for each new shard. The operation completes only after all stages finish for every shard.

Resharding is an atomic operation that cannot be interrupted. Database corruption can occur if the process fails or stops unexpectedly. Minimizing resharding time reduces this risk.

title: Resharding duration factors

text:
Resharding duration increases linearly with the number of keys in your database. Key length and network traffic affect resharding duration:

Key length directly affects resharding duration. Longer keys (2000 KB) require more time to process due to increased hash calculation overhead per key compared to short keys (10 bytes).

Network traffic has a measurable but limited effect on resharding duration. Since resharding operations typically don't reach CPU limits, the impact on both resharding time and ongoing traffic remains minimal.

title: Memory metrics

text:
The Cluster Manager UI provides metrics that can help you evaluate your memory use.

- Free RAM
- RAM fragmentation
- Used memory
- Memory usage
- Memory limit

See [console metrics]() for more detailed information.

title: Related info

role: related

text:
- [Memory and performance]()
- [Disk sizing for heavy write scenarios]()
- [Turn off services to free system memory]()
- [Eviction policy]()
- [Shard placement policy]()
- [Database persistence]()


title: Shard placement policy

title: Overview

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

title: Shard placement policies

title: Dense shard placement policy

text:
In the dense policy, the cluster places the database shards on as few nodes as possible.
When the node is not able to host all of the shards, some shards are moved to another node to maintain optimal node health.

For example, for a database with two master and two replica shards on a cluster with three nodes and a dense shard placement policy,
the two master shards are hosted on one node and the two replica shards are hosted on another node.

For Redis on RAM databases without the OSS cluster API enabled, use the dense policy to optimize performance.

*Figure: Three nodes with two master shards (red) and two replica shards (white) with a dense placement policy*

title: Sparse shard placement policy

text:
In the sparse policy, the cluster places shards on as many nodes as possible to distribute the shards of a database across all available nodes.
When all nodes have database shards, the shards are distributed evenly across the nodes to maintain optimal node health.

For example, for a database with two master and two replica shards on a cluster with three nodes and a sparse shard placement policy:

- Node 1 hosts one of the master shards
- Node 2 hosts the replica for the first master shard
- Node 3 hosts the second master shard
- Node 1 hosts for the replica shard for master shard 2

For Redis on RAM databases with OSS cluster API enabled and for databases with Auto Tiering enabled, use the sparse policy to optimize performance.

*Figure: Three nodes with two master shards (red) and two replica shards (white) with a sparse placement policy*

title: Related articles

text: You can [configure the shard placement policy]() for each database.


title: Migrate database shards

title: Overview

text: To migrate database shards to other nodes in the cluster, you can use the [`rladmin migrate`]() command or [REST API requests]().

title: Use cases for shard migration

text:
Migrate database shards to a different node in the following scenarios:

- Before node removal.

- To balance the database manually in case of latency issues or uneven load distribution across nodes.

- To manage node resources, such as memory usage.

title: Considerations for shard migration

text:
For databases with replication:

- Migrating a shard will not cause disruptions since a primary shard will still be available.

- If you try to migrate a primary shard, it will be demoted to a replica shard and a replica shard will be promoted to primary before the migration. If you set `"preserve_roles": true` in the request, a second failover will occur after the migration finishes to change the migrated shard's role back to primary.

For databases without replication, the migrated shard will not be available until the migration is done.

Connected clients shouldn't be disconnected in either case.

If too many primary shards are placed on the same node, it can impact database performance.

title: Migrate specific shard

text:
To migrate a specific database shard, use one of the following methods:

- [`rladmin migrate shard`]():

    [code example]

- [Migrate shard]() REST API request:

    Specify the ID of the shard to migrate in the request path and the destination node's ID as the `target_node_uid` in the request body. See the [request reference]() for more options.

    [code example]

    Example JSON response body:

    [code example]

    You can track the action's progress with a [`GET /v1/actions/<action_uid>`]() request.

title: Migrate multiple shards

text:
To migrate multiple database shards, use one of the following methods:

- [`rladmin migrate shard`]():

    [code example]

- [Migrate multiple shards]() REST API request:

    Specify the IDs of the shards to migrate in the `shard_uids` list and the destination node's ID as the `target_node_uid` in the request body. See the [request reference]() for more options.

    [code example]

    Example JSON response body:

    [code example]

    You can track the action's progress with a [`GET /v1/actions/<action_uid>`]() request.

title: Migrate all shards from a node

text:
To migrate all shards from a specific node to another node, run [`rladmin migrate all_shards`]():

[code example]

title: Migrate primary shards

text:
You can use the [`rladmin migrate all_master_shards`]() command to migrate all primary shards for a specific database or node to another node in the cluster.

To migrate a specific database's primary shards:

[code example]

To migrate all primary shards from a specific node:

[code example]

title: Migrate replica shards

text:
You can use the [`rladmin migrate all_slave_shards`]() command to migrate all replica shards for a specific database or node to another node in the cluster.

To migrate a specific database's replica shards:

[code example]

To migrate all replica shards from a specific node:

[code example]

code: rladmin migrate shard <shard_id> target_node <node_id>

section_id: migrate-specific-shard

code:
POST /v1/shards/<shard_id>/actions/migrate
    {
        "target_node_uid": <node_id>
    }

description: Migrate was triggered

code: rladmin migrate shard <shard_id1> <shard_id2> <shard_id3> target_node <node_id>

section_id: migrate-multiple-shards

code:
POST /v1/shards/actions/migrate
    {
        "shard_uids": ["<shard_id1>","<shard_id2>","<shard_id3>"],
        "target_node_uid": <node_id>
    }

description: Migrate was triggered

code: rladmin migrate node <origin_node_id> all_shards target_node <node_id>

section_id: migrate-all-shards-from-a-node

code: rladmin migrate db db:<id> all_master_shards target_node <node_id>

section_id: migrate-primary-shards

code: rladmin migrate node <origin_node_id> all_master_shards target_node <node_id>

code: rladmin migrate db db:<id> all_slave_shards target_node <node_id>

section_id: migrate-replica-shards

code: rladmin migrate node <origin_node_id> all_slave_shards target_node <node_id>


title: Recover a failed database

title: Overview

text:
When a cluster fails or a database is corrupted, you must:

1. [Restore the cluster configuration]() from the CCS files
1. Recover the databases with their previous configuration and data

To restore data to databases in the new cluster,
you must restore the database persistence files (backup, AOF, or snapshot files) to the databases.
These files are stored in the [persistence storage location]().

The database recovery process includes:

1. If the cluster failed, [recover the cluster]().
1. Identify recoverable databases.
1. Restore the database data.
1. Verify that the databases are active.

title: Prerequisites

text:
- Before you start database recovery, make sure that the cluster that hosts the database is healthy.
    In the case of a cluster failure,
    you must [recover the cluster]() before you recover the databases.

- We recommend that you allocate new persistent storage drives for the new cluster nodes.
    If you use the original storage drives,
    make sure to back up all files on the old persistent storage drives to another location.

title: Recover databases

text:
After you prepare the cluster that hosts the database,
you can run the recovery process from the [`rladmin`]()
command-line interface (CLI).

To recover the database:

1. Mount the persistent storage drives with the recovery files to the new nodes.
    These drives must contain the cluster configuration backup files and database persistence files.

Make sure that the user `redislabs` has permissions to access the storage location
of the configuration and persistence files on each of the nodes.

    If you use local persistent storage, place all of the recovery files on each of the cluster nodes.

1. To see which databases are recoverable, run [`rladmin recover list`]():

    [code example]

    The status for each database can be either ready for recovery or missing files.
    An indication of missing files in any of the databases can result from:

    - The storage location is not found - Make sure the recovery path is set correctly on all nodes in the cluster.
    - Files are not found in the storage location - Move the files to the storage location.
    - No permission to read the files - Change the file permissions so that redislabs:redislabs has 640 permissions.
    - Files are corrupted - Locate copies of the files that are not corrupted.

    If you cannot resolve the issues, contact [Redis support](https://redis.com/company/support/).

1. Recover the database using one of the following [`rladmin recover`]() commands:

    - Recover all databases from the persistence files located in the persistent storage drives:

        [code example]

    - Recover a single database from the persistence files located in the persistent storage drives:

        - By database ID:

            [code example]

        - By database name:

            [code example]

    - Recover only the database configuration for a single database (without the data):

        [code example]

- If persistence was not configured for the database, the database is restored empty.
- For Active-Active databases that still have live instances, we recommend that you recover the configuration for the failed instances and let the  data update from the other instances.
- For Active-Active databases where all instances need to be recovered, we recommend you recover one instance with the data and only recover the configuration for the other instances.
   The empty instances then update from the recovered data.
- If the persistence files of the databases from the old cluster are not stored in the persistent storage location of the new node,
   you must first map the recovery path of each node to the location of the old persistence files.
   To do this, run the `node <id> recovery_path set` command in rladmin.
   The persistence files for each database are located in the persistent storage path of the nodes from the old cluster, usually under `/var/opt/redislabs/persist/redis`.

1. To verify that the recovered databases are now active, run:

    [code example]

After the databases are recovered, make sure your Redis clients can successfully connect to the databases.

title: Configure automatic recovery

text:
If you enable the automatic recovery cluster policy, Redis Software tries to quickly recover as much data as possible from before the disaster.

To enable automatic recovery, use one of the following methods:

**rladmin:**

To enable automatic recovery using `rladmin`, run the [`rladmin tune cluster`]() command:

[code example]

**REST API:**

To enable automatic recovery using the REST API, use an [update cluster policy]() request:

[code example]

Redis Software tries to recover databases from the best existing persistence files. If a persistence file isn't available, which can happen if its host node is down, the automatic recovery process waits for it to become available.

For each database, you can set the `recovery_wait_time` to define how many seconds the database waits for a persistence file to become available before recovery. After the wait time elapses, the recovery process continues, which can result in partial or full data loss. The default value is `-1`, which means to wait forever. Short wait times can increase the risk of potential data loss.

To change `recovery_wait_time` for an existing database using the REST API:

[code example]

You can also set `recovery_wait_time` when you [create a database]() using the REST API.

code: rladmin recover list

section_id: recover-databases

code: rladmin recover all

code: rladmin recover db db:<id>

code: rladmin recover db <name>

code: rladmin recover db <name> only_configuration

code: rladmin status

code: rladmin tune cluster auto_recovery enabled

section_id: configure-automatic-recovery

code:
PUT /v1/cluster/policy
{
  "auto_recovery": true
}

code:
PUT /v1/bdbs/<bdb_uid>
{
  "recovery_wait_time": 3600
}


title: Redis Software

summary: The self-managed, enterprise-grade version of Redis.

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

title: Install, set up, and upgrade Redis Software

summary: Administrative tasks and information related to the Redis Software cluster.

title: Manage clusters

title: Manage databases

summary: Networking features and considerations for designing your Redis Software deployment.

title: Manage networks

title: Security

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

title: Monitoring with metrics and alerts

summary: Resources for troubleshooting Redis Software

title: Troubleshooting Redis Software

title: Reference

title: Release notes

summary: Describes where to view the archive of Redis Enterprise Software documentation.

title: Archive

title: Overview

text:
[Redis Software](https://redis.io/software/) is a self-managed, enterprise-grade version of Redis.

With Redis Software, you get many enterprise-grade capabilities, including:
- Linear scalability
- High availability, backups, and recovery
- Predictable performance
- 24/7 support

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

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

title: Get started

text:
Build a small-scale cluster with the Redis Software container image.
- [Linux quickstart]()
- [Docker quickstart]()
- [Get started with Active-Active]()

title: Install & setup

role: setup

text:
[Install & set up]() a Redis Software cluster.
- [Networking]()
- [Set up]() & [configure]() a [cluster]()
- [Release notes]()

title: Databases

text:
Create and manage a [Redis database]() on a cluster.
- [Create a Redis Software database]()
- [Configure database]()
- [Create Active-Active database]()
- [Edit Active-Active database]()

title: Security

role: security

text:
[Manage secure connections]() to the cluster and databases.
- [Access control]()
- [Users]() & [roles]()
- [Certificates]()
- [TLS]() & [Encryption]()

title: Reference

text:
Use command-line utilities and the REST API to manage the cluster and databases.
- [rladmin](), [crdb-cli](), & [other utilities]()
- [REST API reference]() & [examples]()
- [Redis commands]()

title: Archive

text:
You can use the version selector in the navigation menu to view documentation for Redis Software versions 7.4 and later.

To view documentation earlier than version 7.4, see the archived website:

- [Redis Software v7.2 documentation archive](https://docs.redis.com/7.2/rs/)

- [Redis Software v6.4 documentation archive](https://docs.redis.com/6.4/rs/)

- [Redis Software v6.2 documentation archive](https://docs.redis.com/6.2/rs/)

- [Redis Software v6.0 documentation archive](https://docs.redis.com/6.0/rs/)

title: Related info

text:
- [Redis Cloud]()
- [Redis Open Source]()
- [Redis Stack]()
- [Glossary]()

title: Continue learning with Redis University

text:
* [Get started with Redis Software learning path](https://university.redis.io/learningpath/an0mgw5bjpjfbe?_gl=1*4gjdoe*_gcl_au*MTkyMTIyOTY3Mi4xNzM5MTk5Mjc4)
* [Operate Redis Software learning path](https://university.redis.io/learningpath/uobc5j9rrhalce?tab=details)


title: Configure CentOS/RHEL firewall

summary: Configure firewall rules for Redis Software on CentOS or Red Hat Enterprise Linux (RHEL).

title: Content

text:
CentOS and Red Hat Enterprise Linux (RHEL) distributions use [**firewalld**](https://firewalld.org/) by default to manage the firewall and configure [iptables](https://en.wikipedia.org/wiki/Iptables).
The default configuration assigns the network interfaces to the **public** zone and blocks all ports except port 22, which is used for [SSH](https://en.wikipedia.org/wiki/Secure_Shell).

When you install Redis Software on CentOS or RHEL, it automatically creates two firewalld system services:

- A service named **redislabs**, which includes all ports and protocols needed for communication between cluster nodes.
- A service named **redislabs-clients**, which includes the ports and protocols needed for external communication (outside of the cluster).

These services are defined but not allowed through the firewall by default.
During Redis Software installation, the [installer prompts]() you to confirm auto-configuration of a default (public) zone
to allow the **redislabs** service.

Although automatic firewall configuration simplifies installation, your deployment might not be secure if you did not use other methods to secure the host machine's network, such as external firewall rules or security groups.
You can use firewalld configuration tools such as **firewall-cmd** (command line) or **firewall-config** (UI)
to create more specific firewall policies that allow these two services through the firewall, as necessary.

If databases are created with non-standard [Redis Software ports](),
you need to explicitly configure firewalld to make sure those ports are not blocked.


title: Change socket file locations

summary: Change socket file locations.

title: Default socket file locations

text:
There are two default locations for the socket files in Redis Software:

- `/tmp` - In clean installations of Redis Software version earlier than 5.2.2
- `/var/opt/redislabs/run` - In clean installations of Redis Software version 5.2.2 and later

The default location was changed in case you run any maintenance procedures that delete the `/tmp` directory.

When you upgrade Redis Software from an earlier version to 5.2.2 or later, the socket files are not moved to the new location by default. You need to specify the socket file location [during installation](#during-install).

title: Specify socket file location during install {#during-install}

text:
To specify the socket file location during a new installation, follow the [Install Redis Software on Linux]() instructions, but use the `-s` [installation script option]():

[code example]

title: Change socket file location for an existing cluster {#after-cluster-setup}

text:
Directly changing the socket file location directly is not supported for bootstrapped nodes. If you need to change the socket file location for an existing cluster, use one of the following methods instead:

- [Replace nodes](#replace-nodes)

- [Migrate the cluster using Replica Of](#migrate-replica-of)

title: Replace nodes {#replace-nodes}

text:
To change the socket file location for all nodes in a cluster, follow these steps:

1. Install Redis Software on a new node with the new socket file location. Follow the [Install Redis Software on Linux]() instructions, but use the -s [installation script option]():

    [code example]

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

1. [Remove a node]() with the old socket file location.

1. Repeat the previous steps until all nodes with the old socket file location have been replaced.

title: Migrate cluster using Replica Of {#migrate-replica-of}

text:
To migrate an existing cluster to a new cluster with a different socket file location:

1. Create a new cluster with the new socket file location. To do so, follow the [Install Redis Software on Linux]() instructions, but use the `-s` [installation script option]():

    [code example]

1. Use Replica Of to migrate your databases from the original cluster to the new cluster. For detailed steps, see the procedure to [configure Replica Of with different Redis Software clusters]().

code: sudo ./install.sh -s </path/to/socket/files>

section_id: replace-nodes-replace-nodes


title: Additional configuration

title: Configure CentOS/RHEL firewall

summary: Turn off Linux swap space.

title: Configure swap for Linux

summary: Change socket file locations.

title: Change socket file locations

title: Content

text: This section describes additional configuration options for Redis Software installation.


title: Configure swap for Linux

summary: Turn off Linux swap space.

title: Overview

text:
Linux operating systems use swap space, which is enabled by default, to help manage memory (pages) by
copying pages from RAM to disk. Due to the way Redis Software
utilizes and manages memory, it is best to prevent OS swapping. For more details, see [memory limits](). The
recommendation is to turn off Linux swap completely in the OS.

When you install or build the OS on the machine intended to host your Redis Software cluster, avoid configuring swap partitions if possible.

title: Turn off swap

text:
To turn off swap in the OS of an existing server, VM, or instance, you
must have `sudo` access or be a root user to run the following commands.

Turn off swap:

[code example]

To ensure swap remains off even after a reboot:

1. Open `/etc/fstab` in a text editor and locate the entry that defines the swap space.

    Example swap space entries:

    [code example]

    [code example]

1. Comment out the swap space entry, then save the file.

    Example swap space entries commented out:

    [code example]

    [code example]

code: sudo swapoff -a

section_id: turn-off-swap

code: /swapfile   none    swap    sw      0       0

code: #/swapfile   none    swap    sw      0       0

code: #UUID=1d5e1de7-226d-4f60-a99c-f7a31a045c59 none            swap    defaults        0 0