1. 04 Jun, 2017 1 commit
  2. 14 Apr, 2017 1 commit
    • antirez's avatar
      Cluster: always add PFAIL nodes at end of gossip section. · 02777bb2
      antirez authored
      To rely on the fact that nodes in PFAIL state will be shared around by
      randomly adding them in the gossip section is a weak assumption,
      especially after changes related to sending less ping/pong packets.
      
      We want to always include gossip entries for all the nodes that are in
      PFAIL state, so that the PFAIL -> FAIL state promotion can happen much
      faster and reliably.
      
      Related to #3929.
      02777bb2
  3. 13 Apr, 2017 1 commit
  4. 27 Mar, 2017 1 commit
  5. 29 Jan, 2016 2 commits
  6. 14 Jan, 2016 1 commit
  7. 11 Dec, 2015 1 commit
    • antirez's avatar
      Cluster: replica migration with delay. · adc2fe69
      antirez authored
      We wait a fixed amount of time (5 seconds currently) much greater than
      the usual Cluster node to node communication latency, before migrating.
      This way when a failover occurs, before detecting the new master as a
      target for migration, we give the time to its natural slaves (the slaves
      of the failed over master) to announce they switched to the new master,
      preventing an useless migration operation.
      adc2fe69
  8. 09 Dec, 2015 1 commit
    • antirez's avatar
      Fix replicas migration by adding a new flag. · e0f22df9
      antirez authored
      Some time ago I broken replicas migration (reported in #2924).
      The idea was to prevent masters without replicas from getting replicas
      because of replica migration, I remember it to create issues with tests,
      but there is no clue in the commit message about why it was so
      undesirable.
      
      However my patch as a side effect totally ruined the concept of replicas
      migration since we want it to work also for instances that, technically,
      never had slaves in the past: promoted slaves.
      
      So now instead the ability to be targeted by replicas migration, is a
      new flag "migrate-to". It only applies to masters, and is set in the
      following two cases:
      
      1. When a master gets a slave, it is set.
      2. When a slave turns into a master because of fail over, it is set.
      
      This way replicas migration targets are only masters that used to have
      slaves, and slaves of masters (that used to have slaves... obviously)
      and are promoted.
      
      The new flag is only internal, and is never exposed in the output nor
      persisted in the nodes configuration, since all the information to
      handle it are implicit in the cluster configuration we already have.
      e0f22df9
  9. 27 Jul, 2015 2 commits
  10. 26 Jul, 2015 1 commit
  11. 24 Mar, 2015 1 commit
    • antirez's avatar
      Cluster: redirection refactoring + handling of blocked clients. · 9b7f8b1c
      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.
      9b7f8b1c
  12. 20 Mar, 2015 1 commit
    • antirez's avatar
      Cluster: better cluster state transiction handling. · 25c0f5ac
      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.
      25c0f5ac
  13. 13 Jan, 2015 1 commit
    • antirez's avatar
      Cluster: clusterMsgDataGossip structure, explict padding + minor stuff. · 5b0f4a83
      antirez authored
      Also explicitly set version to 0, add a protocol version define, improve
      comments in the gossip structure.
      
      Note that the structure layout is the same after the change, we are just
      making the padding explicit with an additional not used 16 bits field.
      So this commit is still able to talk with the previous versions of
      cluster nodes.
      5b0f4a83
  14. 28 Nov, 2014 1 commit
    • antirez's avatar
      Cluster PUBLISH message: fix totlen count. · 669aa2a2
      antirez authored
      bulk_data field size was not removed from the count. It is not possible
      to declare it simply as 'char bulk_data[]' since the structure is nested
      into another structure.
      669aa2a2
  15. 07 Oct, 2014 1 commit
  16. 29 Sep, 2014 1 commit
    • Matt Stancliff's avatar
      Clean up text throughout project · 12d0195b
      Matt Stancliff authored
        - Remove trailing newlines from redis.conf
        - Fix comment misspelling
        - Clarifies zipEncodeLength usage and a C API mention (#1243, #1242)
        - Fix cluster typos (inspired by @papanikge #1507)
        - Fix rewite -> rewrite in a few places (inspired by #682)
      
      Closes #1243, #1242, #1507
      12d0195b
  17. 17 Sep, 2014 1 commit
  18. 25 Aug, 2014 1 commit
  19. 22 May, 2014 1 commit
  20. 27 Mar, 2014 1 commit
  21. 10 Mar, 2014 1 commit
    • antirez's avatar
      Cluster: better timeout and retry time for failover. · 0f1f2578
      antirez authored
      When node-timeout is too small, in the order of a few milliseconds,
      there is no way the voting process can terminate during that time, so we
      set a lower limit for the failover timeout of two seconds.
      
      The retry time is set to two times the failover timeout time, so it is
      at least 4 seconds.
      0f1f2578
  22. 07 Mar, 2014 1 commit
  23. 06 Mar, 2014 1 commit
  24. 25 Feb, 2014 1 commit
  25. 10 Feb, 2014 3 commits
  26. 05 Feb, 2014 2 commits
  27. 31 Jan, 2014 1 commit
  28. 29 Jan, 2014 2 commits
  29. 28 Jan, 2014 3 commits
  30. 29 Nov, 2013 2 commits
  31. 08 Nov, 2013 1 commit