- 14 11月, 2013 2 次提交
-
-
由 antirez 提交于
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 提交于
-
- 13 11月, 2013 11 次提交
- 12 11月, 2013 8 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
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 提交于
Even when messages are received via the slave, we should perform operations (like adding a new Sentinel) in the context of the master.
-
- 11 11月, 2013 3 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
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.
-
由 antirez 提交于
-
- 09 11月, 2013 4 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
Now there is a function that handles the update of the local slot configuration every time we have some new info about a node and its set of served slots and configEpoch. Moreoever the UPDATE packets are now processed when received (it was a work in progress in the previous commit).
-
- 08 11月, 2013 3 次提交
- 07 11月, 2013 1 次提交
-
-
由 antirez 提交于
-
- 06 11月, 2013 7 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
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 提交于
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.
-
由 Salvatore Sanfilippo 提交于
Deprecate utils/redis-copy.rb in favor of redis-copy gem
-
由 Ryan Biesemeyer 提交于
-
由 antirez 提交于
Thanks to @badboy for reporting it.
-
- 05 11月, 2013 1 次提交
-
-
由 antirez 提交于
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.
-