- 20 5月, 2014 2 次提交
-
-
由 antirez 提交于
Using CLUSTER FAILOVER FORCE it is now possible to failover a master in a forced way, which means: 1) No check to understand if the master is up is performed. 2) No data age of the slave is checked. Evan a slave with very old data can manually failover a master in this way. 3) No chat with the master is attempted to reach its replication offset: the master can just be down.
-
由 antirez 提交于
Automatic failovers only happen in Redis Cluster if the slave trying to be elected was disconnected from its master for no more than 10 times the node-timeout value. However there should be no such a check for manual failovers, since these are initiated by the sysadmin that, in theory, knows what she is doing when a slave is selected to be promoted.
-
- 19 5月, 2014 2 次提交
-
-
由 antirez 提交于
-
由 Mike Trinkala 提交于
Set the MSB as documented.
-
- 12 5月, 2014 10 次提交
-
-
由 Akos Vandra 提交于
(Note: commit message modified by @antirez for clarity).
-
由 Akos Vandra 提交于
-
由 antirez 提交于
This way there is no need for the conflict resolution algo to be used in order to start with a cluster where each node has a different configEpoch.
-
由 antirez 提交于
-
由 antirez 提交于
-
由 antirez 提交于
Will be configurable / adaptive at some point but let's start with a saner value compared to 1 sec which is not a good idea for big data structures stored into a single key.
-
由 antirez 提交于
The error when the target key is busy was a generic one, while it makes sense to be able to distinguish between the target key busy error and the others easily.
-
由 antirez 提交于
-
由 antirez 提交于
Fixes issue #1734.
-
由 antirez 提交于
-
- 09 5月, 2014 3 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
The same change was operated for normal client connections. This is important for Cluster as well, since when a node rejoins the cluster, when a partition heals or after a restart, it gets flooded with new connection attempts by all the other nodes trying to form a full mesh again.
-
由 antirez 提交于
-
- 08 5月, 2014 3 次提交
-
-
由 antirez 提交于
When a Sentinel performs a failover (successful or not), or when a Sentinel votes for a different Sentinel trying to start a failover, it sets a min delay before it will try to get elected for a failover. While not strictly needed, because if multiple Sentinels will try to failover the same master at the same time, only one configuration will eventually win, this serialization is practically very useful. Normal failovers are cleaner: one Sentinel starts to failover, the others update their config when the Sentinel performing the failover is able to get the selected slave to move from the role of slave to the one of master. However currently this timeout was implicit, so users could see Sentinels not reacting, after a failed failover, for some time, without giving any feedback in the logs to the poor sysadmin waiting for clues. This commit makes Sentinels more verbose about the delay: when a master is down and a failover attempt is not performed because the delay has still not elaped, something like that will be logged: Next failover delay: I will not start a failover before Thu May 8 16:48:59 2014
-
由 antirez 提交于
This event makes clear, before the switch-master event is generated, that a Sentinel received a configuration update from another Sentinel.
-
由 antirez 提交于
The new value is the limit for the robj + SDS header + string + null-term to stay inside the 64 bytes Jemalloc arena in 64 bits systems.
-
- 07 5月, 2014 11 次提交
-
-
由 antirez 提交于
SPOP, tested in the new test, is among the commands rewritng the client->argv argument vector (it gets rewritten as SREM) for command replication purposes. Because of recent optimizations to client->argv caching in the context of the Lua internal Redis client, it is important to test for SPOP to be callable from Lua without bad effects to the other commands.
-
由 antirez 提交于
Sometimes the process is still there but no longer in a state that can be checked (after being killed). This used to happen after a call to SHUTDOWN NOSAVE in the scripting unit, causing a false positive.
-
由 antirez 提交于
Reusing small objects when possible is a major speedup under certain conditions, since it is able to avoid the malloc/free pattern that otherwise is performed for every argument in the client command vector.
-
由 antirez 提交于
Replace the three calls to Lua API lua_tostring, lua_lua_strlen, and lua_isstring, with a single call to lua_tolstring. ~ 5% consistent speed gain measured.
-
由 antirez 提交于
Calling lua_gc() after every script execution is too expensive, and apparently does not make the execution smoother: the same peak latency was measured before and after the commit. This change accounts for scripts execution speedup in the order of 10%.
-
由 antirez 提交于
~ 4% consistently measured speed improvement.
-
由 antirez 提交于
Bug introduced when adding a fast path to avoid copying the reply buffer for small replies that fit into the client static buffer.
-
由 antirez 提交于
The function showed up consuming a non trivial amount of time in the profiler output. After this change benchmarking gives a 6% speed improvement that can be consistently measured.
-
由 antirez 提交于
When the reply is only contained in the client static output buffer, use a fast path avoiding the dynamic allocation of an SDS string to concatenate the client reply objects.
-
由 antirez 提交于
-
由 antirez 提交于
It if faster to just create the string with a single sdsnewlen() call. If c->bufpos is zero, the call will simply be like sdsemtpy().
-
- 05 5月, 2014 9 次提交