- 21 Nov, 2013 24 commits
-
-
antirez authored
-
antirez authored
Now Sentinel believe the current configuration is always the winner and should be applied by Sentinels instead of trying to adapt our view of the cluster based on what we observe. So the only way to modify what a Sentinel believe to be the truth is to win an election and advertise the new configuration via Pub / Sub with a greater configuration epoch.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
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.
-
- 11 Nov, 2013 1 commit
-
-
antirez authored
-
- 10 Nov, 2013 1 commit
-
-
antirez authored
-
- 07 Nov, 2013 1 commit
-
-
antirez authored
Thanks to @PhoneLi for reporting.
-
- 06 Nov, 2013 4 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.
-
antirez authored
-
- 05 Nov, 2013 8 commits
-
-
antirez authored
Thanks to @badboy for reporting it.
-
antirez authored
The previous implementation of SCAN parsed the cursor in the generic function implementing SCAN, SSCAN, HSCAN and ZSCAN. The actual higher-level command implementation only checked for empty keys and return ASAP in that case. The result was that inverting the arguments of, for instance, SSCAN for example and write: SSCAN 0 key Instead of SSCAN key 0 Resulted into no error, since 0 is a non-existing key name very likely. Just the iterator returned no elements at all. In order to fix this issue the code was refactored to extract the function to parse the cursor and return the error. Every higher level command implementation now parses the cursor and later checks if the key exist or not.
-
antirez authored
The previous implementation assumed that the first call always happens with cursor set to 0, this may not be the case, and we want to return 0 anyway otherwise the (broken) client code will loop forever.
-
antirez authored
-
antirez authored
-
antirez authored
This fixes issue #1360 and #1362.
-
antirez authored
-
antirez authored
-
- 31 Oct, 2013 1 commit
-
-
antirez authored
-