1. 23 Jun, 2014 3 commits
  2. 21 Jun, 2014 2 commits
  3. 20 Jun, 2014 3 commits
  4. 19 Jun, 2014 5 commits
    • antirez's avatar
      f62dfa0f
    • antirez's avatar
    • antirez's avatar
      Sentinel: send hello messages ASAP after config change. · 41f12ac9
      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.
      41f12ac9
    • antirez's avatar
      Sentinel test: add manual failover test. · f16ad11c
      antirez authored
      f16ad11c
    • antirez's avatar
      Sentinel: handle SRI_PROMOTED flag correctly. · 94bc4673
      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.
      94bc4673
  5. 18 Jun, 2014 8 commits
  6. 17 Jun, 2014 3 commits
  7. 16 Jun, 2014 5 commits
    • antirez's avatar
      CLIENT KILL API modified. · bb2011d9
      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.
      bb2011d9
    • antirez's avatar
      e06b3819
    • antirez's avatar
      New features for CLIENT KILL. · e7affd26
      antirez authored
      e7affd26
    • antirez's avatar
      Assign an unique non-repeating ID to each new client. · f26f79ea
      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.
      f26f79ea
    • antirez's avatar
      Client types generalized. · 56d26c23
      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.
      56d26c23
  8. 12 Jun, 2014 2 commits
    • antirez's avatar
      Scripting: regression test for issue #1811. · aa19fd61
      antirez authored
      aa19fd61
    • antirez's avatar
      Fix semantics of Lua calls to SELECT. · 96e0fe62
      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.
      96e0fe62
  9. 11 Jun, 2014 4 commits
  10. 10 Jun, 2014 5 commits