{
  "id": "replica-ha",
  "title": "Configure high availability for replica shards",
  "url": "https://redis.io/docs/latest/operate/rs/7.8/databases/configure/replica-ha/",
  "summary": "Configure high availability for replica shards so that the cluster automatically migrates the replica shards to an available node.",
  "content": "\nWhen you enable [database replication](),\nRedis Enterprise Software creates a replica of each primary shard.  The replica shard will always be \nlocated on a different node than the primary shard to make your data highly available.  If the primary shard \nfails or if the node hosting the primary shard fails, then the replica is promoted to primary.\n\nWithout replica high availability (_replica\\_ha_) enabled, the promoted primary shard becomes a single point of failure \nas the only copy of the data.\n\nEnabling _replica\\_ha_ configures the cluster to automatically replicate the promoted replica on an available node. \nThis automatically returns the database to a state where there are two copies of the data: \nthe former replica shard which has been promoted to primary and a new replica shard.\n\nAn available node:\n\n1. Meets replica migration requirements, such as [rack-awareness]().\n1. Has enough available RAM to store the replica shard.\n1. Does not also contain the primary shard.\n\nIn practice, replica migration creates a new replica shard and copies the data from the primary shard to the new replica shard.\n\nFor example:\n\n1. Node:2 has a primary shard and node:3 has the corresponding replica shard.\n1. Either:\n\n    - Node:2 fails and the replica shard on node:3 is promoted to primary.\n    - Node:3 fails and the primary shard is no longer replicated to the replica shard on the failed node.\n\n1. If replica HA is enabled, a new replica shard is created on an available node.\n1. The data from the primary shard is replicated to the new replica shard.\n\n\n- Replica HA follows all prerequisites of replica migration, such as [rack-awareness]().\n- Replica HA migrates as many shards as possible based on available DRAM in the target node. When no DRAM is available, replica HA stops migrating replica shards to that node.\n\n\n## Configure high availability for replica shards\n\nIf replica high availability is enabled for both the cluster and a database,\nthe database's replica shards automatically migrate to another node when a primary or replica shard fails.\nIf replica HA is not enabled at the cluster level,\nreplica HA will not migrate replica shards even if replica HA is enabled for a database.\n\nReplica high availability is enabled for the cluster by default.\n\nWhen you create a database using the Cluster Manager UI, replica high availability is enabled for the database by default if you enable replication.\n\n\n\nTo use replication without replication high availability, clear the **Replica high availability** checkbox.\n\nYou can also enable or turn off replica high availability for a database using `rladmin` or the REST API.\n\n\nFor Active-Active databases, replica HA is enabled for the database by default to make sure that replica shards are available for Active-Active replication.\n\n\n### Configure cluster policy for replica HA\n\nTo enable or turn off replica high availability by default for the entire cluster, use one of the following methods:\n\n- [rladmin tune cluster](): \n    \n    ```sh\n    rladmin tune cluster slave_ha { enabled | disabled }\n    ```\n\n- [Update cluster policy]() REST API request:\n\n    ```sh\n    PUT /v1/cluster/policy \n    { \"slave_ha\": \u003cboolean\u003e }\n    ```\n\n### Turn off replica HA for a database\n\nTo turn off replica high availability for a specific database using `rladmin`, run:\n\n``` text\nrladmin tune db db:\u003cID\u003e slave_ha disabled\n```\n\nYou can use the database name in place of `db:\u003cID\u003e` in the preceding command.\n\n\n## Configuration options\n\nYou can see the current configuration options for replica HA with:\n\n``` text\nrladmin info cluster\n```\n\n### Grace period\n\nBy default, replica HA has a 10-minute grace period after node failure and before new replica shards are created.\n\nThe default grace period is 30 minutes for containerized applications using [Redis Enterprise Software for Kubernetes]().\n\nTo configure this grace period from rladmin, run:\n\n``` text\nrladmin tune cluster slave_ha_grace_period \u003ctime_in_seconds\u003e\n```\n\n\n### Shard priority\n\nReplica shard migration is based on priority.  When memory resources are limited, the most important replica shards are migrated first:\n\n1. `slave_ha_priority` - Replica shards with higher \n    integer values are migrated before shards with lower values.\n\n    To assign priority to a database, run:\n\n    ``` text\n    rladmin tune db db:\u003cID\u003e slave_ha_priority \u003cpositive integer\u003e\n    ```\n    \n    You can use the database name in place of `db:\u003cID\u003e` in the preceding command.\n\n1. Active-Active databases - Active-Active database synchronization uses replica shards to synchronize between the replicas.\n1. Database size - It is easier and more efficient to move replica shards of smaller databases.\n1. Database UID - The replica shards of databases with a higher UID are moved first.\n\n### Cooldown periods\n\nBoth the cluster and the database have cooldown periods.\n\nAfter node failure, the cluster cooldown period (`slave_ha_cooldown_period`) prevents another replica migration due to another node failure for any\ndatabase in the cluster until the cooldown period ends. The default is one hour.\n\nAfter a database is migrated with replica HA,\nit cannot go through another migration due to another node failure until the cooldown period for the database (`slave_ha_bdb_cooldown_period`) ends. The default is two hours.\n\nTo configure cooldown periods, use [`rladmin tune cluster`]():\n\n- For the cluster:\n\n    ``` text\n    rladmin tune cluster slave_ha_cooldown_period \u003ctime_in_seconds\u003e\n    ```\n\n- For all databases in the cluster:\n\n    ``` text\n    rladmin tune cluster slave_ha_bdb_cooldown_period \u003ctime_in_seconds\u003e\n    ```\n\n### Alerts\n\nThe following alerts are sent during replica HA activation:\n\n- Shard migration begins after the grace period.\n- Shard migration fails because there is no available node (sent hourly).\n- Shard migration is delayed because of the cooldown period.\n",
  "tags": ["docs","operate","rs"],
  "last_updated": "2026-04-01T08:10:08-05:00"
}