1. 18 May, 2014 1 commit
  2. 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
  3. 14 May, 2014 4 commits
    • antirez's avatar
      0b7aa261
    • 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
    • antirez's avatar
      27ca133d
  4. 13 May, 2014 2 commits
  5. 12 May, 2014 10 commits
  6. 10 May, 2014 1 commit
  7. 09 May, 2014 5 commits
  8. 08 May, 2014 2 commits
    • antirez's avatar
      Sentinel: log when a failover will be attempted again. · 21027786
      antirez authored
      When a Sentinel performs a failover (successful or not), or when a
      Sentinel votes for a different Sentinel trying to start a failover, it
      sets a min delay before it will try to get elected for a failover.
      
      While not strictly needed, because if multiple Sentinels will try
      to failover the same master at the same time, only one configuration
      will eventually win, this serialization is practically very useful.
      Normal failovers are cleaner: one Sentinel starts to failover, the
      others update their config when the Sentinel performing the failover
      is able to get the selected slave to move from the role of slave to the
      one of master.
      
      However currently this timeout was implicit, so users could see
      Sentinels not reacting, after a failed failover, for some time, without
      giving any feedback in the logs to the poor sysadmin waiting for clues.
      
      This commit makes Sentinels more verbose about the delay: when a master
      is down and a failover attempt is not performed because the delay has
      still not elaped, something like that will be logged:
      
          Next failover delay: I will not start a failover
          before Thu May  8 16:48:59 2014
      21027786
    • antirez's avatar
      Sentinel: generate +config-update-from event when a new config is received. · 931beae9
      antirez authored
      This event makes clear, before the switch-master event is generated,
      that a Sentinel received a configuration update from another Sentinel.
      931beae9
  9. 07 May, 2014 10 commits