diff options
author | antirez <antirez@gmail.com> | 2015-03-20 09:57:10 +0100 |
---|---|---|
committer | antirez <antirez@gmail.com> | 2015-03-20 09:59:28 +0100 |
commit | 25c0f5ac63320e85f81750bd0f999fc6f5eba5c1 (patch) | |
tree | 47329f6724d24fa64d3a0ce8119724b652c2de9f /src/redis.c | |
parent | 2ecb5edf3454e3752a428e50b6ee068e357c7fae (diff) | |
download | redis-25c0f5ac63320e85f81750bd0f999fc6f5eba5c1.tar.gz |
Cluster: better cluster state transiction handling.
Before we relied on the global cluster state to make sure all the hash
slots are linked to some node, when getNodeByQuery() is called. So
finding the hash slot unbound was checked with an assertion. However
this is fragile. The cluster state is often updated in the
clusterBeforeSleep() function, and not ASAP on state change, so it may
happen to process clients with a cluster state that is 'ok' but yet
certain hash slots set to NULL.
With this commit the condition is also checked in getNodeByQuery() and
reported with a identical error code of -CLUSTERDOWN but slightly
different error message so that we have more debugging clue in the
future.
Root cause of issue #2288.
Diffstat (limited to 'src/redis.c')
-rw-r--r-- | src/redis.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/src/redis.c b/src/redis.c index 48e7f24ea..e216109c1 100644 --- a/src/redis.c +++ b/src/redis.c @@ -2219,6 +2219,8 @@ int processCommand(redisClient *c) { * but the slot is not "stable" currently as there is * a migration or import in progress. */ addReplySds(c,sdsnew("-TRYAGAIN Multiple keys request during rehashing of slot\r\n")); + } else if (error_code == REDIS_CLUSTER_REDIR_DOWN) { + addReplySds(c,sdsnew("-CLUSTERDOWN The cluster is down. Hash slot is unbound\r\n")); } else { redisPanic("getNodeByQuery() unknown error."); } |