1. 10 Dec, 2014 8 commits
    • antirez's avatar
      Better read-only behavior for expired keys in slaves. · 06e76bc3
      antirez authored
      Slaves key expire is orchestrated by the master. Sometimes the master
      will send the synthesized DEL to expire keys on the slave with a non
      trivial delay (when the key is not accessed, only the incremental expiry
      algorithm will expire it in background).
      
      During that time, a key is logically expired, but slaves still return
      the key if you GET (or whatever) it. This is a bad behavior.
      
      However we can't simply trust the slave view of the key, since we need
      the master to be able to send write commands to update the slave data
      set, and DELs should only happen when the key is expired in the master
      in order to ensure consistency.
      
      However 99.99% of the issues with this behavior is when a client which
      is not a master sends a read only command. In this case we are safe and
      can consider the key as non existing.
      
      This commit does a few changes in order to make this sane:
      
      1. lookupKeyRead() is modified in order to return NULL if the above
      conditions are met.
      2. Calls to lookupKeyRead() in commands actually writing to the data set
      are repliaced with calls to lookupKeyWrite().
      
      There are redundand checks, so for example, if in "2" something was
      overlooked, we should be still safe, since anyway, when the master
      writes the behavior is to don't care about what expireIfneeded()
      returns.
      
      This commit is related to  #1768, #1770, #2131.
      06e76bc3
    • antirez's avatar
      Sentinel: INFO-CACHE comments reworked a bit. · d8158771
      antirez authored
      Changed in order to make them more review friendly, based on the
      experience of reviewing the code myself.
      d8158771
    • antirez's avatar
      Sentinel: INFO-CACHE GCC minior code cleanup. · c83a9172
      antirez authored
      I guess the initial goal of the initialization was to suppress GCC
      warning, but if we have to initialize, we can do it with the base-case
      value instead of NULL which is never retained.
      c83a9172
    • antirez's avatar
      04223216
    • antirez's avatar
      7576a27d
    • antirez's avatar
      test-sds target in Makefile to run sds.c tests. · 0195afae
      antirez authored
      0195afae
    • antirez's avatar
      sds.c: more tests for sdstrim(). · 9bb4ef87
      antirez authored
      9bb4ef87
    • Brochen's avatar
      Update sds.c · 181300d4
      Brochen authored
      in the case (all chars of the string s found in 'cset' ),
      line[573] will no more do the same thing line[572] did.
      this will be more faster especially in the case that the string s is very long and all chars of string s found in 'cset'
      181300d4
  2. 09 Dec, 2014 1 commit
  3. 08 Dec, 2014 3 commits
  4. 05 Dec, 2014 1 commit
  5. 04 Dec, 2014 1 commit
  6. 03 Dec, 2014 4 commits
  7. 02 Dec, 2014 4 commits
    • antirez's avatar
      Use exp format and more precision output for ZSCAN. · 92c5ab40
      antirez authored
      Ref: issue #2175
      92c5ab40
    • antirez's avatar
      5bd3b9d9
    • antirez's avatar
      Mark PFCOUNT as read-only, even if not true. · 8a7ccc58
      antirez authored
      PFCOUNT is technically speaking a write command, since the cached value
      of the HLL is exposed in the data structure (design error, mea culpa), and
      can be modified by PFCOUNT.
      
      However if we flag PFCOUNT as "w", read only slaves can't execute the
      command, which is a problem since there are environments where slaves
      are used to scale PFCOUNT reads.
      
      Nor it is possible to just prevent PFCOUNT to modify the data structure
      in slaves, since without the cache we lose too much efficiency.
      
      So while this commit allows slaves to create a temporary inconsistency
      (the strings representing the HLLs in the master and slave can be
      different in certain moments) it is actually harmless.
      
      In the long run this should be probably fixed by turning the HLL into a
      more opaque representation, for example by storing the cached value in
      the part of the string which is not exposed (this should be possible
      with SDS strings).
      8a7ccc58
    • Sun He's avatar
      0ec7672a
  8. 01 Dec, 2014 3 commits
  9. 28 Nov, 2014 3 commits
  10. 26 Nov, 2014 1 commit
    • antirez's avatar
      Fix DEBUG OBJECT lru field to report seconds. · acf73a05
      antirez authored
      Because of (not so) recent Redis changes, now the LRU internally
      reported unit is milliseconds, not seconds, but the DEBUG OBJECT output
      was still claiming seconds while providing milliseconds.
      However OBJECT IDLETIME was working as expected, which is the correct
      API to use.
      acf73a05
  11. 25 Nov, 2014 3 commits
  12. 20 Nov, 2014 1 commit
    • Matt Stancliff's avatar
      Add SENTINEL INFO-CACHE [masters...] · f8c73e38
      Matt Stancliff authored
      Sentinel queries the INFO from every master and from every replica of
      every master.
      
      We can cache the INFO results in Sentinel so Sentinel can be a single
      place to quickly get all INFO output for an entire Sentinel monitoring
      group.
      
      This commit gives us SENTINEL INFO-CACHE in two forms:
        - SENTINEL INFO-CACHE — returns all masters and all replicas
        - SENTINEL INFO-CACHE master0 master1 ... masterN — vararg specify masters
      
      Results are returned as a multibulk reply with two top-level entries
      for each master.  The first entry for each master is the name of the master.
      The second entry is a nested multibulk reply with the contents of INFO,
      first for the master, then an additional entry for each of the
      replicas.
      f8c73e38
  13. 14 Nov, 2014 1 commit
  14. 12 Nov, 2014 3 commits
  15. 11 Nov, 2014 3 commits
    • antirez's avatar
      Diskless SYNC: fix RDB EOF detection. · bb7fea0d
      antirez authored
      RDB EOF detection was relying on the final part of the RDB transfer to
      be a magic 40 bytes EOF marker. However as the slave is put online
      immediately, and because of sockets timeouts, the replication stream is
      actually contiguous with the RDB file.
      
      This means that to detect the EOF correctly we should either:
      
      1) Scan all the stream searching for the mark. Sucks CPU-wise.
      2) Start to send the replication stream only after an acknowledge.
      3) Implement a proper chunked encoding.
      
      For now solution "2" was picked, so the master does not start to send
      ASAP the stream of commands in the case of diskless replication. We wait
      for the first REPLCONF ACK command from the slave, that certifies us
      that the slave correctly loaded the RDB file and is ready to get more
      data.
      bb7fea0d
    • antirez's avatar
    • Charles Hooper's avatar
      3ab83219