1. 14 May, 2014 1 commit
    • antirez's avatar
      Cluster: better handling of stolen slots. · 6baac558
      antirez authored
      The previous code handling a lost slot (by another master with an higher
      configuration for the slot) was defensive, considering it an error and
      putting the cluster in an odd state requiring redis-cli fix.
      
      This was changed, because actually this only happens either in a
      legitimate way, with failovers, or when the admin messed with the config
      in order to reconfigure the cluster. So the new code instead will try to
      make sure that the keys stored match the new slots map, by removing all
      the keys in the slots we lost ownership from.
      
      The function that deletes the keys from the lost slots is called only
      if the node does not lose all its slots (resulting in a reconfiguration
      as a slave of the node that got ownership). This is an optimization
      since the replication code will anyway flush all the instance data in
      a faster way.
      6baac558
  2. 12 May, 2014 4 commits
    • antirez's avatar
      832a2980
    • antirez's avatar
      Cluster: forced failover implemented. · 26923391
      antirez authored
      Using CLUSTER FAILOVER FORCE it is now possible to failover a master in
      a forced way, which means:
      
      1) No check to understand if the master is up is performed.
      2) No data age of the slave is checked. Evan a slave with very old data
         can manually failover a master in this way.
      3) No chat with the master is attempted to reach its replication offset:
         the master can just be down.
      26923391
    • antirez's avatar
      Cluster: bypass data_age check for manual failovers. · 005f564e
      antirez authored
      Automatic failovers only happen in Redis Cluster if the slave trying to
      be elected was disconnected from its master for no more than 10 times
      the node-timeout value. However there should be no such a check for
      manual failovers, since these are initiated by the sysadmin that, in
      theory, knows what she is doing when a slave is selected to be promoted.
      005f564e
    • antirez's avatar
      RESTORE: reply with -BUSYKEY special error code. · 5c78f876
      antirez authored
      The error when the target key is busy was a generic one, while it makes
      sense to be able to distinguish between the target key busy error and
      the others easily.
      5c78f876
  3. 09 May, 2014 3 commits
  4. 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
  5. 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
  6. 22 Apr, 2014 1 commit
  7. 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
  8. 27 Mar, 2014 2 commits
  9. 26 Mar, 2014 3 commits
  10. 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
  11. 20 Mar, 2014 1 commit
  12. 11 Mar, 2014 5 commits
  13. 10 Mar, 2014 5 commits
  14. 07 Mar, 2014 2 commits
  15. 06 Mar, 2014 3 commits
  16. 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
  17. 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
  18. 19 Feb, 2014 1 commit