AWS provides the cache service called Elasticache. Two different technologies can be used the Redis and the Memcache. Both are robust solutions and they both have their advantages and disadvantages.
The solution needs to be resilient and highly available and as fast as possible. Besides an important feature is how they handle the failure of the system. Failover is a key factor to avoid any big disruption that weighs on the decision-making.
Redis and Memcache manage the failure differently and we will look at them in this article.
Redis
Multi-AZ & Auto Failover
This feature allows for minimizing any downtime due to a planned operation, a failure of the primary writer instance, or other unexpected events. The replacement of the primary node results in some downtime which is reduced for the cluster if the Multi-Az is ON.
Elasticache handles everything for you. it fails over on a healthy node, updates the DNS cluster endpoints, and replaces the unhappy former primary node to resume writing to the new primary as soon as promotion is completed.
The best practice is to use the cluster endpoint which gets always updated automatically with the newer primary node endpoint.
In the case of planned operation replacements, the behavior of the clusters depends on the cluster version and cluster mode.
Limitations on Redis Multi-AZ
- Multi-AZ is supported on Redis for 2.8.6
- It is not supported on T1 instance type
- Redis replication is asynchronous
- To manually Promote a read replica to primary for a Cluster mode disabled cluster is possible only if the auto-failover and Multi-AZ are disabled.
- Redis Multi-AZ and append-only file AOF are mutually exclusive.
- A customer-initiated reboot of a primary doesn't trigger automatic failover.
- when the primary is rebooted, it has cleared of data when it comes back online
- After a read replica has been promoted, the other replicas sync with the new primary and retain the data. It causes a brief interruption, during which the replicas are not accessible.
FAQs
I can't enable Multi-AZ
The cluster has a Primary and a Read Replica, if they are in the same AZ, the MultiAZ can't be enabled. Only the Auto-failover can be turned ON.
differences between Multi-AZ and auto-failover
If enabled, in case of primary node loss, failover to a read replica will happen automatically.
- Multi-AZ. Only happens if RR are in different AZs
- Auto-failover
Q: What is Multi-AZ for an Amazon ElastiCache for Redis replication group?
An Amazon ElastiCache for Redis replication group consists of a primary and up to five read replicas. If Multi-AZ is enable then at least one replica is required per primary.
Q: What are the benefits of using Multi-AZ and when should I use it?
The main benefits of running your Amazon ElastiCache for Redis in Multi-AZ mode are enhanced availability and smaller need for administration. If an Amazon ElastiCache for Redis primary node failure occurs, the impact on your ability to read/write to the primary is limited to the time it takes for automatic failover to complete. When Multi-AZ is enabled, Amazon ElastiCache node failover is automatic and requires no administration.
Q: Can I have replicas in the same Availability Zone as the primary?
Yes. Note that placing both the primary and the replica(s) in the same Availability Zone will not make your Amazon ElastiCache for Redis replication group resilient to an Availability Zone disruption. Additionally this well not be allowed if Multi-AZ is turned on.
Memcached
Mitigating Failures
When you plan to use Memcached for your implementation, you need to develop your applications to be able to handle a minimal impact upon your application.
Memcached doesn't sync the data across all the nodes, so in the lost node event, some data gets lost.
Mitigating Node Failures
to reduce to a minimum the outage of a node failure, spread your cached data over more nodes. Memcached does not support replication, a node failure will always result in some data loss for the cluster.
A cluster can have from 1 to 40 nodes, partitioning the data across a greater number of node means it will be lost less data if a single node fails.
Mitigating Availability Zone Failures
To mitigate the impact of an AZ failure, locate the nodes in as many AZs as possible. There is not a magic formula for determining how many nodes to have, you need to figure it out the impact of data loss vs the possible of a failure vs cost.
References
Minimizing downtime in ElastiCache for Redis with Multi-AZ - Enabling Multi-AZ