Replacing nodes - Amazon ElastiCache for Redis
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Replacing nodes

Amazon ElastiCache for Redis frequently upgrades its fleet with patches and upgrades being applied to instances seamlessly. However, from time to time we need to relaunch your ElastiCache for Redis nodes to apply mandatory OS updates to the underlying host. These replacements are required to apply upgrades that strengthen security, reliability, and operational performance.

You have the option to manage these replacements yourself at any time before the scheduled node replacement window. When you manage a replacement yourself, your instance receives the OS update when you relaunch the node and your scheduled node replacement is canceled. You might continue to receive alerts indicating that the node replacement is to take place. If you've already manually mitigated the need for the maintenance, you can ignore these alerts.

Note

Replacement cache nodes automatically generated by Amazon ElastiCache may have different IP addresses. You are responsible for reviewing your application configuration to ensure that your cache nodes are associated with the appropriate IP addresses.

The following list identifies actions you can take when ElastiCache schedules one of your Redis nodes for replacement. To expedite finding the information you need for your situation, choose from the following menu.

Redis node replacement options

  • Do nothing – If you do nothing, ElastiCache replaces the node as scheduled.

     

    For non-Cluster configurations with autofailover enabled, clusters on Redis 5.0.6 and above complete replacement while the cluster continues to stay online and serve incoming write requests. For auto failover enabled clusters on Redis 4.0.10 or below, you might notice a brief write interruption of up to a few seconds associated with DNS updates.

    If the node is a member of an auto failover enabled cluster, ElastiCache for Redis provides improved availability during patching, updates, and other maintenance-related node replacements.

     

    For ElastiCache for Redis Cluster configurations that are set up to use ElastiCache for Redis Cluster clients, replacement now completes while the cluster serves incoming write requests.

     

    For non-Cluster configurations with autofailover enabled, clusters on Redis 5.0.6 and above complete replacement while the cluster continues to stay online and serve incoming write requests. For auto failover enabled clusters on Redis 4.0.10 or below, you might notice a brief write interruption of up to a few seconds associated with DNS updates.

     

    If the node is standalone, Amazon ElastiCache first launches a replacement node and then syncs from the existing node. The existing node isn't available for service requests during this time. Once the sync is complete, the existing node is terminated and the new node takes its place. ElastiCache makes a best effort to retain your data during this operation.

     

  • Change your maintenance window – For scheduled maintenance events, you receive an email or a notification event from ElastiCache. In these cases, if you change your maintenance window before the scheduled replacement time, your node now is replaced at the new time. For more information, see the following:

    Note

    The ability to change your replacement window by moving your maintenance window is only available when the ElastiCache notification includes a maintenance window. If the notification does not include a maintenance window, you cannot change your replacement window.

    For example, let's say it's Thursday, November 9, at 15:00 and the next maintenance window is Friday, November 10, at 17:00. Following are three scenarios with their outcomes:

    • You change your maintenance window to Fridays at 16:00, after the current date and time and before the next scheduled maintenance window. The node is replaced on Friday, November 10, at 16:00.

    • You change your maintenance window to Saturday at 16:00, after the current date and time and after the next scheduled maintenance window. The node is replaced on Saturday, November 11, at 16:00.

    • You change your maintenance window to Wednesday at 16:00, earlier in the week than the current date and time). The node is replaced next Wednesday, November 15, at 16:00.

    For instructions, see Managing maintenance.

     

  • Replace the only node in any Redis cluster – If the cluster does not have any read replicas, you can use the following procedure to replace the node.

    To replace the only node using backup and restore

    1. Create a snapshot of the node's cluster. For instructions, see Taking manual backups.

    2. Create a new cluster seeding it from the snapshot. For instructions, see Restoring from a backup into a new cache.

    3. Delete the cluster with the node scheduled for replacement. For instructions, see Deleting a cluster.

    4. In your application, replace the old node's endpoint with the new node's endpoint.

     

  • Replace a replica node in any Redis cluster – To replace a replica cluster, increase your replica count. To do this, add a replica then decrease the replica count by removing the replica that you want to replace. This process is dynamic and doesn't have any cluster downtime.

    Note

    If your shard or replication group already has five replicas, reverse steps 1 and 2.

    To replace a replica in any Redis cluster

    1. Increase the replica count by adding a replica to the shard or replication group. For more information, see Increasing the number of replicas in a shard.

    2. Delete the replica you want to replace. For more information, see Decreasing the number of replicas in a shard.

    3. Update the endpoints in your application.

     

  • Replace any node in a Redis (cluster mode enabled) shard – To replace the node in a cluster with no downtime, use online resharding. First add a shard by scaling out, and then delete the shard with the node to be replaced by scaling in.

    To replace any node in a Redis (cluster mode enabled) cluster

    1. Scale out: Add an additional shard with the same configuration as the existing shard with the node to be replaced. For more information, see Adding shards with online resharding.

    2. Scale in: Delete the shard with the node to be replaced. For more information, see Removing shards with online resharding.

    3. Update the endpoints in your application.

     

  • Replace a node in a Redis (cluster mode disabled) cluster – If the cluster is a Redis (cluster mode disabled) cluster without any read replicas, use the following procedure to replace the node.

    To replace the node using replication (cluster mode disabled only)

    1. Add replication to the cluster with the node scheduled for replacement as the primary. Do not enable Multi-AZ on this cluster. For instructions, see To add replication to a Redis cluster with no shards.

    2. Add a read-replica to the cluster. For instructions, see To add nodes to a cluster (console).

    3. Promote the newly created read-replica to primary. For instructions, see Promoting a read replica to primary, for Redis (cluster mode disabled) replication groups.

    4. Delete the node scheduled for replacement. For instructions, see Removing nodes from a cluster.

    5. In your application, replace the old node's endpoint with the new node's endpoint.

     

  • Replace a Redis (cluster mode disabled) read-replica – If the node is a read-replica, replace the node.

    If your cluster has only one replica node and Multi-AZ is enabled, you must disable Multi-AZ before you can delete the replica. For instructions, see Modifying a replication group.

    To replace a Redis (cluster mode disabled) read replica

    1. Delete the replica that is scheduled for replacement. For instructions, see the following:

    2. Add a new replica to replace the one that is scheduled for replacement. If you use the same name as the replica you just deleted, you can skip step 3. For instructions, see the following:

    3. In your application, replace the old replica's endpoint with the new replica's endpoint.

    4. If you disabled Multi-AZ at the start, re-enable it now. For instructions, see Enabling Multi-AZ .

     

  • Replace a Redis (cluster mode disabled) primary node – If the node is the primary node, first promote a read-replica to primary. Then delete the replica that used to be the primary node.

    If your cluster has only one replica and Multi-AZ is enabled, you must disable Multi-AZ before you can delete the replica in step 2. For instructions, see Modifying a replication group.

    To replace a Redis (cluster mode disabled) primary node

    1. Promote a read-replica to primary. For instructions, see Promoting a read replica to primary, for Redis (cluster mode disabled) replication groups.

    2. Delete the node that is scheduled for replacement (the old primary). For instructions, see Removing nodes from a cluster.

    3. Add a new replica to replace the one scheduled for replacement. If you use the same name as the node you just deleted, you can skip changing endpoints in your application.

      For instructions, see Adding a read replica, for Redis (Cluster Mode Disabled) replication groups.

    4. In your application, replace the old node's endpoint with the new node's endpoint.

    5. If you disabled Multi-AZ at the start, re-enable it now. For instructions, see Enabling Multi-AZ .