Menu
Amazon ElastiCache
User Guide (API Version 2015-02-02)

Redis Replication

Redis implements replication in two ways: 1) Redis (cluster mode disabled) with a single shard that contains all of the cluster's data in each node, and 2) Redis (cluster mode enabled) with data partitioned across up to 15 shards.

Redis (cluster mode disabled)

A Redis (cluster mode disabled) cluster has a single shard, inside of which is a collection of Redis nodes; one primary read-write node and up to five secondary, read-only replica nodes. Each read replica maintains a copy of the data from the cluster's primary node. Asynchronous replication mechanisms are used to keep the read-replicas synchronized with the primary. Applications can read from any node in the cluster. Applications can write only to the primary node. Read replicas improve read throughput and guard against data loss in cases of a node failure.

Image: Redis (cluster mode disabled) cluster with a single shard and replica nodes

Redis (cluster mode disabled) cluster with a single shard and replica nodes

You can use Redis (cluster mode disabled) clusters with replica nodes to scale your Redis solution for ElastiCache to handle applications that are read-intensive or to support large numbers of clients that simultaneously read from the same cluster.

All of the nodes in a Redis (cluster mode disabled) cluster must reside in the same region. To improve fault tolerance, you can provision read replicas in multiple Availability Zones within that region.

When you add a read replica to a cluster, all of the data from the primary is copied to the new node. From that point on, whenever data is written to the primary, the changes are asynchronously propagated to all the read replicas.

To improve fault tolerance and reduce write down time, enable Multi-AZ with automatic failover for your Redis (cluster mode disabled) cluster with replicas. For more information, see Replication: Multi-AZ with Automatic Failover (Redis).

You can change the roles of the nodes within the Redis (cluster mode disabled) cluster, with the primary and one of the replicas exchanging roles. You might decide to do this for performance tuning reasons. For example, with a web application that has heavy write activity, you can choose the node that has the lowest network latency. For more information, see Promoting a Read-Replica to Primary.

Redis (cluster mode enabled)

A Redis (cluster mode enabled) cluster is comprised of from 1 to 15 shards (API/CLI: node groups). Each shard has a primary node and up to five read-only replica nodes. Each read replica in a shard maintains a copy of the data from the shard's primary. Asynchronous replication mechanisms are used to keep the read-replicas synchronized with the primary. Applications can read from any node in the cluster. Applications can write only to the primary nodes. Read replicas enhance read scalability and guard against data loss. Data is partitioned across the shards in a Redis (cluster mode enabled) cluster.

Applications use the Redis (cluster mode enabled) cluster's configuration endpoint to connect with the nodes in the cluster. For more information, see Finding Your ElastiCache Endpoints.


               Image: Redis (cluster mode enabled) cluster with multiple shards and replica nodes

Redis (cluster mode enabled) cluster with multiple shards and replica nodes

All of the nodes in a Redis (cluster mode enabled) cluster must reside in the same region. To improve fault tolerance, you can provision both primaries and read replicas in multiple Availability Zones within that region.

Multi-AZ with automatic failover is required for all Redis (cluster mode enabled) clusters. For more information, see Replication: Multi-AZ with Automatic Failover (Redis).

Currently, in Redis (cluster mode enabled), there are some limitations.

  • Each shard must have at least one read-replica node.

  • You cannot promote any of the replica nodes to primary.

  • Multi-AZ with automatic failover is required.

  • The structure of the cluster, node type, number of shards, and number of nodes, can only be changed by restoring from a backup. For more information, see Restoring From a Backup with Cluster Resizing.