Fix install server #752

wants to merge 387 commits into


None yet
ambakshi commented Nov 4, 2012

No description provided.

and others added some commits Apr 13, 2012
@antirez A few var names fixed in Makefile.
I modified it for error in a previous commit doing search & replace.
@antirez Protect globals access in Lua scripting. 430602b
@antirez Scripting: globals protection can now be switched on/off. 3e6a446
@antirez Tests for lua globals protection. e387dc5
@antirez Globals protection global() function modified for speed and correctness. 6255a5a
@antirez Stop access to global vars. Not configurable.
After considering the interaction between ability to delcare globals in
scripts using the 'global' function, and the complexities related to
hanlding replication and AOF in a sane way with globals AND ability to
turn protection On and Off, we reconsidered the design. The new design
makes clear that there is only one good way to write Redis scripts, that
is not using globals. In the rare cases state must be retained across
calls a Redis key can be used.
@antirez mt.declared is no longer needed.
Lua global protection can now be simpified becuase we no longer have the
global() function. It's useless to occupy memory with this table, it is
also not faster because the metamethods we use are only called when a
global object does not exist or we are trying to create it from a
@antirez Tests modified to match the new global protection implementation. d63a171
@antirez Use Lua tostring() before concatenation. c9853f5
@antirez EVAL errors are more clear now. 9a2dd1e
@antirez New test for scripting engine: DECR_IF_GT. 59333ff
@pietern pietern Rename ADD_*FLAGS -> REDIS_*FLAGS, REDIS_*FLAGS -> FINAL_*FLAGS
This reflects that REDIS_*FLAGS will only be used for compilation of
Redis and not for its dependencies. Similarly, that FINAL_*FLAGS are
composed of other variables and holds the options that are finally
passed to the compiler and linker.
@pietern pietern The lcov target shouldn't clean
This is not needed because every change in compiler/linker flags
triggers a cleanup.
@pietern pietern Ignore gcov/lcov artifacts cb481f4
@pietern pietern Question mark assignment is not needed 95bc195
@pietern pietern First set defaults, then do composition 61e8825
@pietern pietern Remove unused LIBS variable 3126e08
@pietern pietern Don't set flags recursively 8642295
@pietern pietern Persist `make` settings and trigger rebuild if anything changes d0cd262
@antirez Less false positives in maxclients test, hopefully. 96aeca4
@antirez lookupKeyByPattern() used by SORT GET/BY rewritten. Fixes issue #460.
lookupKeyByPattern() was implemented with a trick to speedup the lookup
process allocating two fake Redis obejcts on the stack. However now that
we propagate expires to the slave as DEL operations the lookup of the
key may result into a call to expireIfNeeded() having the stack
allocated object as argument, that may in turn use it to create the
protocol to send to the slave. But since this fake obejcts are
inherently read-only this is a problem.

As a side effect of this fix there are no longer size limits in the
pattern to be used with GET/BY option of SORT.

See antirez#460 for bug details.
@antirez Added test for SORT corner case: pattern ending with just "->". a1090c1
@antirez Two small fixes to maxclients handling.
1) Don't accept maxclients set to < 0
2) Allow maxclients < 1024, it is useful for testing.
@antirez More robust maxclients test. 212bb9c
@antirez Marginally cleaner lookupKeyByPattern() implementation.
just fieldobj itself as sentinel of the fact a field object is used or
not, instead of using the filed length, that may be confusing both for
people and for the compiler emitting a warning.
@antirez Merge pull request #455 from pietern/2.6-mkopts
Persist Makefile flags (2.6)
@antirez Test LINDEX out of range index. 8d12645
@antirez Test LINSERT syntax error. a00fcaa
@antirez Explicit RPOP/LPOP tests. bec200e
@antirez Document mostly dead code in RPOPLPUSH implementation. 60ef787
@antirez New hash fuzzing test. 24982f2
@antirez Added an SMOVE test where src and dest key are the same. ff5e31f
@antirez Test SINTER with non existing key. eb624e3
@antirez Test SINTER against same integer elements, but different set encoding. 7a2065e
@antirez Test SDIFF with first set empty. 5c45ae1
@antirez redis-cli --bigkeys e107685
@antirez redis-cli --bigkeys output modified to be simpler to read.. 0122cc4
@antirez cr16.c removed from 2.6 branch, was not used. 1d82bbd
@antirez Tests for scripting PRNG. c331276
@antirez Currenly not used code in dict.c commented out. d54943b
@antirez SHUTDOWN NOSAVE now can stop a non returning script. Issue #466. ca577d1
@antirez New tests related to scripts max execution time. abfd08f
@antirez README now makes clear that our support for solaris derived systems i…
…s "best effort".
@antirez redis.conf AOF section comments improved. c11a01a
@antirez Limit memory used by big SLOWLOG entries.
Two limits are added:

1) Up to SLOWLOG_ENTRY_MAX_ARGV arguments are logged.
2) Up to SLOWLOG_ENTRY_MAX_STRING bytes per argument are logged.
3) slowlog-max-len is set to 128 by default (was 1024).

The number of remaining arguments / bytes is logged in the entry
so that the user can understand better the nature of the logged command.
@antirez Even inside #if 0 comments are comments. e337b26
@schlenk schlenk Replace unnecessary calls to echo and cat
Tcl's exec can send data to stdout itself, no need to call cat/echo for
that usually.
@antirez Remove loadfile() access from the scripting engine. 537dafa
@antirez New time limit for protocol desync test set to 30 seconds to reduce f…
…alse positives.
@antirez Ziplist encoding now tested with negative integers as well. 69b30cf
@antirez Fix and refactoring of code used to get registers on crash.
This fixes compilation on FreeBSD (and possibly other systems) by
not using ucontext_t at all if HAVE_BACKTRACE is not defined.
Also the ifdefs to get the registers are modified to explicitly test for the
operating system in the first level, and the arch in the second level
of nesting.
@antirez A few compiler warnings suppressed. 9de5d46
@grisha grisha Add a 24bit integer to ziplists to save one byte for ints that can
fit in 24 bits (thanks to antirez for catching and solving the two's compliment

Increment REDIS_RDB_VERSION to 6
@antirez ziplist.c: added comments about the new 24 bit encoding. dd51571
@antirez rdbLoad() should check REDIS_RDB_VERSION instead of hardcoded number. 62bfa66
@antirez Added two new encodings to ziplist.c
1) One integer "immediate" encoding that can encode from 0 to 12 in the
encoding byte itself.
2) One 8 bit signed integer encoding that can encode 8 bit signed small
integers in a single byte.

The idea is to exploit all the not used bits we have around in a
backward compatible way.
@antirez Spurious debugging printf removed. 717145c
@antirez redis-check-dump now is RDB version 6 ready. 12a042f
@antirez Explicitly use bash for Fixes issue #397 c16bf71
@dtran320 dtran320 Spelling: s/synchrnonization/synchronization 8111a80
@antirez Redis test: scripting EVALSHA replication test more reliable.
A new primitive wait_for_condition was introduced in the scripting
engine that makes waiting for events simpler, so that it is simpler to
write tests that are more resistant to timing issues.
@antirez Redis test: More reliable BRPOPLPUSH replication test.
Now it uses the new wait_for_condition testing primitive.
Also wait_for_condition implementation was fixed in this commit to properly
escape the expr command and its argument.
@antirez Don't use an alternative stack for SIGSEGV & co.
This commit reverts most of c575766, in
order to use back main stack for signal handling.

The main reason is that otherwise it is completely pointless that we do
a lot of efforts to print the stack trace on crash, and the content of
the stack and registers as well. Using an alternate stack broken this
feature completely.
@antirez Produce the stack trace in an async safe way. 9db4cea
@antirez Re-introduce -g -rdynamic -ggdb when linking, fixing strack traces.
A previous commit removed -g -rdynamic -ggdb as LDFLAGS, not allowing
Redis to produce a stack trace wth symbol names on crash.
This commit fixes the issue.
@antirez Set LUA_MASKCOUNT hook more selectively. Fixes issue #480.
An user reported a crash with Redis scripting (see issue #480 on
github), inspection of the kindly provided strack trace showed that
server.lua_caller was probably set to NULL. The stack trace also slowed
that the call to the hook was originating from a point where we just
used to set/get a few global variables in the Lua state.

What was happening is that we did not set the timeout hook selectively
only when the user script was called. Now we set it more selectively,
specifically only in the context of the lua_pcall() call, and make sure
to remove the hook when the call returns. Otherwise the hook can get
called in random contexts every time we do something with the Lua
@antirez Update makefile dependencies. b1aa718
@antirez redis-cli commands description in help.h updated. 2c0aae7
@antirez Release notes updated with the new 2.6 features. 748f206
@antirez memtest.c fixed to actually use v1 and v2 in memtest_fill_value(). 603adb2
@antirez Redis 2.5.7 (2.6 RC1) 7c5d96d
@antirez Fixed release notes typo 8b97442
@antirez yet another typo fixed in release notes. 18759c9
@antirez Added "read-only slaves" in new features section of 2.6 release notes. b330de5
@antirez A more lightweight implementation of issue 141 regression test. dd41887
@antirez Properly wait the slave to sync with master in BRPOPLPUSH test. 8f984be
@alicebob alicebob Show problem with 'keys' command with specific command sequence. 8520066
@pietern pietern Use safe dictionary iterator from KEYS
Every matched key in a KEYS call is checked for expiration. When the key
is set to expire, the call to `getExpire` will assert that the key also
exists in the main dictionary. This in turn causes a rehashing step to
be executed. Rehashing a dictionary when there is an iterator active may
result in the iterator emitting duplicate entries, or not emitting some
entries at all. By using a safe iterator, the rehash step is omitted.
@antirez Merge pull request #488 from pietern/2.6-safekeys
Use safe dictionary iterator from KEYS (fixes #487)
@antirez Test "Turning off AOF kills the background writing child if any" is n…
…ow more reliable.
@antirez Redis 2.5.8 (2.6.0 RC2). 0f07781
@antirez Add a note abotu read-only slaves in 2.6 release notes. 96d9c6c
@antirez Use specific error if master is down and slave-serve-stale-data is se…
…t to no.

We used to reply -ERR ... message ..., now the reply is
instead -MASTERDOWN ... message ... so that it can be distinguished
easily by the other error conditions.
@antirez Remove useless trailing space in SYNC command sent to master. 9b43b1e
@antirez syncio.c read / write functions reworked for correctness and performa…

The new implementation start reading / writing before blocking with
aeWait(), likely the descriptor can accept writes or has buffered data
inside and we can go faster, otherwise we get an error and wait.

This change has effects on speed but also on correctness: on socket
errors when we perform non blocking connect(2) write is performed ASAP
and the error is returned ASAP before waiting.

So the practical effect is that now a Redis slave is more available if it
can not connect to the master, previously the slave continued to block on
syncWrite() trying to send SYNC, and serving commands very slowly.
quiver fix several bugs of init.d scripts
- PIDFILE environ variable was not properly retrieved
- chkconfig command failed
@pietern pietern Fix `install` target on OSX (see #495) 1b1cf8e
@pietern pietern Compare integers in ziplist regardless of encoding
Because of the introduction of new integer encoding types for ziplists
in the 2.6 tree, the same integer value may have a different encoding in
different versions of the ziplist implementation. This means that the
encoding can NOT be used as a fast path in comparing integers.
@antirez Merge pull request #500 from pietern/2.6-zipfix
Compare integers in ziplist regardless of encoding
@antirez Redis 2.5.9 (2.6 RC3). 184b8e7
@antirez More complete release notes for 2.5.9 af2455b
@antirez Fixed typo in RC3 release notes. 8afa5b7
@antirez Allow PREFIX to be overrided in Makefile. f580a3e
@antirez Fix PREFIX typo in Makefile. 91d1850
@antirez redis-cli --pipe for mass import. dd4e820
@antirez redis-cli pipe mode: handle EAGAIN while writing to socket. 346825c
@antirez redis-cli pipe mode: handle EINTR properly as well so that SIGSTOP/SI…
…GCONT are handled correctly.
@antirez If the computer running the Redis test is slow, we revert to --client…
…s 1 to avoid false positives.
@antirez More incremental active expired keys collection process.
If a large amonut of keys are all expiring about at the same time, the
"active" expired keys collection cycle used to block as far as the
percentage of already expired keys was >= 25% of the total population of
keys with an expire set.

This could block the server even for many seconds in order to reclaim
memory ASAP. The new algorithm uses at max a small amount of
milliseconds per cycle, even if this means reclaiming the memory less
promptly it also means a more responsive server.
@antirez Comment improved so that the code goal is more clear. Thx to @agladysh. f078d56
saj and others added some commits Jul 16, 2012
@saj saj Truncate short write from the AOF
If Redis only manages to write out a partial buffer, the AOF file won't
load back into Redis the next time it starts up.  It is better to
discard the short write than waste time running redis-check-aof.
@mgp mgp Use correct variable name for value to convert.
Note by @antirez: this code was never compiled because utils.c lacked the
float.h include, so we never noticed this variable was mispelled in the

This should provide a noticeable speed boost when saving certain types
of databases with many sorted sets inside.
@antirez Redis 2.5.12 (2.6 RC6). 73d3e87
@tobstarr tobstarr Fix version numbers 013189e
@pietern pietern Add ziplist test for deleting next to last entries 89bf6f5
@pietern pietern Set p to its new offset before modifying it 2f44452
@antirez hiredis library updated.
This version of hiredis merges modifications of the Redis fork with
latest changes in the hiredis repository.

The same version was pushed on the hiredis repository and will probably
merged into the master branch in short time.
@antirez redis-benchmark: disable big buffer cleanup in hiredis context.
This new hiredis features allows us to reuse a previous context reader
buffer even if already very big in order to maximize performances with
big payloads (Usually hiredis re-creates buffers when they are too big
and unused in order to save memory).
@antirez Better Out of Memory handling.
The previous implementation of zmalloc.c was not able to handle out of
memory in an application-specific way. It just logged an error on
standard error, and aborted.

The result was that in the case of an actual out of memory in Redis
where malloc returned NULL (In Linux this actually happens under
specific overcommit policy settings and/or with no or little swap
configured) the error was not properly logged in the Redis log.

This commit fixes this problem, fixing issue #509.
Now the out of memory is properly reported in the Redis log and a stack
trace is generated.

The approach used is to provide a configurable out of memory handler
to zmalloc (otherwise the default one logging the event on the
standard output is used).
@antirez Fix a forget zmalloc_oom() -> zmalloc_oom_handler() replacement. 06bd3b9
@antirez Incrementally flush RDB on disk while loading it from a master.
This fixes issue #539.

Basically if there is enough free memory the OS may buffer the RDB file
that the slave transfers on disk from the master. The file may
actually be flused on disk at once by the operating system when it gets
closed by Redis, causing the close system call to block for a long time.

This patch is a modified version of one provided by yoav-steinberg of
@garantiadata (the original version was posted in the issue #539
comments), and tries to flush the OS buffers incrementally (every 8 MB
of loaded data).
@antirez Scripting: require at least one argument for
Redis used to crash with a call like the following:

    EVAL "" 0

Now the explicit check for at least one argument prevents the problem.

This commit fixes issue #655.
@antirez Sentinel: Redis-side support for slave priority.
A Redis slave can now be configured with a priority, that is an integer
number that is shown in INFO output and can be get and set using the
redis.conf file or the CONFIG GET/SET command.

This field is used by Sentinel during slave election. A slave with lower
priority is preferred. A slave with priority zero is never elected (and
is considered to be impossible to elect even if it is the only slave

A next commit will add support in the Sentinel side as well.
@antirez Sentinel: added documentation about slave-priority in redis.conf 851ac9d
@antirez Scripting: Reset Lua fake client reply_bytes after command execution.
Lua scripting uses a fake client in order to run commands in the context
of a client, accumulate the reply, and convert it into a Lua object
to return to the caller. This client is reused again and again, and is
referenced by the server.lua_client globally accessible pointer.

However after every call to or redis.pcall(), that is
handled by the luaRedisGenericCommand() function, the reply_bytes field
of the client was not set back to zero. This filed is used to estimate
the amount of memory currently used in the reply. Because of the lack of
reset, script after script executed, this value used to get bigger and
bigger, and in the end on 32 bit systems it triggered the following

    redisAssert(c->reply_bytes < ULONG_MAX-(1024*64));

On 64 bit systems this does not happen because it takes too much time to
reach values near to 2^64 for users to see the practical effect of the

Now in the cleanup stage of luaRedisGenericCommand() we reset the
reply_bytes counter to zero, avoiding the issue. It is not practical to
add a test for this bug, but the fix was manually tested using a

This commit fixes issue #656.
@antirez Send an async PING before starting replication with master.
During the first synchronization step of the replication process, a Redis
slave connects with the master in a non blocking way. However once the
connection is established the replication continues sending the REPLCONF
command, and sometimes the AUTH command if needed. Those commands are
send in a partially blocking way (blocking with timeout in the order of

Because it is common for a blocked master to accept connections even if
it is actually not able to reply to the slave requests, it was easy for
a slave to block if the master had serious issues, but was still able to
accept connections in the listening socket.

For this reason we now send an asynchronous PING request just after the
non blocking connection ended in a successful way, and wait for the
reply before to continue with the replication process. It is very
unlikely that a master replying to PING can't reply to the other

This solution was proposed by Didier Spezia (Thanks!) so that we don't
need to turn all the replication process into a non blocking affair, but
still the probability of a slave blocked is minimal even in the event of
a failing master.

Also we now use getsockopt(SO_ERROR) in order to check errors ASAP
in the event handler, instead of waiting for actual I/O to return an

This commit fixes issue #632.
@antirez Scripting: Force SORT BY constant determinism inside SORT itself.
SORT is able to return (faster than when ordering) unordered output if
the "BY" clause is used with a constant value. However we try to play
well with scripting requirements of determinism providing always sorted
outputs when SORT (and other similar commands) are called by Lua

However we used the general mechanism in place in scripting in order to
reorder SORT output, that is, if the command has the "S" flag set, the
Lua scripting engine will take an additional step when converting a
multi bulk reply to Lua value, calling a Lua sorting function.

This is suboptimal as we can do it faster inside SORT itself.
This is also broken as issue #545 shows us: basically when SORT is used
with a constant BY, and additionally also GET is used, the Lua scripting
engine was trying to order the output as a flat array, while it was
actually a list of key-value pairs.

What we do know is to recognized if the caller of SORT is the Lua client
(since we can check this using the REDIS_LUA_CLIENT flag). If so, and if
a "don't sort" condition is triggered by the BY option with a constant
string, we force the lexicographical sorting.

This commit fixes this bug and improves the performance, and at the same
time simplifies the implementation. This does not mean I'm smart today,
it means I was stupid when I committed the original implementation ;)
@saj saj Bug fix: slaves being pinged every second
REDIS_REPL_PING_SLAVE_PERIOD controls how often the master should
transmit a heartbeat (PING) to its slaves.  This period, which defaults
to 10, is measured in seconds.

Redis 2.4 masters used to ping their slaves every ten seconds, just like
it says on the tin.

The Redis 2.6 masters I have been experimenting with, on the other hand,
ping their slaves *every second*.  (master_last_io_seconds_ago never
approaches 10.)  I think the ping period was inadvertently slashed to
one-tenth of its nominal value around the time REDIS_HZ was introduced.
This commit reintroduces correct ping schedule behaviour.
@trapezoid trapezoid BITCOUNT: fix segmentation fault.
remove unsafe and unnecessary cast.
until now, this cast may lead segmentation fault when end > UINT_MAX

setbit foo 0 1
bitcount  0 4294967295
=> ok
bitcount  0 4294967296
=> cause segmentation fault.

Note by @antirez: the commit was modified a bit to also change the
string length type to long, since it's guaranteed to be at max 512 MB in
size, so we can work with the same type across all the code path.

A regression test was also added.
@antirez BITCOUNT regression test for #582 fixed for 32 bit target.
Bug #582 was not present in 32 bit builds of Redis as
getObjectFromLong() will return an error for overflow.

This commit makes sure that the test does not fail because of the error
returned when running against 32 bit builds.
@antirez Match printf format with actual type in genRedisInfoString(). efb54f0
@antirez Make sure that SELECT argument is an integer or return an error.
Unfortunately we had still the lame atoi() without any error checking in
place, so "SELECT foo" would work as "SELECT 0". This was not an huge
problem per se but some people expected that DB can be strings and not
just numbers, and without errors you get the feeling that they can be
numbers, but not the behavior.

Now getLongFromObjectOrReply() is used as almost everybody else across
the code, generating an error if the number is not an integer or
overflows the long type.

Thanks to @mipearson for reporting that on Twitter.
@antirez A reimplementation of blocking operation internals.
Redis provides support for blocking operations such as BLPOP or BRPOP.
This operations are identical to normal LPOP and RPOP operations as long
as there are elements in the target list, but if the list is empty they
block waiting for new data to arrive to the list.

All the clients blocked waiting for th same list are served in a FIFO
way, so the first that blocked is the first to be served when there is
more data pushed by another client into the list.

The previous implementation of blocking operations was conceived to
serve clients in the context of push operations. For for instance:

1) There is a client "A" blocked on list "foo".
2) The client "B" performs `LPUSH foo somevalue`.
3) The client "A" is served in the context of the "B" LPUSH,

Processing things in a synchronous way was useful as if "A" pushes a
value that is served by "B", from the point of view of the database is a
NOP (no operation) thing, that is, nothing is replicated, nothing is
written in the AOF file, and so forth.

However later we implemented two things:

1) Variadic LPUSH that could add multiple values to a list in the
context of a single call.
2) BRPOPLPUSH that was a version of BRPOP that also provided a "PUSH"
side effect when receiving data.

This forced us to make the synchronous implementation more complex. If
client "B" is waiting for data, and "A" pushes three elemnents in a
single call, we needed to propagate an LPUSH with a missing argument
in the AOF and replication link. We also needed to make sure to
replicate the LPUSH side of BRPOPLPUSH, but only if in turn did not
happened to serve another blocking client into another list ;)

This were complex but with a few of mutually recursive functions
everything worked as expected... until one day we introduced scripting
in Redis.

Scripting + synchronous blocking operations = Issue #614.

Basically you can't "rewrite" a script to have just a partial effect on
the replicas and AOF file if the script happened to serve a few blocked

The solution to all this problems, implemented by this commit, is to
change the way we serve blocked clients. Instead of serving the blocked
clients synchronously, in the context of the command performing the PUSH
operation, it is now an asynchronous and iterative process:

1) If a key that has clients blocked waiting for data is the subject of
a list push operation, We simply mark keys as "ready" and put it into a
2) Every command pushing stuff on lists, as a variadic LPUSH, a script,
or whatever it is, is replicated verbatim without any rewriting.
3) Every time a Redis command, a MULTI/EXEC block, or a script,
completed its execution, we run the list of keys ready to serve blocked
clients (as more data arrived), and process this list serving the
blocked clients.
4) As a result of "3" maybe more keys are ready again for other clients
(as a result of BRPOPLPUSH we may have push operations), so we iterate
back to step "3" if it's needed.

The new code has a much simpler semantics, and a simpler to understand
implementation, with the disadvantage of not being able to "optmize out"
a PUSH+BPOP as a No OP.

This commit will be tested with care before the final merge, more tests
will be added likely.
@antirez .gitignore modified to be more general with less entries. 174518f
@antirez Redis 2.5.13 (2.6.0 RC7). 4403862
@antirez Fix compilation on FreeBSD. Thanks to @koobs on twitter. 8b6b1b2
@antirez Added the SRANDMEMBER key <count> variant.
SRANDMEMBER called with just the key argument can just return a single
random element from a Redis Set. However many users need to return
multiple unique elements from a Set, this is not a trivial problem to
handle in the client side, and for truly good performance a C
implementation was required.

After many requests for this feature it was finally implemented.

The problem implementing this command is the strategy to follow when
the number of elements the user asks for is near to the number of
elements that are already inside the set. In this case asking random
elements to the dictionary API, and trying to add it to a temporary set,
may result into an extremely poor performance, as most add operations
will be wasted on duplicated elements.

For this reason this implementation uses a different strategy in this
case: the Set is copied, and random elements are returned to reach the
specified count.

The code actually uses 4 different algorithms optimized for the
different cases.

If the count is negative, the command changes behavior and allows for
duplicated elements in the returned subset.
@antirez SRANDMEMBER <count> leak fixed.
For "CASE 4" (see code) we need to free the element if it's already in
the result dictionary and adding it failed.
@antirez Test for SRANDMEMBER with <count>. 2812b94
@antirez First implementation of Redis Sentinel.
This commit implements the first, beta quality implementation of Redis
Sentinel, a distributed monitoring system for Redis with notification
and automatic failover capabilities.

More info at
@antirez Typo. 5b5eb19
@antirez Fixed an error in the example sentinel.conf. d26a8fb
@antirez Sentinel: more robust failover detection as observer.
Sentinel observers detect failover checking if a slave attached to the
monitored master turns into its replication state from slave to master.
However while this change may in theory only happen after a SLAVEOF NO
ONE command, in practie it is very easy to reboot a slave instance with
a wrong configuration that turns it into a master, especially if it was
a past master before a successfull failover.

This commit changes the detection policy so that if an instance goes
from slave to master, but at the same time the runid has changed, we
sense a reboot, and in that case we don't detect a failover at all.

This commit also introduces the "reboot" sentinel event, that is logged
at "warning" level (so this will trigger an admin notification).

The commit also fixes a problem in the disconnect handler that assumed
that the instance object always existed, that is not the case. Now we
no longer assume that redisAsyncFree() will call the disconnection
handler before returning.
@antirez Sentinel: check that instance still exists in reply callbacks.
We can't be sure the instance object still exists when the reply
callback is called.
@antirez Sentinel: changes to connection handling and redirection.
We disconnect the Redis instances hiredis link in a more robust way now.
Also we change the way we perform the redirection for the +switch-master
event, that is not just an instance reset with an address change.

Using the same system we now implement the +redirect-to-master event
that is triggered by an instance that is configured to be master but
found to be a slave at the first INFO reply. In that case we monitor the
master instead, logging the incident as an event.
@antirez Sentinel: debugging message removed. 7c39b55
@antirez Prevent a spurious +sdown event on switch.
When we reset the master we should start with clean timestamps for ping
replies otherwise we'll detect a spurious +sdown event, because on
+master-switch event the previous master instance was probably in +sdown
condition. Since we updated the address we should count time from
scratch again.

Also this commit makes sure to explicitly reset the count of pending
commands, now we can do this because of the new way the hiredis link
is closed.
@antirez Sentinel: reset pending_commands in a more generic way. 2085fdb
@antirez Sentinel: abort failover if no good slave is available.
The previous behavior of the state machine was to wait some time and
retry the slave selection, but this is not robust enough against drastic
changes in the conditions of the monitored instances.

What we do now when the slave selection fails is to abort the failover
and return back monitoring the master. If the ODOWN condition is still
present a new failover will be triggered and so forth.

This commit also refactors the code we use to abort a failover.
@mrb mrb Some cleanup in sentinel.conf fcc8bf9
@mrb mrb Fix warning in redis.c for sentinel config load f105753
@antirez Sentinel: ability to execute notification scripts. 999fe0d
@jzawodn jzawodn comment fix
improve English a bit. :-)
@antirez Sentinel: don't start a failover as leader if there is no good slave. 0d0975f
@badboy badboy Include sys/wait.h to avoid compiler warning
gcc warned about an implicit declaration of function 'wait3'.
Including this header fixes this.
@antirez Sentinel: scripts execution engine improved.
We no longer use a vanilla fork+execve but take a queue of jobs of
scripts to execute, with retry on error, timeouts, and so forth.

Currently this is used only for notifications but soon the ability to
also call clients reconfiguration scripts will be added.
@antirez Sentinel: abort failover when in wait-start if master is back.
When we are a Leader Sentinel in wait-start state, starting with this
commit the failover is aborted if the master returns online.

This improves the way we handle a notable case of net split, that is the
split between Sentinels and Redis servers, that will be a very common
case of split becase Sentinels will often be installed in the client's
network and servers can be in a differnt arm of the network.

When Sentinels and Redis servers are isolated the master is in ODOWN
condition since the Sentinels can agree about this state, however the
failover does not start since there are no good slaves to promote (in
this specific case all the slaves are unreachable).

However when the split is resolved, Sentinels may sense the slave back
a moment before they sense the master is back, so the failover may start
without a good reason (since the master is actually working too).

Now this condition is reversible, so the failover will be aborted
immediately after if the master is detected to be working again, that
is, not in SDOWN nor in ODOWN condition.
@antirez Sentinel: sentinel.conf self-documenation improved. 7c9bfe1
@antirez Sentinel: sentinelRefreshInstanceInfo() comments improved a bit. 201ed6d
@antirez Sentinel: when leader in wait-start, sense another leader as race.
When we are in wait start, if another leader (or any other external
entity) turns a slave into a master, abort the failover, and detect it
as an observer.

Note that the wait-start state is mainly there for this reason but the
abort was yet not implemented.

This adds a new sentinel event -failover-abort-race.
@antirez Sentinel: client reconfiguration script execution.
This commit adds support to optionally execute a script when one of the
following events happen:

* The failover starts (with a slave already promoted).
* The failover ends.
* The failover is aborted.

The script is called with enough parameters (documented in the example
sentinel.conf file) to provide information about the old and new ip:port
pair of the master, the role of the sentinel (leader or observer) and
the name of the master.

The goal of the script is to inform clients of the configuration change
in a way specific to the environment Sentinel is running, that can't be
implemented in a genereal way inside Sentinel itself.
@antirez Sentinel: SENTINEL FAILOVER command implemented.
This command can be used in order to force a Sentinel instance to start
a failover for the specified master, as leader, forcing the failover
even if the master is up.

The commit also adds some minor refactoring and other improvements to
functions already implemented that make them able to work when the
master is not in SDOWN condition. For instance slave selection
assumed that we ask INFO every second to every slave, this is true
only when the master is in SDOWN condition, so slave selection did not
worked when the master was not in SDOWN condition.
@antirez Sentinel: fixed a crash on script execution.
The call to sentinelScheduleScriptExecution() lacked the final NULL
argument to signal the end of arguments. This resulted into a crash.
@antirez Sentinel: send SCRIPT KILL on -BUSY reply and SDOWN instance.
From the point of view of Redis an instance replying -BUSY is down,
since it is effectively not able to reply to user requests. However
a looping script is a recoverable condition in Redis if the script still
did not performed any write to the dataset. In that case performing a
fail over is not optimal, so Sentinel now tries to restore the normal server
condition killing the script with a SCRIPT KILL command.

If the script already performed some write before entering an infinite
(or long enough to timeout) loop, SCRIPT KILL will not work and the
fail over will be triggered anyway.
@antirez Sentinel: suppress harmless warning by initializing 'table' to NULL.
Note that the assertion guarantees that one of the if branches setting
table is always entered.
@antirez Sentinel: Sentinel-side support for slave priority.
The slave priority that is now published by Redis in INFO output is
now used by Sentinel in order to select the slave with minimum priority
for promotion, and in order to consider slaves with priority set to 0 as
not able to play the role of master (they will never be promoted by

The "slave-priority" field is now one of the fileds that Sentinel
publishes when describing an instance via the SENTINEL commands such as
"SENTINEL slaves mastername".
@antirez Sentinel: add Redis execution mode to INFO output.
The new "redis_mode" field in the INFO output will show if Redis is
running in standalone mode, cluster, or sentinel mode.
@antirez Sentinel: INFO command implementation. de499f7
@antirez Sentinel: do not crash against slaves not publishing the runid.
Older versions of Redis (before 2.4.17) don't publish the runid field in
INFO. This commit makes Sentinel able to handle that without crashing.
@antirez Sentinel: more easy master redirection if master is a slave.
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.
@antirez Sentinel: reply -IDONTKNOW to get-master-addr-by-name on lack of info.
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 Sentinel: Support for AUTH. dfb7194
@antirez Final merge of Sentinel into 2.6.
After cherry-picking Sentinel commits a few spurious issues remained
about references to Redis Cluster that is not present in the 2.6 branch.
@erikdubbelboer erikdubbelboer Added consts keyword where possible e04be06
@erikdubbelboer erikdubbelboer Fixed some spelling errors in the comments 04779bd
@antirez Scripting: redis.NIL to return nil bulk replies.
Lua arrays can't contain nil elements (see for more information), so Lua scripts
were not able to return a multi-bulk reply containing nil bulk
elements inside.

This commit introduces a special conversion: a table with just
a "nilbulk" field set to a boolean value is converted by Redis as a nil
bulk reply, but at the same time for Lua this type is not a "nil" so can
be used inside Lua arrays.

This type is also assigned to redis.NIL, so the following two forms
are equivalent and will be able to return a nil bulk reply as second
element of a three elements array:

    EVAL "return {1,redis.NIL,3}" 0
    EVAL "return {1,{nilbulk=true},3}" 0

The result in redis-cli will be:

    1) (integer) 1
    2) (nil)
    3) (integer) 3
@antirez Scripting: add helper functions redis.error_reply() and redis.status_…

A previous commit introduced Redis.NIL. This commit adds similar helper
functions to return tables with a single field set to the specified
string so that instead of using 'return {err="My Error"}' it is possible
to use a more idiomatic form:

    return redis.error_reply("My Error")
    return redis.status_reply("OK")

Please do not reference PiL I — it is about Lua 5.0, not 5.1. It is not a very good idea to encourage people to read it (unless they are to work with 5.0, which is not the case here), even if a given chapter is left intact in PiL II — it often leads to much confusion later on. A reference to a corresponding chapter in PiL II would be much better.


Hi @agladysh thanks for the hint, I was not aware at all about PiL I vs II, I'll take care the next time.

Please note the message at the top of each page of online PiL I.


So PiL II is not available in the web site as normal documentation? I guess I need to find a different resource then ;)

No, it is a commercial book (as PiL I was previously). I highly recommend you to buy and read it — I'd say it is one of best CS books ever. (But note that it is not very different from PiL I from that point of view.)

As for the references of the kind you use here, just quote the manual — it does contain this information.


I don't question the validity of the book and I'll be happy to purchase it and read it, thanks for the advice. However I don't want to link to resources that are not freely available on the web in commit comments, as everybody should be able to access it. Next time I'll put a note that what I'm writing is applicable to Lua 5.0 and with 5.1 things may be different.

Next time I'll put a note that what I'm writing is applicable to Lua 5.0 and with 5.1 things may be different.

IMHO such notice will be confusing. (Redis does not have anything to do with 5.0, and 5.0 is ages old.) I'd use the manual instead.

But it is not that big deal anyway.


It should be faster to store a reference to redis.NIL somewhere (e.g. in upvalue, in function environment or in registry) at the initialization time and simply compare table references here. (I.e. redis.NIL is considered to be a special unique token object.)

This is how (IMO) it is usually done, but the way you did here is OK as well. Note that the semantics is slightly different though — although not for "documented" use case.

(But see below.)


Erm. So, nilbulk becomes a reserved name, and I can't serialize a table if it contains that field? Not very clean IMO.


In Lua -> Redis conversion the only arrays that are valid to serialize are those with integer keys, not general Lua tables, so we are using only special-cases that are not serializable (that is, tables with non-numerical keys). Therefore there is no reserved word.

  1. I would put a comment about this in sources.

  2. Are you sure this will not change in future?

and others added some commits Oct 1, 2012
@antirez Revert "Scripting: redis.NIL to return nil bulk replies."
This reverts commit e061d79.


@antirez "SORT by nosort" (skip sorting) respect sorted set ordering.
When SORT is called with the option BY set to a string constant not
inclduing the wildcard character "*", there is no way to sort the output
so any ordering is valid. This allows the SORT internals to optimize its
work and don't really sort the output at all.

However it was odd that this option was not able to retain the natural
order of a sorted set. This feature was requested by users multiple
times as sometimes to call SORT with GET against sorted sets as a way to
mass-fetch objects can be handy.

This commit introduces two things:

1) The ability of SORT to return sorted sets elements in their natural
ordering when `BY nosort` is specified, accordingly to `DESC / ASC` options.
2) The ability of SORT to optimize this case further if LIMIT is passed
as well, avoiding to really fetch the whole sorted set, but directly
obtaining the specified range.

Because in this case the sorting is always deterministic, no
post-sorting activity is performed when SORT is called from a Lua

This commit fixes issue #98.
@antirez "Timeout receiving bulk data" error message modified.
The new message now contains an hint about modifying the repl-timeout
configuration directive if the problem persists.

This should normally not be needed, because while the master generates
the RDB file it makes sure to send newlines to the replication channel
to prevent timeouts. However there are times when masters running on
very slow systems can completely stop for seconds during the RDB saving
process. In such a case enlarging the timeout value can fix the problem.

See issue #695 for an example of this problem in an EC2 deployment.
@jokea jokea Force expire all timer events when system clock skew is detected.
When system time changes back, the timer will not worker properly
hence some core functionality of redis will stop working(e.g. replication,
bgsave, etc). See issue #633 for details.

The patch saves the previous time and when a system clock skew is detected,
it will force expire all timers.

Modiifed by @antirez: the previous time was moved into the eventLoop
structure to make sure the library is still thread safe as long as you
use different event loops into different threads (otherwise you need
some synchronization). More comments added about the reasoning at the
base of the patch, that's worth reporting here:

/* If the system clock is moved to the future, and then set back to the
 * right value, time events may be delayed in a random way. Often this
 * means that scheduled operations will not be performed soon enough.
 * Here we try to detect system clock skews, and force all the time
 * events to be processed ASAP when this happens: the idea is that
 * processing events earlier is less dangerous than delaying them
 * indefinitely, and practice suggests it is. */
@antirez Include time.h in ae.c as we now use time(). e2f2dab
@antirez Warn when configured maxmemory value seems odd.
This commit warns the user with a log at "warning" level if:

1) After the server startup the maxmemory limit was found to be < 1MB.
2) After a CONFIG SET command modifying the maxmemory setting the limit
is set to a value that is smaller than the currently used memory.

The behaviour of the Redis server is unmodified, and this wil not make
the CONFIG SET command or a wrong configuration in redis.conf less
likely to create problems, but at least this will make aware most users
about a possbile error they committed without resorting to external

However no warning is issued if, as a result of loading the AOF or RDB
file, we are very near the maxmemory setting, or key eviction will be
needed in order to go under the specified maxmemory setting. The reason
is that in servers configured as a cache with an aggressive
maxmemory-policy most of the times restarting the server will cause this
condition to happen if persistence is not switched off.

This fixes issue #429.
@antirez Hash function switched to murmurhash2.
The previously used hash function, djbhash, is not secure against
collision attacks even when the seed is randomized as there are simple
ways to find seed-independent collisions.

The new hash function appears to be safe (or much harder to exploit at
least) in this case, and has better distribution.

Better distribution does not always means that's better. For instance in
a fast benchmark with "DEBUG POPULATE 1000000" I obtained the following

    1.6 seconds with djbhash
    2.0 seconds with murmurhash2

This is due to the fact that djbhash will hash objects that follow the
pattern `prefix:<id>` and where the id is numerically near, to near
buckets. This improves the locality.

However in other access patterns with keys that have no relation
murmurhash2 has some (apparently minimal) speed advantage.

On the other hand a better distribution should significantly
improve the quality of the distribution of elements returned with
dictGetRandomKey() that is used in SPOP, SRANDMEMBER, RANDOMKEY, and
other commands.

Everything considered, and under the suspect that this commit fixes a
security issue in Redis, we are switching to the new hash function.
If some serious speed regression will be found in the future we'll be able
to step back easiliy.

This commit fixes issue #663.
@antirez Merge pull request #544 from dvirsky/2.6
fixed install script to rewrite the default config
@antirez Redis 2.6.0 RC8 (2.5.14) 500dddc
@antirez CONTRIBUTING file updated. f4eb4b3
@antirez Allow AUTH when Redis is busy because of timedout Lua script.
If the server is password protected we need to accept AUTH when there is
a server busy (-BUSY) condition, otherwise it will be impossible to send

This fixes issue #708.
@antirez Merge remote-tracking branch 'origin/2.6' into 2.6 c3ff470
@antirez Fix MULTI / EXEC rendering in MONITOR output.
Before of this commit it used to be like this:

... actual commands of the transaction ...

Because after all that is the natural order of things. Transaction
commands are queued and executed *only after* EXEC is called.

However this makes debugging with MONITOR a mess, so the code was
modified to provide a coherent output.

What happens is that MULTI is rendered in the MONITOR output as far as
possible, instead EXEC is propagated only after the transaction is
executed, or even in the case it fails because of WATCH, so in this case
you'll simply see:


An empty transaction.


otherwise looks like a sane fix.

NanXiao and others added some commits Oct 10, 2012
@NanXiao NanXiao Update src/redis-benchmark.c
The code of current implementation:

if (c->pending == 0) clientDone(c);
In clientDone function, the c's memory has been freed, then the loop will continue: while(c->pending). The memory of c has been freed now, so c->pending is invalid (c is an invalid pointer now), and this will cause memory dump in some platforams(eg: Solaris).

So I think the code should be modified as:
if (c->pending == 0)
and this will not lead to while(c->pending).
@antirez Differentiate SCRIPT KILL error replies.
When calling SCRIPT KILL currently you can get two errors:

* No script in timeout (busy) state.
* The script already performed a write.

It is useful to be able to distinguish the two errors, but right now both
start with "ERR" prefix, so string matching (that is fragile) must be used.

This commit introduces two different prefixes.

-NOTBUSY and -UNKILLABLE respectively to reply with an error when no
script is busy at the moment, and when the script already executed a
write operation and can not be killed.
@antirez Default memory limit for 32bit instanced moved from 3.5 GB to 3 GB.
In some system, notably osx, the 3.5 GB limit was too far and not able
to prevent a crash for out of memory. The 3 GB limit works better and it
is still a lot of memory within a 4 GB theorical limit so it's not going
to bore anyone :-)

This fixes issue #711
@ripcurld00d ripcurld00d redis-check-dump now understands dumps produced by Redis 2.6
(Commit message from @antirez as it was missign in the original commits,
also the patch was modified a bit to still work with 2.4 dumps and to
avoid if expressions that are always true due to checked types range)

This commit changes redis-check-dump to account for new encodings and
for the new MSTIME expire format. It also refactors the test for valid
type into a function.

The code is still compatible with Redis 2.4 generated dumps.

This fixes issue #709.
Greg Hurrell Fix (cosmetic) typos in dict.h a61705d
@antirez A filed called slave_read_only added in INFO output.
This was an important information missing from the INFO output in the
replication section.

It obviously reflects if the slave is read only or not.
@antirez Redis 2.6.0 5eec376
@antirez Update memory peak stats while loading RDB / AOF. 1eb9145
@antirez Fix compilation on Linux kernels or glibc versions lacking sync_file_…

This fixes issue #667.

Many thanks to Didier Spezia for the fix.
@antirez Redis 2.6.1 2b5fc52
@openbaas openbaas patch config.h for sync_file_range b25b0dc
@antirez Marginally more robust glibc version test for sync_file_range detection. 9b3b110
@antirez Ctrl+w support in linenoise. 3b1a41b
@antirez Redis 2.6.2 0dd6241
@ambakshi ambakshi Fix on RHEL/CentOS machines
The expression to check for chkconfig was wrong
as was the 'echo -e'. Use cat to create temp file
instead and fix the if expr.
@mattsta mattsta closed this Aug 1, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment