1. 18 Nov, 2013 4 commits
    • antirez's avatar
      Sentinel: slaves reconfig delay modified. · e0750acf
      antirez authored
      The time Sentinel waits since the slave is detected to be configured to
      the wrong master, before reconfiguring it, is now the failover_timeout
      time as this makes more sense in order to give the Sentinel performing
      the failover enoung time to reconfigure the slaves slowly (if required
      by the configuration).
      
      Also we now PUBLISH more frequently the new configuraiton as this allows
      to switch the reapprearing master back to slave faster.
      e0750acf
    • antirez's avatar
      Sentinel: failover restart time is now multiple of failover timeout. · 83316f51
      antirez authored
      Also defaulf failover timeout changed to 3 minutes as the failover is a
      fairly fast procedure most of the times, unless there are a very big
      number of slaves and the user picked to configure them sequentially (in
      that case the user should change the failover timeout accordingly).
      83316f51
    • antirez's avatar
      Sentinel: state machine and timeouts simplified. · 3a56013a
      antirez authored
      3a56013a
    • antirez's avatar
      Sentinel: election timeout define. · 4be53b1c
      antirez authored
      4be53b1c
  2. 14 Nov, 2013 3 commits
  3. 13 Nov, 2013 12 commits
  4. 12 Nov, 2013 10 commits
  5. 11 Nov, 2013 5 commits
    • antirez's avatar
      Sentinel: leadership handling changes WIP. · 8c1bf9a2
      antirez authored
      Changes to leadership handling.
      
      Now the leader gets selected by every Sentinel, for a specified epoch,
      when the SENTINEL is-master-down-by-addr is sent.
      
      This command now includes the runid and the currentEpoch of the instance
      seeking for a vote. The Sentinel only votes a single time in a given
      epoch.
      
      Still a work in progress, does not even compile at this stage.
      8c1bf9a2
    • antirez's avatar
      Sentinel: handle Hello messages received via slaves correctly. · 0bac36d0
      antirez authored
      Even when messages are received via the slave, we should perform
      operations (like adding a new Sentinel) in the context of the master.
      0bac36d0
    • antirez's avatar
      9e1b27d4
    • antirez's avatar
      Sentinel: epoch introduced. · b93b0adc
      antirez authored
      Sentinel state now includes the idea of current epoch and config epoch.
      In the Hello message, that is now published both on masters and slaves,
      a Sentinel no longer just advertises itself but also broadcasts its
      current view of the configuration: the master name / ip / port and its
      current epoch.
      
      Sentinels receiving such information switch to the new master if the
      configuration epoch received is newer and the ip / port of the master
      are indeed different compared to the previos ones.
      b93b0adc
    • antirez's avatar
      b2f83439
  6. 08 Nov, 2013 6 commits