- 26 Feb, 2013 2 commits
-
-
antirez authored
-
antirez authored
This is not very important as anyway when the function counting the number of reports is called the cleanup is performed. However with this change if only part of the nodes that reported the failure will report the node is back ok, we'll cleanup the older entries ASAP. In complex split net split scenarios, and when we are dealing with clusters having nodes in the order of ~ 1000, this can save some CPU.
-
- 25 Feb, 2013 8 commits
-
-
antirez authored
This is the missing part of the API that will be used to reimplement failure detection of Cluster nodes.
-
antirez authored
Not sure why I set a limit to 1 million keys, there is no reason for this artificial limit, and anyway this is s a stupid limit because it is already high enough to create latency issues. So let's the users shoot on their feet because maybe they just actually know what they are doing.
-
antirez authored
-
antirez authored
The new sub-command uses the new countKeysInSlot() API and allows a cluster client to get the number of keys for a given hashslot.
-
antirez authored
-
antirez authored
Redis functions start in low case. A few functions about cluster were capitalized the wrong way.
-
antirez authored
-
antirez authored
See the top-comment for the function in this commit for details about what the function is supposed to do.
-
- 22 Feb, 2013 5 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
The definition of cluster size is: the number of known nodes in the cluster that are masters and serving at least an hash slot.
-
antirez authored
-
antirez authored
A §Redis Cluster node used to mark a node as failing when itself detected a failure for that node, and a single acknowledge was received about the possible failure state. The new API will be used in order to possible to require that N other nodes have a PFAIL or FAIL state for a given node for a node to set it as failing.
-
- 21 Feb, 2013 5 commits
- 20 Feb, 2013 3 commits
- 15 Feb, 2013 4 commits
- 14 Feb, 2013 4 commits
- 05 Feb, 2013 1 commit
-
-
antirez authored
-
- 19 Jan, 2013 1 commit
-
-
guiquanz authored
-
- 14 Nov, 2012 1 commit
-
-
antirez authored
Now that we cache connections, a retry attempt makes sure that the operation don't fail just because there is an existing connection error on the socket, like the other end closing the connection. Unfortunately this condition is not detectable using getsockopt(SO_ERROR), so the only option left is to retry. We don't retry on timeouts.
-
- 12 Nov, 2012 2 commits
-
-
antirez authored
When a timeout <= 0 is provided we set a default timeout of 1 second. It was set to 1 millisecond for an error resulting from a recent change.
-
antirez authored
While it is documented that the MIGRATE timeout is in milliseconds, it was in seconds instead. This commit fixes the problem.
-
- 11 Nov, 2012 1 commit
-
-
antirez authored
By caching TCP connections used by MIGRATE to chat with other Redis instances a 5x performance improvement was measured with redis-benchmark against small keys. This can dramatically speedup cluster resharding and other processes where an high load of MIGRATE commands are used.
-
- 08 Nov, 2012 1 commit
-
-
antirez authored
-
- 07 Nov, 2012 2 commits
-
-
antirez authored
With COPY now MIGRATE does not remove the key from the source instance. With REPLACE it uses RESTORE REPLACE on the target host so that even if the key already eixsts in the target instance it will be overwritten. The options can be used together.
-
antirez authored
The REPLACE option deletes an existing key with the same name (if any) and materializes the new one. The default behavior without RESTORE is to return an error if a key already exists.
-