1. 24 Mar, 2015 1 commit
    • antirez's avatar
      Cluster: redirection refactoring + handling of blocked clients. · 3468cd36
      antirez authored
      There was a bug in Redis Cluster caused by clients blocked in a blocking
      list pop operation, for keys no longer handled by the instance, or
      in a condition where the cluster became down after the client blocked.
      
      A typical situation is:
      
      1) BLPOP <somekey> 0
      2) <somekey> hash slot is resharded to another master.
      
      The client will block forever int this case.
      
      A symmentrical non-cluster-specific bug happens when an instance is
      turned from master to slave. In that case it is more serious since this
      will desynchronize data between slaves and masters. This other bug was
      discovered as a side effect of thinking about the bug explained and
      fixed in this commit, but will be fixed in a separated commit.
      3468cd36
  2. 22 Mar, 2015 1 commit
  3. 21 Mar, 2015 1 commit
  4. 20 Mar, 2015 2 commits
    • antirez's avatar
      Cluster: better cluster state transiction handling. · 62893f5b
      antirez authored
      Before we relied on the global cluster state to make sure all the hash
      slots are linked to some node, when getNodeByQuery() is called. So
      finding the hash slot unbound was checked with an assertion. However
      this is fragile. The cluster state is often updated in the
      clusterBeforeSleep() function, and not ASAP on state change, so it may
      happen to process clients with a cluster state that is 'ok' but yet
      certain hash slots set to NULL.
      
      With this commit the condition is also checked in getNodeByQuery() and
      reported with a identical error code of -CLUSTERDOWN but slightly
      different error message so that we have more debugging clue in the
      future.
      
      Root cause of issue #2288.
      62893f5b
    • antirez's avatar
      Cluster: move clusterBeforeSleep() call before unblocked clients processing. · 585f68ac
      antirez authored
      Related to issue #2288.
      585f68ac
  5. 18 Mar, 2015 1 commit
  6. 11 Feb, 2015 3 commits
  7. 23 Dec, 2014 1 commit
    • antirez's avatar
      INFO loading stats: three fixes. · 1e8f1577
      antirez authored
      1. Server unxtime may remain not updated while loading AOF, so ETA is
      not updated correctly.
      
      2. Number of processed byte was not initialized.
      
      3. Possible division by zero condition (likely cause of issue #1932).
      1e8f1577
  8. 19 Dec, 2014 1 commit
  9. 13 Dec, 2014 2 commits
  10. 04 Dec, 2014 1 commit
  11. 03 Dec, 2014 2 commits
  12. 02 Dec, 2014 1 commit
    • antirez's avatar
      Mark PFCOUNT as read-only, even if not true. · 69efb59a
      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).
      69efb59a
  13. 12 Nov, 2014 1 commit
  14. 29 Oct, 2014 5 commits
  15. 06 Oct, 2014 2 commits
  16. 19 Sep, 2014 1 commit
  17. 17 Sep, 2014 1 commit
    • antirez's avatar
      Don't propagate SAVE. · ef61ab63
      antirez authored
      This is a general fix (check that dirty delta is positive) but actually
      should have as the only effect fixing the SAVE propagation to
      AOF and slaves.
      ef61ab63
  18. 08 Sep, 2014 1 commit
  19. 26 Aug, 2014 9 commits
  20. 28 Jul, 2014 1 commit
  21. 18 Jul, 2014 2 commits