- 21 Nov, 2013 18 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
This commit also removes some dead code and cleanup generic flags.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
Changes to leadership handling. Now the leader gets selected by every Sentinel, for a specified epoch, when the SENTINEL is-master-down-by-addr is sent. This command now includes the runid and the currentEpoch of the instance seeking for a vote. The Sentinel only votes a single time in a given epoch. Still a work in progress, does not even compile at this stage.
-
antirez authored
Even when messages are received via the slave, we should perform operations (like adding a new Sentinel) in the context of the master.
-
antirez authored
-
antirez authored
Sentinel state now includes the idea of current epoch and config epoch. In the Hello message, that is now published both on masters and slaves, a Sentinel no longer just advertises itself but also broadcasts its current view of the configuration: the master name / ip / port and its current epoch. Sentinels receiving such information switch to the new master if the configuration epoch received is newer and the ip / port of the master are indeed different compared to the previos ones.
-
- 06 Nov, 2013 3 commits
-
-
antirez authored
-
antirez authored
AUTH and SCRIPT KILL were sent without incrementing the pending commands counter. Clearly this needs some kind of wrapper doing it for the caller in order to be less bug prone.
-
antirez authored
This change makes Sentinel less fragile about a number of failure modes. This commit also fixes a different bug as a side effect, SLAVEOF command was sent multiple times without incrementing the pending commands count.
-
- 24 Jul, 2013 1 commit
-
-
antirez authored
Actaully the string is modified in-place and a reallocation is never needed, so there is no need to return the new sds string pointer as return value of the function, that is now just "void".
-
- 11 Jul, 2013 6 commits
-
-
antirez authored
-
antirez authored
We use comma to play well with IPv6 addresses, but the implementation is still able to parse the old messages separated by colons.
-
antirez authored
With ipv6 support we need more space, so we account for the IP address max size plus what we need for the Run ID, port, flags.
-
antirez authored
-
Geoff Garside authored
This has been done by exposing the anetSockName() function anet.c to be used when the sentinel is publishing its existence to the masters. This implementation is very unintelligent as it will likely break if used with IPv6 as the nested colons will break any parsing of the PUBLISH string by the master.
-
Geoff Garside authored
-
- 20 Jun, 2013 1 commit
-
-
antirez authored
Sentinel was not able to detect slaves when connected to a very recent version of Redis master since a previos non-backward compatible change to INFO broken the parsing of the slaves ip:port INFO output. This fixes issue #1164
-
- 30 Apr, 2013 3 commits
-
-
antirez authored
Tilt mode was too aggressive (not processing INFO output), this resulted in a few problems: 1) Redirections were not followed when in tilt mode. This opened a window to misinform clients about the current master when a Sentinel was in tilt mode and a fail over happened during the time it was not able to update the state. 2) It was possible for a Sentinel exiting tilt mode to detect a false fail over start, if a slave rebooted with a wrong configuration about at the same time. This used to happen since in tilt mode we lose the information that the runid changed (reboot). Now instead the Sentinel in tilt mode will still remove the instance from the list of slaves if it changes state AND runid at the same time. Both are edge conditions but the changes should overall improve the reliability of Sentinel.
-
antirez authored
-
antirez authored
We used to always turn a master into a slave if the DEMOTE flag was set, as this was a resurrecting master instance. However the following race condition is possible for a Sentinel that got partitioned or internal issues (tilt mode), and was not able to refresh the state in the meantime: 1) Sentinel X is running, master is instance "A". 3) "A" fails, sentinels will promote slave "B" as master. 2) Sentinel X goes down because of a network partition. 4) "A" returns available, Sentinels will demote it as a slave. 5) "B" fails, other Sentinels will promote slave "A" as master. 6) At this point Sentinel X comes back. When "X" comes back he thinks that: "B" is the master. "A" is the slave to demote. We want to avoid that Sentinel "X" will demote "A" into a slave. We also want that Sentinel "X" will detect that the conditions changed and will reconfigure itself to monitor the right master. There are two main ways for the Sentinel to reconfigure itself after this event: 1) If "B" is reachable and already configured as a slave by other sentinels, "X" will perform a redirection to "A". 2) If there are not the conditions to demote "A", the fact that "A" reports to be a master will trigger a failover detection in "X", that will end into a reconfiguraiton to monitor "A". However if the Sentinel was not reachable, its state may not be updated, so in case it titled, or was partiitoned from the master instance of the slave to demote, the new implementation waits some time (enough to guarantee we can detect the new INFO, and new DOWN conditions). If after some time still there are not the right condiitons to demote the instance, the DEMOTE flag is cleared.
-
- 24 Apr, 2013 1 commit
-
-
antirez authored
Sentinel redirected to the master if the instance changed runid or it was the first time we got INFO, and a role change was detected from master to slave. While this is a good idea in case of slave->master, since otherwise we could detect a failover without good reasons just after a reboot with a slave with a wrong configuration, in the case of master->slave transition is much better to always perform the redirection for the following reasons: 1) A Sentinel may go down for some time. When it is back online there is no other way to understand there was a failover. 2) Pointing clients to a slave seems to be always the wrong thing to do. 3) There is no good rationale about handling things differently once an instance is rebooted (runid change) in that case.
-
- 22 Apr, 2013 1 commit
-
-
antirez authored
-
- 11 Feb, 2013 1 commit
-
-
antirez authored
-
- 19 Jan, 2013 1 commit
-
-
guiquanz authored
Conflicts fixed, mainly because 2.8 has no cluster support / files: 00-RELEASENOTES src/cluster.c src/crc16.c src/redis-trib.rb src/redis.h
-
- 08 Nov, 2012 1 commit
-
-
antirez authored
-
- 27 Sep, 2012 3 commits
-
-
antirez authored
-
antirez authored
If we don't have any clue about a master since it never replied to INFO so far, reply with an -IDONTKNOW error to SENTINEL get-master-addr-by-name requests.
-
antirez authored
Before this commit Sentienl used to redirect master ip/addr if the current instance reported to be a slave only if this was the first INFO output received, and the role was found to be slave. Now instead also if we find that the runid is different, and the reported role is slave, we also redirect to the reported master ip/addr. This unifies the behavior of Sentinel in the case of a reboot (where it will see the first INFO output with the wrong role and will perform the redirection), with the behavior of Sentinel in the case of a change in what it sees in the INFO output of the master.
-