1. 20 May, 2014 2 commits
    • antirez's avatar
      Cluster: forced failover implemented. · e84dcabf
      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.
      e84dcabf
    • antirez's avatar
      Cluster: bypass data_age check for manual failovers. · b5cdd42b
      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.
      b5cdd42b
  2. 12 May, 2014 2 commits
  3. 09 May, 2014 2 commits
  4. 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
  5. 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
  6. 23 Apr, 2014 1 commit
  7. 16 Apr, 2014 9 commits
  8. 21 Mar, 2014 1 commit
  9. 11 Mar, 2014 17 commits
  10. 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
  11. 11 Feb, 2014 2 commits