1. 22 Apr, 2014 1 commit
  2. 07 Apr, 2014 1 commit
    • antirez's avatar
      Add casting to match printf format. · 67bb2c46
      antirez authored
      adjustOpenFilesLimit() and clusterUpdateSlotsWithConfig() that were
      assuming uint64_t is the same as unsigned long long, which is true
      probably for all the systems out there that we target, but still GCC
      emitted a warning since technically they are two different types.
      67bb2c46
  3. 27 Mar, 2014 2 commits
  4. 26 Mar, 2014 3 commits
  5. 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
  6. 20 Mar, 2014 1 commit
  7. 11 Mar, 2014 5 commits
  8. 10 Mar, 2014 5 commits
  9. 07 Mar, 2014 2 commits
  10. 06 Mar, 2014 3 commits
  11. 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
  12. 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
  13. 19 Feb, 2014 1 commit
  14. 11 Feb, 2014 5 commits
  15. 10 Feb, 2014 6 commits
    • antirez's avatar
      Cluster: on resharding upgrade version of receiving node. · a1349728
      antirez authored
      The node receiving the hash slot needs to have a version that wins over
      the other versions in order to force the ownership of the slot.
      
      However the current code is far from perfect since a failover can happen
      during the manual resharding. The fix is a work in progress but the
      bottom line is that the new version must either be voted as usually,
      set by redis-trib manually after it makes sure can't be used by other
      nodes, or reserved configEpochs could be used for manual operations (for
      example odd versions could be never used by slaves and are always used
      by CLUSTER SETSLOT NODE).
      a1349728
    • antirez's avatar
      Cluster: fsync at every SETSLOT command puts too pressure on disks. · 6dc26795
      antirez authored
      During slots migration redis-trib can send a number of SETSLOT commands.
      Fsyncing every time is a bit too much in production as verified
      empirically.
      
      To make sure configs are fsynced on all nodes after a resharding
      redis-trib may send something like CLUSTER CONFSYNC.
      
      In this case fsyncs were not providing too much value since anyway
      processes can crash in the middle of the resharding of an hash slot, and
      redis-trib should be able to recover from this condition anyway.
      6dc26795
    • antirez's avatar
      Cluster: conditions to clear "migrating" on slot for SETSLOT ... NODE changed. · 218358bb
      antirez authored
      If the slot is manually assigned to another node, clear the migrating
      status regardless of the fact it was previously assigned to us or not,
      as long as we no longer have keys for this slot.
      
      This avoid a race during slots migration that may leave the slot in
      migrating status in the source node, since it received an update message
      from the destination node that is already claiming the slot.
      
      This way we are sure that redis-trib at the end of the slot migration is
      always able to close the slot correctly.
      218358bb
    • antirez's avatar
      Cluster: don't update slave's master if we don't know it. · bf670e07
      antirez authored
      There is no way we can update the slave's node->slaveof pointer if we
      don't know the master (no node with such an ID in our tables).
      bf670e07
    • antirez's avatar
      a3755ae9
    • antirez's avatar
      6fc53e16