1. 09 May, 2014 2 commits
  2. 05 May, 2014 1 commit
    • antirez's avatar
      CLUSTER SET-CONFIG-EPOCH implemented. · c4c7389f
      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.
      c4c7389f
  3. 28 Apr, 2014 2 commits
    • antirez's avatar
      clusterLoadConfig() REDIS_ERR retval semantics refined. · b008863e
      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.
      b008863e
    • antirez's avatar
      Lock nodes.conf to avoid multiple processes using the same file. · 71d71814
      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.
      71d71814
  4. 23 Apr, 2014 1 commit
  5. 16 Apr, 2014 9 commits
  6. 21 Mar, 2014 1 commit
  7. 11 Mar, 2014 17 commits
  8. 05 Mar, 2014 1 commit
    • antirez's avatar
      Fix configEpoch assignment when a cluster slot gets "closed". · e4833ed8
      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.
      e4833ed8
  9. 11 Feb, 2014 5 commits
  10. 10 Feb, 2014 1 commit
    • antirez's avatar
      Cluster: on resharding upgrade version of receiving node. · 2e3f6b0f
      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).
      2e3f6b0f