1. 26 Mar, 2014 1 commit
  2. 25 Mar, 2014 3 commits
    • antirez's avatar
      Cluster: CLUSTER SETSLOT implementation comment updated. · eb746ec4
      antirez authored
      Update the comment since the implementation details changed.
      eb746ec4
    • antirez's avatar
      Cluster: configEpoch collisions resolution. · 6c527a89
      antirez authored
      The slave election in Redis Cluster guarantees that slaves promoted to
      masters always end with unique config epochs, however failures during
      manual reshardings, software bugs and operational errors may in theory
      cause two nodes to have the same configEpoch.
      
      This commit introduces a mechanism to eventually always end with different
      configEpochs if a collision ever happens.
      
      As a (wanted) side effect, this also ensures that after a new cluster
      is created, all nodes will end with a different configEpoch automatically.
      6c527a89
    • antirez's avatar
      Cluster: stay within 80 cols. · c1041c57
      antirez authored
      c1041c57
  3. 20 Mar, 2014 1 commit
  4. 11 Mar, 2014 5 commits
  5. 10 Mar, 2014 5 commits
  6. 07 Mar, 2014 2 commits
  7. 06 Mar, 2014 3 commits
  8. 04 Mar, 2014 1 commit
    • Matt Stancliff's avatar
      Bind source address for cluster communication · e5b1e7be
      Matt Stancliff authored
      The first address specified as a bind parameter
      (server.bindaddr[0]) gets used as the source IP
      for cluster communication.
      
      If no bind address is specified by the user, the
      behavior is unchanged.
      
      This patch allows multiple Redis Cluster instances
      to communicate when running on the same interface
      of the same host.
      e5b1e7be
  9. 03 Mar, 2014 1 commit
    • antirez's avatar
      Fix configEpoch assignment when a cluster slot gets "closed". · 8dea2029
      antirez authored
      This is still code to rework in order to use agreement to obtain a new
      configEpoch when a slot is migrated, however this commit handles the
      special case that happens when the nodes are just started and everybody
      has a configEpoch of 0. In this special condition to have the maximum
      configEpoch is not enough as the special epoch 0 is not unique (all the
      others are).
      
      This does not fixes the intrinsic race condition of a failover happening
      while we are resharding, that will be addressed later.
      8dea2029
  10. 19 Feb, 2014 1 commit
  11. 11 Feb, 2014 5 commits
  12. 10 Feb, 2014 12 commits