关于AWS ElastiCache Redis复制组跨版本配置变化的技术咨询

Great question—moving from a standard single-shard Redis replication group (like your Redis 2.8 setup) to cluster-mode enabled in ElastiCache is a common upgrade, and there are critical differences and configuration gotchas to keep in mind. Let’s break this down clearly:

First, let’s clarify the fundamental architectural shifts between the two modes:

• Architecture Model

  • Disabled Cluster Mode (Redis 2.8 style): A single primary node with N replicas. The entire dataset lives on the primary, and replicas sync the full dataset. Your old setup with NumCacheClusters=2 was 1 primary + 1 replica, using PreferredCacheClusterAZs to spread them across AZs for failover.
  • Enabled Cluster Mode (Redis 3.2+): Sharded architecture (controlled via NumNodeGroups—Redis calls these "shards"). Each shard is its own primary+replica group, and your dataset is split across 16384 hash slots assigned to different shards. Each shard can have 0-5 replicas, with failover happening at the shard level.

• Capacity & Scalability

  • Disabled Mode: Your total capacity is limited to the maximum memory of a single node—you can only scale vertically (upgrade node size).
  • Enabled Mode: Horizontal scaling is possible: add more shards (NumNodeGroups) or upgrade individual shard node sizes. Total capacity = number of shards × single node capacity.

• Failover Logic

  • Disabled Mode: If the primary fails, ElastiCache promotes a replica to primary, and the DNS endpoint switches to the new primary. All traffic shifts to the new primary.
  • Enabled Mode: Failover is isolated to individual shards. If one shard’s primary fails, only that shard’s replica is promoted—other shards continue operating normally. This minimizes downtime impact.

• Configuration Parameters

  • Disabled Mode: Use NumCacheClusters to set total nodes (primary + replicas), and PreferredCacheClusterAZs to assign AZs per node.
  • Enabled Mode: NumCacheClusters is ignored. Instead, use NumNodeGroups for shard count, ReplicasPerNodeGroup for replicas per shard, and PreferredAvailabilityZones to map AZs to shard nodes.

Now, let’s dive into the critical points to get right when setting up your cluster-mode replication group:

1. Shard & Replica Planning #

• Shard Count (NumNodeGroups): Calculate based on your total dataset size and performance needs. For example, if a single node holds 10GB and you have 30GB of data, start with 3 shards. Leave headroom for future growth.
• Replicas per Shard (ReplicasPerNodeGroup): Aim for at least 1 replica per shard for high availability. You can go up to 5, but balance redundancy with cost. Replicas sync asynchronously, so they’re great for offloading read traffic (just be aware of minor data consistency delays).

2. AZ Deployment Strategy #

• Use PreferredAvailabilityZones to spread shard primaries and replicas across different AZs. For example, if you have 2 shards and 1 replica per shard:

PreferredAvailabilityZones:
  - us-east-1a  # Shard 1 primary
  - us-east-1b  # Shard 1 replica
  - us-east-1a  # Shard 2 primary
  - us-east-1b  # Shard 2 replica

• Avoid clustering all shard primaries in one AZ—this risks widespread failover if that AZ goes down.

3. Client Compatibility #

• Cluster-mode requires clients that support the Redis Cluster Protocol (e.g., JedisCluster for Java, lettuce’s cluster mode, or redis-py-cluster). These clients automatically route requests to the correct shard based on hash slots.
• Unlike disabled mode, you can’t use a standard Redis client that only connects to a single endpoint.

4. Migration Considerations #

• You can’t directly toggle ClusterMode on an existing replication group. Instead, create a new cluster-mode group, then migrate data:
  • Use Redis’s MIGRATE command to move keys shard-by-shard.
  • Restore a snapshot from your old group to the new cluster-mode group—ElastiCache automatically splits the data across shards by hash slot.

5. Performance & Best Practices #

• Avoid Hot Shards: If certain keys get massive traffic, use hash tags (e.g., {user:123}:profile) to group related keys into the same shard. This prevents one shard from bearing all the load.
• Limit Cross-Shard Operations: Commands like MULTI don’t work across shards, and KEYS/SCAN will scan all shards (which is slow for large clusters). Use shard-specific commands where possible.
• Leverage Read Replicas: Configure clients to route read traffic to replicas to reduce primary node load. Just ensure your application can tolerate eventual consistency.

• Don’t mix NumCacheClusters with cluster mode—it’s ignored, and you’ll get unexpected node counts. Calculate total nodes as NumNodeGroups × (1 + ReplicasPerNodeGroup).
• Cluster mode doesn’t support all Redis commands (e.g., EVAL with cross-shard keys, SELECT for databases). Double-check command compatibility before migrating.
• Automatic failover is enabled by default, but clients need to handle connection resets and re-routing when a shard fails over. Make sure your client library has retry logic built in.

内容的提问来源于stack exchange，提问作者stewart99