- 28 Jan, 2016 1 commit
-
-
Itamar Haber authored
-
- 27 Jan, 2016 1 commit
-
-
antirez authored
-
- 26 Jan, 2016 3 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
The change covers the case where: 1. There is a node we can't reach (in fail or pfail state). 2. We see a different address for this node, in the gossip section sent to us by a node that, instead, is able to talk with the node we cannot talk to. In this case it's a good bet to switch to the address reported by this node, since there was an address switch and it is able to talk with the node and we are not. However previosuly this was done in a dangerous way, by initiating an handshake. The handshake, using the MEET packet, forces the receiver to join our cluster, and this is not a good idea. If the node in question really just switched address, but is the same node, it already knows about us, so we just need to perform an address update and a reconnection. So with this commit instead we just update the address of the node, release the node link if any, and attempt to reconnect in the next clusterCron() cycle. The commit also improves debugging messages printed by Cluster during address or ID switches.
-
- 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 1 commit
-
-
antirez authored
-