- 26 Mar, 2015 1 commit
-
-
asheldon authored
-
- 24 Mar, 2015 4 commits
-
-
antirez authored
-
antirez authored
Bug as old as Redis and blocking operations. It's hard to trigger since only happens on instance role switch, but the results are quite bad since an inconsistency between master and slave is created. How to trigger the bug is a good description of the bug itself. 1. Client does "BLPOP mylist 0" in master. 2. Master is turned into slave, that replicates from New-Master. 3. Client does "LPUSH mylist foo" in New-Master. 4. New-Master propagates write to slave. 5. Slave receives the LPUSH, the blocked client get served. Now Master "mylist" key has "foo", Slave "mylist" key is empty. Highlights: * At step "2" above, the client remains attached, basically escaping any check performed during command dispatch: read only slave, in that case. * At step "5" the slave (that was the master), serves the blocked client consuming a list element, which is not consumed on the master side. This scenario is technically likely to happen during failovers, however since Redis Sentinel already disconnects clients using the CLIENT command when changing the role of the instance, the bug is avoided in Sentinel deployments. Closes #2473.
-
antirez authored
There was a bug in Redis Cluster caused by clients blocked in a blocking list pop operation, for keys no longer handled by the instance, or in a condition where the cluster became down after the client blocked. A typical situation is: 1) BLPOP <somekey> 0 2) <somekey> hash slot is resharded to another master. The client will block forever int this case. A symmentrical non-cluster-specific bug happens when an instance is turned from master to slave. In that case it is more serious since this will desynchronize data between slaves and masters. This other bug was discovered as a side effect of thinking about the bug explained and fixed in this commit, but will be fixed in a separated commit.
-
superlogical authored
-
- 22 Mar, 2015 5 commits
- 21 Mar, 2015 8 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
1. No need to set btype in processUnblockedClients(), since clients flagged REDIS_UNBLOCKED should have it already cleared. 2. When putting clients in the unblocked clients list, clientsArePaused() should flag them with REDIS_UNBLOCKED. Not strictly needed with the current code but is more coherent.
-
antirez authored
-
antirez authored
In no case we should try to attempt to failover if myself->slaveof is NULL.
-
antirez authored
This commit moves the process of generating a new config epoch without consensus out of the clusterCommand() implementation, in order to make it reusable for other reasons (current target is to have a CLUSTER FAILOVER option forcing the failover when no master majority is reachable). Moreover the commit moves other functions which are similarly related to config epochs in a new logical section of the cluster.c file, just for clarity.
-
antirez authored
-
antirez authored
When the list of unblocked clients were processed, btype was set to blocking type none, but the client remained flagged with REDIS_BLOCKED. When timeout is reached (or when the client disconnects), unblocking it will trigger an assertion. There is no need to process pending requests from blocked clients, so now clientsArePaused() just avoid touching blocked clients. Close #2467.
-
- 20 Mar, 2015 3 commits
-
-
antirez authored
-
antirez authored
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.
-
antirez authored
Related to issue #2288.
-
- 18 Mar, 2015 11 commits
-
-
antirez authored
There are rare conditions where node->slaveof may be NULL even if the node is a slave. To check by flag is much more robust.
-
antirez authored
-
antirez authored
-
antirez authored
Related to issue #2372.
-
Mariano Pérez Rodríguez authored
Fixing #2371 as per @mattsta's suggestion
-
antirez authored
Backtrace is a glibc extension, while setproctitle() implementation depends on the memory layout and is partially libc dependent.
-
antirez authored
-
antirez authored
Less grays: more readable palette since usually we have a non linear distribution of percentages and very near gray tones are hard to take apart. Final part of the palette is gradient from yellow to red. The red part is hardly reached because of usual distribution of latencies, but shows up mainly when latencies are very high because of the logarithmic scale, this is coherent to what people expect: red = bad.
-
Masahiko Sawada authored
-
Michel Martens authored
-
antirez authored
-
- 13 Mar, 2015 1 commit
-
-
Leandro López (inkel) authored
When trying to debug sentinel connections or max connections errors it would be very useful to have the ability to see the list of connected clients to a running sentinel. At the same time it would be very helpful to be able to name each sentinel connection or kill offending clients. This commits adds the already defined CLIENT commands back to Redis Sentinel.
-
- 08 Mar, 2015 1 commit
-
-
antirez authored
-
- 04 Mar, 2015 1 commit
-
-
antirez authored
Itereator misuse due to analyzeLatencyForEvent() accessing the dictionary during the iteration, without the iterator being reclared as safe.
-
- 27 Feb, 2015 1 commit
-
-
antirez authored
-
- 26 Feb, 2015 2 commits
-
-
antirez authored
1. Remove useless "cs" initialization. 2. Add a "select" var to capture a condition checked multiple times. 3. Avoid duplication of the same if (!copy) conditional. 4. Don't increment dirty if copy is given (no deletion is performed), otherwise we propagate MIGRATE when not needed.
-
Salvatore Sanfilippo authored
Add last_dbid to migrateCachedSocket to avoid redundant SELECT
-
- 25 Feb, 2015 1 commit
-
-
Tommy Wang authored
Avoid redundant SELECT calls when continuously migrating keys to the same dbid within a target Redis instance.
-
- 13 Feb, 2015 1 commit
-
-
antirez authored
-