1. 20 5月, 2014 4 次提交
  2. 19 5月, 2014 2 次提交
  3. 15 5月, 2014 1 次提交
  4. 12 5月, 2014 3 次提交
  5. 09 5月, 2014 1 次提交
  6. 08 5月, 2014 2 次提交
    • A
      Sentinel: log when a failover will be attempted again. · 13d8b2b0
      antirez 提交于
      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
      13d8b2b0
    • A
      Sentinel: generate +config-update-from event when a new config is received. · 909d1883
      antirez 提交于
      This event makes clear, before the switch-master event is generated,
      that a Sentinel received a configuration update from another Sentinel.
      909d1883
  7. 07 5月, 2014 11 次提交
  8. 23 4月, 2014 5 次提交
  9. 22 4月, 2014 4 次提交
  10. 18 4月, 2014 7 次提交