- 20 Jun, 2014 1 commit
-
-
antirez authored
-
- 19 Jun, 2014 2 commits
-
-
antirez authored
Eventual configuration convergence is guaranteed by our periodic hello messages to all the instances, however when there are important notices to share, better make a phone call. With this commit we force an hello message to other Sentinal and Redis instances within the next 100 milliseconds of a config update, which is practically better than waiting a few seconds.
-
antirez authored
Lack of check of the SRI_PROMOTED flag caused Sentienl to act with the promoted slave turned into a master during failover like if it was a normal instance. Normally this problem was not apparent because during real failovers the old master is down so the bugged code path was not entered, however with manual failovers via the SENTINEL FAILOVER command, the problem was easily triggered. This commit prevents promoted slaves from getting reconfigured, moreover we now explicitly check that during a failover the slave turning into a master is the one we selected for promotion and not a different one.
-
- 18 Jun, 2014 1 commit
-
-
Alex Suraci authored
-
- 17 Jun, 2014 2 commits
-
-
Matt Stancliff authored
If we run a long latency session and want to Ctrl-C out of it, it's nice to still get the summary output at the end.
-
antirez authored
This implements the new Sentinel-Client protocol for the Sentinel part: now instances are reconfigured using a transaction that ensures that the config is rewritten in the target instance, and that clients lose the connection with the instance, in order to be forced to: ask Sentinel, reconnect to the instance, and verify the instance role with the new ROLE command.
-
- 16 Jun, 2014 5 commits
-
-
antirez authored
Added a new SKIPME option that is true by default, that prevents the client sending the command to be killed, unless SKIPME NO is sent.
-
antirez authored
-
antirez authored
-
antirez authored
This will be used by CLIENT KILL and is also a good way to ensure a given client is still the same across CLIENT LIST calls. The output of CLIENT LIST was modified to include the new ID, but this change is considered to be backward compatible as the API does not imply you can do positional parsing, since each filed as a different name.
-
antirez authored
Because of output buffer limits Redis internals had this idea of type of clients: normal, pubsub, slave. It is possible to set different output buffer limits for the three kinds of clients. However all the macros and API were named after output buffer limit classes, while the idea of a client type is a generic one that can be reused. This commit does two things: 1) Rename the API and defines with more general names. 2) Change the class of clients executing the MONITOR command from "slave" to "normal". "2" is a good idea because you want to have very special settings for slaves, that are not a good idea for MONITOR clients that are instead normal clients even if they are conceptually slave-alike (since it is a push protocol). The backward-compatibility breakage resulting from "2" is considered to be minimal to care, since MONITOR is a debugging command, and because anyway this change is not going to break the format or the behavior, but just when a connection is closed on big output buffer issues.
-
- 12 Jun, 2014 1 commit
-
-
antirez authored
Lua scripts are executed in the context of the currently selected database (as selected by the caller of the script). However Lua scripts are also free to use the SELECT command in order to affect other DBs. When SELECT is called frm Lua, the old behavior, before this commit, was to automatically set the Lua caller selected DB to the last DB selected by Lua. See for example the following sequence of commands: SELECT 0 SET x 10 EVAL "redis.call('select','1')" 0 SET x 20 Before this commit after the execution of this sequence of commands, we'll have x=10 in DB 0, and x=20 in DB 1. Because of the problem above, there was a bug affecting replication of Lua scripts, because of the actual implementation of replication. It was possible to fix the implementation of Lua scripts in order to fix the issue, but looking closely, the bug is the consequence of the behavior of Lua ability to set the caller's DB. Under the old semantics, a script selecting a different DB, has no simple ways to restore the state and select back the previously selected DB. Moreover the script auhtor must remember that the restore is needed, otherwise the new commands executed by the caller, will be executed in the context of a different DB. So this commit fixes both the replication issue, and this hard-to-use semantics, by removing the ability of Lua, after the script execution, to force the caller to switch to the DB selected by the Lua script. The new behavior of the previous sequence of commadns is to just set X=20 in DB 0. However Lua scripts are still capable of writing / reading from different DBs if needed. WARNING: This is a semantical change that will break programs that are conceived to select the client selected DB via Lua scripts. This fixes issue #1811.
-
- 11 Jun, 2014 1 commit
-
-
antirez authored
It is more straightforward to just test for a numerical type avoiding Lua's automatic conversion. The code is technically more correct now, however Lua should automatically convert to number only if the original type is a string that "looks like a number", and not from other types, so practically speaking the fix is identical AFAIK.
-
- 10 Jun, 2014 7 commits
-
-
Matt Stancliff authored
The new check-for-number behavior of Lua arguments broke users who use large strings of just integers. The Lua number check would convert the string to a number, but that breaks user data because Lua numbers have limited precision compared to an arbitrarily precise number wrapped in a string. Regression fixed and new test added. Fixes #1118 again.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
- 07 Jun, 2014 4 commits
-
-
antirez authored
Info about the replication state with the master added.
-
antirez authored
The new ROLE command is designed in order to provide a client with informations about the replication in a fast and easy to use way compared to the INFO command where the same information is also available.
-
antirez authored
Since there are ways to alter the configEpoch outside of the failover procedure (for exampel CLUSTER SET-CONFIG-EPOCH and via the configEpoch collision resolution algorithm), make always sure, before replacing our configEpoch with a new one, that it is greater than the current one.
-
antirez authored
SET-CONFIG-EPOCH, used by redis-trib at cluster creation time, failed to update the currentEpoch, making it possible after a failover for a server to set its configEpoch to a value smaller than the current one (since configEpochs are obtained using currentEpoch). The bug totally break the Redis Cluster algorithms and protocols allowing for permanent split brain conditions about the slots configuration as shown in issue #1799.
-
- 05 Jun, 2014 1 commit
-
-
antirez authored
Replication is totally broken when a slave has this option, since it stops accepting updates from masters. This fixes issue #1434.
-
- 04 Jun, 2014 2 commits
-
-
antirez authored
I'm not sure if while the visibility is the inner block, the fact we point to 'dbuf' is a problem or not, probably the stack var isx guaranteed to live until the function returns. However obvious code is better anyway.
-
antirez authored
The lua_to*string() family of functions use a non optimal format specifier when converting integers to strings. This has both the problem of the number being converted in exponential notation, which we don't use as a Redis return value when floating point numbers are involed, and, moreover, there is a loss of precision since the default format specifier is not able to represent numbers that must be represented exactly in the IEEE 754 number mantissa. The new code handles it as a special case using a saner conversion. This fixes issue #1118.
-
- 31 May, 2014 1 commit
-
-
zionwu authored
-
- 28 May, 2014 2 commits
-
-
antirez authored
-
Jan-Erik Rediger authored
-
- 26 May, 2014 2 commits
-
-
Matt Stancliff authored
If we are in the signal handler, we don't want to handle the signal again. In extreme cases, this can cause a stack overflow and segfault Redis. Fixes #1771
-
antirez authored
There is a time defined by REDIS_CLUSTER_WRITABLE_DELAY where fail -> ok switch is not possible after startup as a master for some time, however the contrary (ok -> fail) should always be possible.
-
- 22 May, 2014 4 commits
-
-
Andy Grunwald authored
-
antirez authored
-
antirez authored
Every log contains, just after the pid, a single character that provides information about the role of an instance: S - Slave M - Master C - Writing child X - Sentinel
-
antirez authored
Check the commit changes in the example redis.conf for more information.
-
- 21 May, 2014 4 commits
-
-
antirez authored
While iterating the list of nodes we want to set the slot as stable in the current node, not always in the first node of the list.
-
antirez authored
-
Matt Stancliff authored
Behrad Zari discovered [1] and Josiah reported [2]: if you block and wait for a list to exist, but the list creates from a non-push command, the blocked client never gets notified. This commit adds notification of blocked clients into the DB layer and away from individual commands. Lists can be created by [LR]PUSH, SORT..STORE, RENAME, MOVE, and RESTORE. Previously, blocked client notifications were only triggered by [LR]PUSH. Your client would never get notified if a list were created by SORT..STORE or RENAME or a RESTORE, etc. Blocked client notification now happens in one unified place: - dbAdd() triggers notification when adding a list to the DB Two new tests are added that fail prior to this commit. All test pass. Fixes #1668 [1]: https://groups.google.com/forum/#!topic/redis-db/k4oWfMkN1NU [2]: #1668
-
antirez authored
This fixes issue #1765.
-