How do I troubleshoot errors when changing my ElastiCache for Redis node type?
"When changing my Amazon ElastiCache for Redis node type, the option isn't available, the change isn't taking effect, or I'm receiving an error message. How can I troubleshoot these issues?"
"When changing my Amazon ElastiCache for Redis node type, the option isn't available, the change isn't taking effect, or I'm receiving an error message. How can I troubleshoot these issues?Short descriptionThe following are common reasons for problems changing your Redis node type:Insufficient memory on the target node type.Insufficient capacity.Insufficient elastic network interfaces.The specified node type isn't available in the Availability Zone.The Redis engine version doesn't support the targeted node type.The ApplyImmediately parameter set to false.Heavy node utilization.ResolutionNote: You can use ElastiCache events and AWS CloudTrail for further insights and to see relevant error messages.Insufficient memory on the target node typeMake sure that the new node type is large enough to accommodate all your data and the required Redis overhead. Amazon CloudWatch provides Redis metrics under Amazon ElastiCache. Make sure that the current total memory usage displayed in the BytesUsedForCache metric is below the max capacity of your target node type.If the BytesUsedForCache metric is above the max capacity for your target node type, then you receive the following error message:Failed to scale down to cache node type Replication Group <replication_group_name> because the node has insufficient memory. Please select a different node type or reduce current memory usage and retry.Note: By default, each cache node has 25% of its memory reserved for non-data use and background writes. This amount is set in the reserved-memory-percent parameter. This reserved memory reduces the maximum memory used for cache data by 25%. This means that there is a lower amount of memory available for data. You can modify the amount of reserved memory to change the maximum memory available for cache data. This change requires creating a custom parameter group because you can't modify the default parameter group. However, setting the reserve memory percentage to 0 might cause some cluster operations, such as snapshots, to fail.For instructions on cache data size and memory usage, see Why can't I scale down my ElastiCache cluster?Insufficient capacityThe InsufficientCacheClusterCapacity error indicates that Amazon ElastiCache can't allocate as many instances from a given Availability Zone as requested. For information on resolving this error, see Error messages: InsufficientCacheClusterCapacity.Insufficient elastic network interfacesMake sure that you have enough elastic network interface capacity. Use service quotas to increase the limit, if needed. For more information, see How do I get more elastic network interfaces if I've reached the limit in an AWS Region?The specified node type isn't available in the Availability ZoneIf you use a node type that isn't supported in the specified Availability Zone, then you receive the following InvalidParameterValue error message:Specified node type <node_type> is not available in AZ <availability_zone>For instructions on available node types, see Why can't I scale down my ElastiCache cluster?The Redis engine version doesn't support the target node typeSome node types require higher versions of the Redis engine. For more information, see Supported node types.Upgrade the Redis engine version before upgrading to the node type.The ApplyImmediately parameter is set to falseIf the ApplyImmediately parameter is set to false, then changes to the nodes in the replication group are applied on the next maintenance reboot, or the next failure reboot, whichever occurs first. If the change must be immediate, set this parameter to true.Note: How long the node type change takes depends on the node type and how much data is in your cluster. It's a best practice to perform the upgrade when the traffic to the cluster is at the lowest.Heavy node utilizationA heavy workload on the cluster during modification might interfere with ElastiCache workflows. It's a best practice to initiate a node modification during low data traffic hours.Follow"