- 19 Jan, 2016 2 commits
-
-
antirez authored
Centralize cleanup of newargv in a single place. Add more comments to help a bit following a complex function. Related to issue #3016.
-
antirez authored
Another leak was fixed in the case of syntax error by restructuring the allocation strategy for the two dynamic vectors. We also make sure to always close the cached socket on I/O errors so that all the I/O errors are handled the same, even if we had a previously queued error of a different kind from the destination server. Thanks to Kevin McGehee. Related to issue #3016.
-
- 18 Jan, 2016 1 commit
-
-
antirez authored
In issue #3016 Kevin McGehee identified multiple very serious issues in the new implementation of MIGRATE. This commit attempts to restructure the code in oder to avoid mistakes, an analysis of the new implementation is in progress in order to check for possible edge cases.
-
- 14 Jan, 2016 1 commit
-
-
antirez authored
With this commit we preserve the list of nodes that have .slaveof set to the node, even when the node is turned into a slave, and make sure to fix the .slaveof pointers to NULL when a node is freed from memory, regardless of the fact it's a slave or a master. Basically we try to remember the logical master in the current configuration even if the logical master advertised it as a slave already. However we still remember the associations, so that when a node is freed we can fix them. This should fix issue #3002.
-
- 11 Jan, 2016 3 commits
-
-
antirez authored
-
antirez authored
Sometimes during "fixes" we have to setup a new configuration and assign slots to nodes. With BUMPEPOCH we can make sure the new configuration of the node will win if there are conflicting configurations (for example another node is *also* claiming the same slot because the cluster is totally messed up).
-
antirez authored
-
- 08 Jan, 2016 2 commits
-
-
antirez authored
Extend the MIGRATE extra freedom to be able to be called in the context of the local slot, anytime there is a slot open in one or the other direction (importing or migrating). This is useful for redis-trib to fix the cluster when it has in an odd state. Thix fix allows "redis-trib fix" to make its work in certain cases where previously an error was reported.
-
antirez authored
-
- 06 Jan, 2016 1 commit
-
-
antirez authored
For non existing keys, we don't want to send -ASK redirections to MIGRATE, since when moving slots from the migrating node to the importing node, we want just to ignore keys that are no longer there. They may be expired or deleted between the GETKEYSINSLOT call and the MIGRATE call. Otherwise this causes an error during migrations with redis-trib (or equivalent cluster management tools).
-
- 16 Dec, 2015 1 commit
-
-
antirez authored
-
- 11 Dec, 2015 4 commits
-
-
antirez authored
-
antirez authored
We need to process replies after errors in order to delete keys successfully transferred. Also argument rewriting was fixed since it was broken in several ways. Now a fresh argument vector is created and set if we are acknowledged of at least one key.
-
antirez authored
-
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.
-
- 10 Dec, 2015 1 commit
-
-
antirez authored
-
- 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 Nov, 2015 1 commit
-
-
antirez authored
-
- 01 Oct, 2015 2 commits
- 27 Jul, 2015 3 commits
- 26 Jul, 2015 6 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 1 commit
-
-
antirez authored
-