1. 07 Jun, 2014 2 commits
    • antirez's avatar
      Cluster: check that configEpoch never goes back. · 8b059f06
      antirez authored
      Since there are ways to alter the configEpoch outside of the failover
      procedure (for exampel CLUSTER SET-CONFIG-EPOCH and via the configEpoch
      collision resolution algorithm), make always sure, before replacing our
      configEpoch with a new one, that it is greater than the current one.
      8b059f06
    • antirez's avatar
      Cluster: SET-CONFIG-EPOCH should update currentEpoch. · 67029323
      antirez authored
      SET-CONFIG-EPOCH, used by redis-trib at cluster creation time, failed to
      update the currentEpoch, making it possible after a failover for a
      server to set its configEpoch to a value smaller than the current one
      (since configEpochs are obtained using currentEpoch).
      
      The bug totally break the Redis Cluster algorithms and protocols
      allowing for permanent split brain conditions about the slots
      configuration as shown in issue #1799.
      67029323
  2. 26 May, 2014 1 commit
  3. 23 May, 2014 1 commit
  4. 20 May, 2014 10 commits
    • antirez's avatar
      Cluster: use clusterSetNodeAsMaster() during slave failover. · 8c6e8680
      antirez authored
      clusterHandleSlaveFailover() was reimplementing what
      clusterSetNodeAsMaster() without any good reason.
      8c6e8680
    • antirez's avatar
      Cluster: clear todo_before_sleep flags when executing actions. · 41a72416
      antirez authored
      Thanks to this change, when there is some code like:
      
          clusterDoBeforeSleep(CLUSTER_TODO_UPDATE_STATE|...);
          ... and later before returning to the event loop ...
          clusterUpdateState();
      
      The clusterUpdateState() function will clar the flag and will not be
      repeated in the clusterBeforeSleep() function. This especially important
      for config save/fsync flags which are slow to execute and not a good
      idea to repeat without a good reason.
      
      This is implemented for all the CLUSTER_TODO flags.
      41a72416
    • antirez's avatar
      Fixed typo in CLUSTER RESET implementation. · 5685d15a
      antirez authored
      5685d15a
    • antirez's avatar
      CLUSTER RESET implemented. · 5efa5501
      antirez authored
      The new command is able to reset a cluster node so that it starts again
      as a fresh node. By default the command performs a soft reset (the same
      as calling it as CLUSTER RESET SOFT), and the following steps are
      performed:
      
      1) All slots are set as unassigned.
      2) The list of known nodes is flushed.
      3) Node is set as master if it is a slave.
      
      When an hard reset is performed with CLUSTER RESET HARD the following
      additional operations are performed:
      
      4) A new Node ID is created at random.
      5) Epochs are set to 0.
      
      CLUSTER RESET is useful both when the sysadmin wants to reconfigure a
      node with a different role (for example turning a slave into a master)
      and for testing purposes.
      
      It also may play a role in automatically provisioned Redis Clusters,
      since it allows to reset a node back to the initial state in order to be
      reconfigured.
      5efa5501
    • antirez's avatar
      Remove trailing spaces from cluster.c file. · 687f84a3
      antirez authored
      687f84a3
    • antirez's avatar
      be159490
    • antirez's avatar
      Cluster: better handling of stolen slots. · b8a71e5a
      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.
      b8a71e5a
    • antirez's avatar
      e10ee072
    • 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
  5. 12 May, 2014 2 commits
  6. 09 May, 2014 2 commits
  7. 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
  8. 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
  9. 23 Apr, 2014 1 commit
  10. 16 Apr, 2014 9 commits
  11. 21 Mar, 2014 1 commit
  12. 11 Mar, 2014 8 commits