1. 10 Jun, 2014 5 commits
  2. 07 Jun, 2014 2 commits
    • antirez's avatar
      Cluster: check that configEpoch never goes back. · 32d0a79f
      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.
      32d0a79f
    • antirez's avatar
      Cluster: SET-CONFIG-EPOCH should update currentEpoch. · a2c2ef7d
      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.
      a2c2ef7d
  3. 26 May, 2014 1 commit
  4. 22 May, 2014 1 commit
  5. 15 May, 2014 5 commits
    • antirez's avatar
      Cluster: use clusterSetNodeAsMaster() during slave failover. · 67133d2f
      antirez authored
      clusterHandleSlaveFailover() was reimplementing what
      clusterSetNodeAsMaster() without any good reason.
      67133d2f
    • antirez's avatar
      Cluster: clear todo_before_sleep flags when executing actions. · 8c6e92c3
      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.
      8c6e92c3
    • antirez's avatar
      Fixed typo in CLUSTER RESET implementation. · 7b87cda7
      antirez authored
      7b87cda7
    • antirez's avatar
      CLUSTER RESET implemented. · 796f4ae9
      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.
      796f4ae9
    • antirez's avatar
      Remove trailing spaces from cluster.c file. · 8b9d5ecb
      antirez authored
      8b9d5ecb
  6. 14 May, 2014 2 commits
    • antirez's avatar
      60e5d172
    • 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
  7. 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
  8. 09 May, 2014 3 commits
  9. 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
  10. 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
  11. 22 Apr, 2014 1 commit
  12. 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
  13. 27 Mar, 2014 2 commits
  14. 26 Mar, 2014 3 commits
  15. 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
  16. 20 Mar, 2014 1 commit
  17. 11 Mar, 2014 3 commits