1. 05 Feb, 2014 3 commits
  2. 04 Feb, 2014 1 commit
    • antirez's avatar
      CLIENT PAUSE and related API implemented. · 4919a13f
      antirez authored
      The API is one of the bulding blocks of CLUSTER FAILOVER command that
      executes a manual failover in Redis Cluster. However exposed as a
      command that the user can call directly, it makes much simpler to
      upgrade a standalone Redis instance using a slave in a safer way.
      
      The commands works like that:
      
          CLIENT PAUSE <milliesconds>
      
      All the clients that are not slaves and not in MONITOR state are paused
      for the specified number of milliesconds. This means that slaves are
      normally served in the meantime.
      
      At the end of the specified amount of time all the clients are unblocked
      and will continue operations normally. This command has no effects on
      the population of the slow log, since clients are not blocked in the
      middle of operations but only when there is to process new data.
      
      Note that while the clients are unblocked, still new commands are
      accepted and queued in the client buffer, so clients will likely not
      block while writing to the server while the pause is active.
      4919a13f
  3. 03 Feb, 2014 3 commits
    • antirez's avatar
      Scripting: expire keys in scripts only at first access. · b089ba98
      antirez authored
      Keys expiring in the middle of the execution of Lua scripts are to
      create inconsistencies in masters and / or AOF files. See the following
      example:
      
          if redis.call("exists",KEYS[1]) == 1
          then
              redis.call("incr","mycounter")
          end
      
          if redis.call("exists",KEYS[1]) == 1
          then
              return redis.call("incr","mycounter")
          end
      
      The script executes two times the same *if key exists then incrementcounter*
      logic. However the two executions will work differently in the master and
      the slaves, provided some unlucky timing happens.
      
      In the master the first time the key may still exist, while the second time
      the key may no longer exist. This will result in the key incremented just one
      time. However as a side effect the master will generate a synthetic
      `DEL` command in the replication channel in order to force the slaves to
      expire the key (given that key expiration is master-driven).
      
      When the same script will run in the slave, the key will no longer be
      there, so the script will not increment the key.
      
      The key idea used to implement the expire-at-first-lookup semantics was
      provided by Marc Gravell.
      b089ba98
    • antirez's avatar
      b770079f
    • antirez's avatar
      Scripting: use mstime() and mstime_t for lua_time_start. · 89884e8f
      antirez authored
      server.lua_time_start is expressed in milliseconds. Use mstime_t instead
      of long long, and populate it with mstime() instead of ustime()/1000.
      
      Functionally identical but more natural.
      89884e8f
  4. 31 Jan, 2014 4 commits
  5. 30 Jan, 2014 3 commits
  6. 29 Jan, 2014 10 commits
  7. 28 Jan, 2014 4 commits
  8. 25 Jan, 2014 1 commit
  9. 24 Jan, 2014 1 commit
  10. 22 Jan, 2014 6 commits
  11. 20 Jan, 2014 4 commits
    • antirez's avatar
      Cluster: master nodes wait before rejoining the cluster after reboot. · 80e80668
      antirez authored
      One of the simple heuristics used by Redis Cluster in order to avoid
      losing data in the typical failure modes created by the asynchronous
      replication with the slaves (a master is unable, when accepting a
      write, to immediately tell if it should be really accepted or refused
      because of a configuration change), is to wait some time before to
      rejoin the cluster after being partitioned away from the majority of
      instances.
      
      A similar condition happens when a master is restarted. It does not know
      if it was already failed over, nor if all the clients have already an
      updated configuration about the cluster map, so it is possible that
      clients will try to write to stale masters that were restarted.
      
      In a similar way this commit changes masters behavior so they wait
      2000 milliseconds before accepting writes after a reboot. There is
      nothing special about 2 seconds if not to be a value supposedly larger
      a few orders of magnitude compared to the cluster bus communication
      latencies.
      80e80668
    • antirez's avatar
      Cluster: debug printf statemets removed. · e6970e20
      antirez authored
      These were committed for error after being inserted in order to fix an
      issue.
      e6970e20
    • antirez's avatar
    • antirez's avatar
      437fc2cb