Articles

Fix Redis ASK Redirect in Cluster: Slot Migration Explained (2026)

April 18, 2026 6 min read

The Redis cluster’s ASK redirect is happening because a client tried to access a key that’s currently being migrated between nodes.

Here are the common reasons and how to fix them:

1. Client is Stale (Most Common)

Your client library, or the application directly, might be holding onto outdated cluster topology information. When a slot migration starts, the source node tells the cluster it’s temporarily responsible for that slot. If your client doesn’t get this update, it’ll try to talk to the old node, which then sends back an ASK redirect.

  • Diagnosis:

    • Check your client library’s documentation for how it handles cluster topology updates. Many have a cluster nodes command or a similar mechanism to refresh their view of the cluster.
    • Manually run redis-cli -c -h <node_ip> -p <node_port> cluster nodes from a machine that can reach your Redis cluster. Look for slot assignments. If a slot is listed as importing or migrating on one node and stable on another, and your client is hitting the migrating node for a key in that slot, this is likely the cause.

  • Fix:

    • Option A (Client Restart): The simplest fix is often to restart your application instances or the specific client connections. This forces them to re-fetch the cluster topology.
    • Option B (Client Re-initialization): If your client library supports it, trigger a manual cluster topology refresh. For example, in some Python libraries, you might call a refresh_cluster() method.
    • Option C (Configure Client Timeout): Some clients have a timeout for stale topology. Increase this if frequent, short migrations are causing issues and restarts are disruptive. For example, a cluster-refresh-timeout setting.

  • Why it works: This forces the client to query the cluster for its current state, obtaining the correct node responsible for the slot after the migration.

2. Slot Migration in Progress (Expected Behavior)

This is the ASK redirect’s job. When a slot is actively being moved from one master to another, the new master temporarily handles requests for keys in that slot. The old master will redirect clients to the new master using ASK. This is normal during redis-cluster-migrate-slot operations.

  • Diagnosis:

    • Use redis-cli -c -h <node_ip> -p <node_port> cluster slots to see which slots are being migrated. Look for slots with migrating or importing states.
    • Observe the redis-cli --cluster check <nodes_list> output. It will report inconsistencies if migrations are stuck or failing.

  • Fix:

    • Wait: If a migration is actively in progress and healthy, the best "fix" is often to wait for it to complete. redis-cli --cluster migrate commands can take time, especially with large datasets or network latency.
    • Monitor: Keep an eye on the migration process. If it’s stuck, you might need to troubleshoot network connectivity or resource issues on the involved nodes.

  • Why it works: The ASK redirect is the designed mechanism for handling this phase of slot movement, ensuring data availability.

3. Network Partition or Firewall Issues

If nodes within the cluster cannot communicate with each other properly, topology updates can be delayed or missed. A node might think it still owns a slot when it’s actually being migrated away, or the client might be trying to talk to a node that is temporarily unreachable for cluster state updates.

  • Diagnosis:

    • From each Redis node, try to ping all other Redis nodes.
    • Check firewall rules on all nodes and any intermediate network devices. Ensure ports 16379 (client port) and 16379 + 10000 (cluster bus port) are open between all nodes.
    • Use redis-cli -c -h <node_ip> -p <node_port> cluster nodes on various nodes. Compare the output. If nodes report different sets of peers or incorrect slot ownership, network issues are likely.

  • Fix:

    • Open Firewall Ports: Ensure 16379 and 16379+10000 are open bi-directionally between all cluster nodes.
    • Resolve Network Connectivity: Fix any routing problems or network device misconfigurations.
    • Restart Nodes (Carefully): In rare cases, a full cluster restart (one node at a time, waiting for others to stabilize) can help re-establish consistent cluster state after network issues are resolved.

  • Why it works: Restoring full inter-node communication allows nodes to reliably exchange cluster state, including slot ownership and migration status, enabling clients to get accurate redirects.

4. Incorrect Cluster Configuration (cluster-enable yes)

If Redis was started without cluster-enable yes in its configuration, or if the configuration file was changed and Redis restarted without applying the cluster configuration, the cluster functionality won’t be active. Even if you manually try to set up a cluster, it won’t behave correctly.

  • Diagnosis:

    • Check the redis.conf file for each node. Ensure cluster-enable yes is present and uncommented.
    • Run redis-cli -h <node_ip> -p <node_port> INFO server. Look for "cluster_enabled:1". If it’s 0, clustering is not enabled.

  • Fix:

    • Add cluster-enable yes: Add or uncomment cluster-enable yes in your redis.conf file.
    • Restart Redis Nodes: Restart all Redis instances for the change to take effect.
    • Re-create Cluster: You will likely need to destroy and recreate the cluster using redis-cli --cluster create ... after enabling clustering on all nodes.

  • Why it works: Ensures the Redis server process is actually running in cluster mode, enabling all cluster-specific features, including slot management and redirects.

5. Client Trying to Access a Slot on the Wrong Node (Manual Intervention)

If you’ve manually moved a slot using redis-cli --cluster setslot <slot> IMPORTING <target_node_id> or MIGRATING without the corresponding IMPORTING on the target node, or if the migration process was interrupted, a client might get an ASK redirect to a node that isn’t properly prepared to receive the slot.

  • Diagnosis:

    • Use redis-cli -c -h <node_ip> -p <node_port> cluster slots on multiple nodes.
    • Check the cluster_state of the nodes involved in the slot migration.
    • Verify that for a slot S being moved from NodeA to NodeB:
      • NodeA has MIGRATING for slot S.
      • NodeB has IMPORTING for slot S.
      • NodeB is the master for slot S according to cluster slots on other nodes.

  • Fix:

    • Complete Migration: If NodeB is IMPORTING slot S, and NodeA is MIGRATING slot S, ensure you initiate the actual data transfer (e.g., redis-cli --cluster reshard or redis-cli --cluster migrate-slot if using newer versions and manual control).
    • Reset Slot State: If the state is inconsistent (e.g., MIGRATING without a corresponding IMPORTING), you might need to reset the slot state on the nodes. For example, on NodeA, run redis-cli -h <node_a_ip> -p <node_a_port> cluster setslot <slot> STABLE <node_a_master_id>. Then, on NodeB, run redis-cli -h <node_b_ip> -p <node_b_port> cluster setslot <slot> STABLE <node_b_master_id>. After resetting, you can re-initiate the migration correctly.

  • Why it works: Ensures that the slot state is consistent across the cluster, and that the target node is correctly configured to receive and serve keys for the slot being migrated.

The next error you’ll likely encounter if you haven’t fixed the underlying issue is the MOVED error, indicating that the client is still trying to access a key on a node that no longer owns its slot.

Want structured learning?

Take the full Redis course →