1. 29 Apr, 2014 1 commit
    • antirez's avatar
      CLUSTER SET-CONFIG-EPOCH implemented. · 11d9ecb7
      antirez authored
      Initially Redis Cluster accepted that after cluster creation all the
      nodes were at configEpoch 0, evolving from zero as failovers happen.
      
      However later the semantic was made more strict in order to make sure a
      cluster has always all the master nodes with a different configEpoch,
      which is more robust in some corner case (especially resulting from
      errors by the system administrator).
      
      To assign different configEpochs to different nodes at startup was a
      task performed naturally by the config conflicts resolution algorithm
      (see the Cluster specification). However this works well only for small
      clusters or when there are actually just a few collisions, since it is
      designed for exceptional cases.
      
      When a large cluster is created hundred of nodes can be at epoch 0, so
      the conflict resolution code is slow to provide an unique config to each
      node. For this reason this new command was introduced. It can be called
      only when a node is totally fresh: no other nodes known, and configEpoch
      set to zero, so it is safe even against misuses.
      
      redis-trib will use the new command in order to start the cluster
      already setting an incremental unique config to every node.
      11d9ecb7
  2. 24 Apr, 2014 2 commits
    • antirez's avatar
      clusterLoadConfig() REDIS_ERR retval semantics refined. · e3cf812c
      antirez authored
      We should return REDIS_ERR to signal we can't read the configuration
      because there is no config file only after checking errno, othewise
      we risk to rewrite an existing file that was not accessible for some
      other reason.
      e3cf812c
    • antirez's avatar
      Lock nodes.conf to avoid multiple processes using the same file. · db06108b
      antirez authored
      This was a common source of problems among users.
      The solution adopted is not bullet-proof as if the user deletes the
      nodes.conf file manually, and starts a new instance with the same
      nodes.conf file path, two instances will use the same file. However
      following this reasoning the user may drop a nuclear bomb into the
      datacenter as well.
      db06108b
  3. 22 Apr, 2014 1 commit
  4. 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
  5. 27 Mar, 2014 2 commits
  6. 26 Mar, 2014 3 commits
  7. 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
  8. 20 Mar, 2014 1 commit
  9. 11 Mar, 2014 5 commits
  10. 10 Mar, 2014 5 commits
  11. 07 Mar, 2014 2 commits
  12. 06 Mar, 2014 3 commits
  13. 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
  14. 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
  15. 19 Feb, 2014 1 commit
  16. 11 Feb, 2014 5 commits
  17. 10 Feb, 2014 3 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