1. 31 Jan, 2014 3 commits
  2. 28 Jan, 2014 1 commit
  3. 14 Jan, 2014 1 commit
    • antirez's avatar
      Cluster: support to read from slave nodes. · 28273394
      antirez authored
      A client can enter a special cluster read-only mode using the READONLY
      command: if the client read from a slave instance after this command,
      for slots that are actually served by the instance's master, the queries
      will be processed without redirection, allowing clients to read from
      slaves (but without any kind fo read-after-write guarantee).
      
      The READWRITE command can be used in order to exit the readonly state.
      28273394
  4. 23 Dec, 2013 1 commit
  5. 19 Dec, 2013 1 commit
  6. 11 Dec, 2013 1 commit
    • antirez's avatar
      Replication: publish the slave_repl_offset when disconnected from master. · a5ec247f
      antirez authored
      When a slave was disconnected from its master the replication offset was
      reported as -1. Now it is reported as the replication offset of the
      previous master, so that failover can be performed using this value in
      order to try to select a slave with more processed data from a set of
      slaves of the old master.
      a5ec247f
  7. 05 Dec, 2013 2 commits
  8. 04 Dec, 2013 1 commit
  9. 03 Dec, 2013 1 commit
  10. 29 Nov, 2013 1 commit
  11. 28 Nov, 2013 2 commits
  12. 21 Nov, 2013 1 commit
  13. 19 Nov, 2013 1 commit
    • antirez's avatar
      Sentinel: distinguish between is-master-down-by-addr requests. · 37a51a25
      antirez authored
      Some are just to know if the master is down, and in this case the runid
      in the request is set to "*", others are actually in order to seek for a
      vote and get elected. In the latter case the runid is set to the runid
      of the instance seeking for the vote.
      37a51a25
  14. 28 Oct, 2013 4 commits
  15. 25 Oct, 2013 2 commits
  16. 09 Oct, 2013 2 commits
  17. 26 Sep, 2013 1 commit
  18. 17 Sep, 2013 1 commit
  19. 27 Aug, 2013 1 commit
  20. 22 Aug, 2013 2 commits
  21. 21 Aug, 2013 1 commit
  22. 06 Aug, 2013 4 commits
    • antirez's avatar
      Add per-db average TTL information in INFO output. · 112fa479
      antirez authored
      Example:
      
      db0:keys=221913,expires=221913,avg_ttl=655
      
      The algorithm uses a running average with only two samples (current and
      previous). Keys found to be expired are considered at TTL zero even if
      the actual TTL can be negative.
      
      The TTL is reported in milliseconds.
      112fa479
    • antirez's avatar
      activeExpireCycle(): fix about fast cycle early start. · 4befe73b
      antirez authored
      We don't want to repeat a fast cycle too soon, the previous code was
      broken, we need to wait two times the period *since* the start of the
      previous cycle in order to avoid there is an even space between cycles:
      
      .-> start                   .-> second start
      |                           |
      +-------------+-------------+--------------+
      | first cycle |    pause    | second cycle |
      +-------------+-------------+--------------+
      
      The second and first start must be PERIOD*2 useconds apart hence the *2
      in the new code.
      4befe73b
    • antirez's avatar
      Some activeExpireCycle() refactoring. · 6500fabf
      antirez authored
      6500fabf
    • antirez's avatar
      d398f388
  23. 05 Aug, 2013 2 commits
    • antirez's avatar
      Darft #2 for key collection algo: more improvements. · 66a26471
      antirez authored
      This commit makes the fast collection cycle time configurable, at
      the same time it does not allow to run a new fast collection cycle
      for the same amount of time as the max duration of the fast
      collection cycle.
      66a26471
    • antirez's avatar
      Draft #1 of a new expired keys collection algorithm. · b09ea1bd
      antirez authored
      The main idea here is that when we are no longer to expire keys at the
      rate the are created, we can't block more in the normal expire cycle as
      this would result in too big latency spikes.
      
      For this reason the commit introduces a "fast" expire cycle that does
      not run for more than 1 millisecond but is called in the beforeSleep()
      hook of the event loop, so much more often, and with a frequency bound
      to the frequency of executed commnads.
      
      The fast expire cycle is only called when the standard expiration
      algorithm runs out of time, that is, consumed more than
      REDIS_EXPIRELOOKUPS_TIME_PERC of CPU in a given cycle without being able
      to take the number of already expired keys that are yet not collected
      to a number smaller than 25% of the number of keys.
      
      You can test this commit with different loads, but a simple way is to
      use the following:
      
      Extreme load with pipelining:
      
      redis-benchmark -r 100000000 -n 100000000  \
              -P 32 set ele:rand:000000000000 foo ex 2
      
      Remove the -P32 in order to avoid the pipelining for a more real-world
      load.
      
      In another terminal tab you can monitor the Redis behavior with:
      
      redis-cli -i 0.1 -r -1 info keyspace
      
      and
      
      redis-cli --latency-history
      
      Note: this commit will make Redis printing a lot of debug messages, it
      is not a good idea to use it in production.
      b09ea1bd
  24. 25 Jul, 2013 2 commits
  25. 24 Jul, 2013 1 commit