- 04 Jun, 2017 1 commit
-
-
Antonio Mallia authored
-
- 14 Apr, 2017 1 commit
-
-
antirez authored
To rely on the fact that nodes in PFAIL state will be shared around by randomly adding them in the gossip section is a weak assumption, especially after changes related to sending less ping/pong packets. We want to always include gossip entries for all the nodes that are in PFAIL state, so that the PFAIL -> FAIL state promotion can happen much faster and reliably. Related to #3929.
-
- 13 Apr, 2017 1 commit
-
-
antirez authored
First step in order to change Cluster in order to use less messages. Related to issue #3929.
-
- 27 Mar, 2017 1 commit
-
-
antirez authored
-
- 29 Jan, 2016 2 commits
- 14 Jan, 2016 1 commit
-
-
antirez authored
-
- 11 Dec, 2015 1 commit
-
-
antirez authored
We wait a fixed amount of time (5 seconds currently) much greater than the usual Cluster node to node communication latency, before migrating. This way when a failover occurs, before detecting the new master as a target for migration, we give the time to its natural slaves (the slaves of the failed over master) to announce they switched to the new master, preventing an useless migration operation.
-
- 09 Dec, 2015 1 commit
-
-
antirez authored
Some time ago I broken replicas migration (reported in #2924). The idea was to prevent masters without replicas from getting replicas because of replica migration, I remember it to create issues with tests, but there is no clue in the commit message about why it was so undesirable. However my patch as a side effect totally ruined the concept of replicas migration since we want it to work also for instances that, technically, never had slaves in the past: promoted slaves. So now instead the ability to be targeted by replicas migration, is a new flag "migrate-to". It only applies to masters, and is set in the following two cases: 1. When a master gets a slave, it is set. 2. When a slave turns into a master because of fail over, it is set. This way replicas migration targets are only masters that used to have slaves, and slaves of masters (that used to have slaves... obviously) and are promoted. The new flag is only internal, and is never exposed in the output nor persisted in the nodes configuration, since all the information to handle it are implicit in the cluster configuration we already have.
-
- 27 Jul, 2015 2 commits
- 26 Jul, 2015 1 commit
-
-
antirez authored
-
- 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.
-
- 20 Mar, 2015 1 commit
-
-
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.
-
- 13 Jan, 2015 1 commit
-
-
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.
-
- 28 Nov, 2014 1 commit
-
-
antirez authored
bulk_data field size was not removed from the count. It is not possible to declare it simply as 'char bulk_data[]' since the structure is nested into another structure.
-
- 07 Oct, 2014 1 commit
-
-
antirez authored
-
- 29 Sep, 2014 1 commit
-
-
Matt Stancliff authored
- Remove trailing newlines from redis.conf - Fix comment misspelling - Clarifies zipEncodeLength usage and a C API mention (#1243, #1242) - Fix cluster typos (inspired by @papanikge #1507) - Fix rewite -> rewrite in a few places (inspired by #682) Closes #1243, #1242, #1507
-
- 17 Sep, 2014 1 commit
-
-
antirez authored
-
- 25 Aug, 2014 1 commit
-
-
antirez authored
-
- 22 May, 2014 1 commit
-
-
antirez authored
Check the commit changes in the example redis.conf for more information.
-
- 27 Mar, 2014 1 commit
-
-
antirez authored
Use cammel case for epochs that are persisted on disk.
-
- 10 Mar, 2014 1 commit
-
-
antirez authored
When node-timeout is too small, in the order of a few milliseconds, there is no way the voting process can terminate during that time, so we set a lower limit for the failover timeout of two seconds. The retry time is set to two times the failover timeout time, so it is at least 4 seconds.
-
- 07 Mar, 2014 1 commit
-
-
antirez authored
-
- 06 Mar, 2014 1 commit
-
-
Matt Stancliff authored
REDIS_CLUSTER_IPLEN had the same value as REDIS_IP_STR_LEN. They were both #define'd to the same INET6_ADDRSTRLEN.
-
- 25 Feb, 2014 1 commit
-
-
Matt Stancliff authored
-
- 10 Feb, 2014 3 commits
- 05 Feb, 2014 2 commits
- 31 Jan, 2014 1 commit
-
-
antirez authored
It is possible to configure the min number of additional working slaves a master should be left with, for a slave to migrate to an orphaned master.
-
- 29 Jan, 2014 2 commits
- 28 Jan, 2014 3 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
The two fields are used in order to remember the latest known replication offset and the time we received it from other slave nodes. This will be used by slaves in order to start the election procedure with a delay that is proportional to the rank of the slave among the other slaves for this master, when sorted for replication offset. Usually this allows the slave with the most updated offset to win the election and replace the failing master in the cluster.
-
- 29 Nov, 2013 2 commits
- 08 Nov, 2013 1 commit
-
-
antirez authored
-