- 26 Jul, 2015 2 commits
- 24 Jun, 2015 1 commit
-
-
Jan-Erik Rediger authored
-
- 11 Jun, 2015 1 commit
-
-
antirez authored
Related to issues #2609 and #2612.
-
- 24 Mar, 2015 1 commit
-
-
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.
-
- 21 Mar, 2015 2 commits
- 20 Mar, 2015 4 commits
-
-
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
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.
-
- 18 Mar, 2015 1 commit
-
-
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.
-
- 13 Mar, 2015 2 commits
- 10 Mar, 2015 1 commit
-
-
Michel Martens authored
-
- 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.
-
Tommy Wang authored
Avoid redundant SELECT calls when continuously migrating keys to the same dbid within a target Redis instance.
-
- 30 Jan, 2015 2 commits
-
-
antirez authored
This improves PFAIL -> FAIL switch. Too late at this point in the RC releases to add proper PFAIL/FAIL separate dictionary to do this in a less randomized way. Tested in practice with experiments that this helps. PFAIL -> FAIL average with 20 nodes and node-timeout set to 5 seconds takes 2.5 seconds without this commit, 1 second with this commit.
-
antirez authored
-
- 29 Jan, 2015 3 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
Otherwise it is impossible to receive the majority of failure reports in the node_timeout*2 window in larger clusters. Still with a 200 nodes cluster, 20 gossip sections are a very reasonable amount of bytes to send. A side effect of this change is also fater cluster nodes joins for large clusters, because the cluster layout makes less time to propagate.
-
- 24 Jan, 2015 1 commit
-
-
antirez authored
Otherwise we risk sending not initialized data to other nodes, that may contain anything. This was actually not possible only because the initialization of the buffer where the cluster packets header is created was larger than the 3 gossip sections we use, so the memory was already all filled with zeroes by the memset().
-
- 21 Jan, 2015 6 commits
-
-
Matt Stancliff authored
Fixes valgrind error: 48 bytes in 1 blocks are definitely lost in loss record 196 of 373 at 0x4910D3: je_malloc (jemalloc.c:944) by 0x42807D: zmalloc (zmalloc.c:125) by 0x41FA0D: dictGetIterator (dict.c:543) by 0x41FA48: dictGetSafeIterator (dict.c:555) by 0x459B73: clusterHandleSlaveMigration (cluster.c:2776) by 0x45BF27: clusterCron (cluster.c:3123) by 0x423344: serverCron (redis.c:1239) by 0x41D6CD: aeProcessEvents (ae.c:311) by 0x41D8EA: aeMain (ae.c:455) by 0x41A84B: main (redis.c:3832)
-
Matt Stancliff authored
If array has N elements, we can't read +1 if we are already at N. Also, we need to move elements by their storage size in the array, not just by individual bytes.
-
Matt Stancliff authored
[maybe] Fixes valgrind errors: 32 bytes in 4 blocks are definitely lost in loss record 107 of 228 at 0x80EA447: je_malloc (jemalloc.c:944) by 0x806E59C: zrealloc (zmalloc.c:125) by 0x80A9AFC: clusterSetMaster (cluster.c:801) by 0x80AEDC9: clusterCommand (cluster.c:3994) by 0x80682A5: call (redis.c:2049) by 0x8068A20: processCommand (redis.c:2309) by 0x8076497: processInputBuffer (networking.c:1143) by 0x8073BAF: readQueryFromClient (networking.c:1208) by 0x8060E98: aeProcessEvents (ae.c:412) by 0x806123B: aeMain (ae.c:455) by 0x806C3DB: main (redis.c:3832) 64 bytes in 8 blocks are definitely lost in loss record 143 of 228 at 0x80EA447: je_malloc (jemalloc.c:944) by 0x806E59C: zrealloc (zmalloc.c:125) by 0x80AAB40: clusterProcessPacket (cluster.c:801) by 0x80A847F: clusterReadHandler (cluster.c:1975) by 0x30000FF: ??? 80 bytes in 10 blocks are definitely lost in loss record 148 of 228 at 0x80EA447: je_malloc (jemalloc.c:944) by 0x806E59C: zrealloc (zmalloc.c:125) by 0x80AAB40: clusterProcessPacket (cluster.c:801) by 0x80A847F: clusterReadHandler (cluster.c:1975) by 0x2FFFFFF: ???
-
Matt Stancliff authored
Fixes valgrind error: Syscall param write(buf) points to uninitialised byte(s) at 0x514C35D: ??? (syscall-template.S:81) by 0x456B81: clusterWriteHandler (cluster.c:1907) by 0x41D596: aeProcessEvents (ae.c:416) by 0x41D8EA: aeMain (ae.c:455) by 0x41A84B: main (redis.c:3832) Address 0x5f268e2 is 2,274 bytes inside a block of size 8,192 alloc'd at 0x4932D1: je_realloc (jemalloc.c:1297) by 0x428185: zrealloc (zmalloc.c:162) by 0x4269E0: sdsMakeRoomFor.part.0 (sds.c:142) by 0x426CD7: sdscatlen (sds.c:251) by 0x4579E7: clusterSendMessage (cluster.c:1995) by 0x45805A: clusterSendPing (cluster.c:2140) by 0x45BB03: clusterCron (cluster.c:2944) by 0x423344: serverCron (redis.c:1239) by 0x41D6CD: aeProcessEvents (ae.c:311) by 0x41D8EA: aeMain (ae.c:455) by 0x41A84B: main (redis.c:3832) Uninitialised value was created by a stack allocation at 0x457810: nodeUpdateAddressIfNeeded (cluster.c:1236)
-
antirez authored
-
antirez authored
Related to issue #2289.
-
- 19 Jan, 2015 1 commit
-
-
Matt Stancliff authored
read() and write() return ssize_t (signed long), not int. For other offsets, we can use the unsigned size_t type instead of a signed offset (since our replication offsets and buffer positions are never negative).
-
- 13 Jan, 2015 3 commits
-
-
antirez authored
In order to avoid that misconfigured cluster nodes at some time may force an IP update on other nodes, it is required that nodes update their own address only on MEET messages. However it does not make sense to do this the first time a node is contacted and yet does not have an IP, we just risk that myself->ip remains not assigned if there are messages lost or cluster creation procedures that don't make sure everybody is targeted by at least one incoming MEET message. Also fix the logging of the IP switch avoiding the :-1 tail.
-
antirez authored
Also explicitly set version to 0, add a protocol version define, improve comments in the gossip structure. Note that the structure layout is the same after the change, we are just making the padding explicit with an additional not used 16 bits field. So this commit is still able to talk with the previous versions of cluster nodes.
-
antirez authored
Valgrind checks that the buffers we transfer via syscalls are all composed of bytes actually initialized. This is useful, it makes we able to avoid leaking informations in non initialized parts fo messages transferred to other hosts. This commit fixes one of such issues.
-
- 12 Jan, 2015 1 commit
-
-
antirez authored
Can't be initialized by resetManualFailover() since it's actual state the function uses, so we need to initialize it at startup time. Not really a bug in practical terms, but showed up into valgrind and is not technically correct anyway.
-
- 23 Dec, 2014 1 commit
-
-
Matt Stancliff authored
Refactor a common pattern into one function so we don't end up with copy/paste programming.
-
- 17 Dec, 2014 1 commit
-
-
Matt Stancliff authored
If we woke up to accept a connection, but we can't accept it, inform the user of the error going on with their networking. (The previous message was the same for success or error!)
-
- 16 Dec, 2014 1 commit
-
-
antirez authored
-
- 15 Dec, 2014 1 commit
-
-
antirez authored
-
- 11 Dec, 2014 1 commit
-
-
antirez authored
A few code style changes + consistent format: not nice for humans but better for parsers.
-