1. 12 Nov, 2013 7 commits
  2. 11 Nov, 2013 4 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
  3. 06 Nov, 2013 3 commits
  4. 26 Sep, 2013 1 commit
  5. 24 Jul, 2013 1 commit
    • antirez's avatar
      sdsrange() does not need to return a value. · 6ea8e094
      antirez authored
      Actaully the string is modified in-place and a reallocation is never
      needed, so there is no need to return the new sds string pointer as
      return value of the function, that is now just "void".
      6ea8e094
  6. 11 Jul, 2013 2 commits
  7. 10 Jul, 2013 1 commit
  8. 09 Jul, 2013 1 commit
  9. 08 Jul, 2013 2 commits
  10. 20 Jun, 2013 1 commit
    • antirez's avatar
      Sentinel: parse new INFO replication output correctly. · 4c0f8c4e
      antirez authored
      Sentinel was not able to detect slaves when connected to a very recent
      version of Redis master since a previos non-backward compatible change
      to INFO broken the parsing of the slaves ip:port INFO output.
      
      This fixes issue #1164
      4c0f8c4e
  11. 30 Apr, 2013 2 commits
    • antirez's avatar
      Sentinel: changes to tilt mode. · e5ef85c4
      antirez authored
      Tilt mode was too aggressive (not processing INFO output), this
      resulted in a few problems:
      
      1) Redirections were not followed when in tilt mode. This opened a
         window to misinform clients about the current master when a Sentinel
         was in tilt mode and a fail over happened during the time it was not
         able to update the state.
      
      2) It was possible for a Sentinel exiting tilt mode to detect a false
         fail over start, if a slave rebooted with a wrong configuration
         about at the same time. This used to happen since in tilt mode we
         lose the information that the runid changed (reboot).
      
         Now instead the Sentinel in tilt mode will still remove the instance
         from the list of slaves if it changes state AND runid at the same
         time.
      
      Both are edge conditions but the changes should overall improve the
      reliability of Sentinel.
      e5ef85c4
    • antirez's avatar
      ef05a78e
  12. 26 Apr, 2013 1 commit
    • antirez's avatar
      Sentinel: only demote old master into slave under certain conditions. · 48ede0d8
      antirez authored
      We used to always turn a master into a slave if the DEMOTE flag was set,
      as this was a resurrecting master instance.
      
      However the following race condition is possible for a Sentinel that
      got partitioned or internal issues (tilt mode), and was not able to
      refresh the state in the meantime:
      
      1) Sentinel X is running, master is instance "A".
      3) "A" fails, sentinels will promote slave "B" as master.
      2) Sentinel X goes down because of a network partition.
      4) "A" returns available, Sentinels will demote it as a slave.
      5) "B" fails, other Sentinels will promote slave "A" as master.
      6) At this point Sentinel X comes back.
      
      When "X" comes back he thinks that:
      
      "B" is the master.
      "A" is the slave to demote.
      
      We want to avoid that Sentinel "X" will demote "A" into a slave.
      We also want that Sentinel "X" will detect that the conditions changed
      and will reconfigure itself to monitor the right master.
      
      There are two main ways for the Sentinel to reconfigure itself after
      this event:
      
      1) If "B" is reachable and already configured as a slave by other
      sentinels, "X" will perform a redirection to "A".
      2) If there are not the conditions to demote "A", the fact that "A"
      reports to be a master will trigger a failover detection in "X", that
      will end into a reconfiguraiton to monitor "A".
      
      However if the Sentinel was not reachable, its state may not be updated,
      so in case it titled, or was partiitoned from the master instance of the
      slave to demote, the new implementation waits some time (enough to
      guarantee we can detect the new INFO, and new DOWN conditions).
      
      If after some time still there are not the right condiitons to demote
      the instance, the DEMOTE flag is cleared.
      48ede0d8
  13. 24 Apr, 2013 1 commit
    • antirez's avatar
      Sentinel: always redirect on master->slave transition. · 1965e22a
      antirez authored
      Sentinel redirected to the master if the instance changed runid or it
      was the first time we got INFO, and a role change was detected from
      master to slave.
      
      While this is a good idea in case of slave->master, since otherwise we
      could detect a failover without good reasons just after a reboot with a
      slave with a wrong configuration, in the case of master->slave
      transition is much better to always perform the redirection for the
      following reasons:
      
      1) A Sentinel may go down for some time. When it is back online there is
      no other way to understand there was a failover.
      2) Pointing clients to a slave seems to be always the wrong thing to do.
      3) There is no good rationale about handling things differently once an
      instance is rebooted (runid change) in that case.
      1965e22a
  14. 19 Apr, 2013 1 commit
  15. 31 Jan, 2013 1 commit
  16. 19 Jan, 2013 1 commit
  17. 08 Nov, 2012 1 commit
  18. 26 Sep, 2012 1 commit
  19. 04 Sep, 2012 2 commits
    • antirez's avatar
      Sentinel: reply -IDONTKNOW to get-master-addr-by-name on lack of info. · 9bd0e097
      antirez authored
      If we don't have any clue about a master since it never replied to INFO
      so far, reply with an -IDONTKNOW error to SENTINEL
      get-master-addr-by-name requests.
      9bd0e097
    • antirez's avatar
      Sentinel: more easy master redirection if master is a slave. · 8bdde086
      antirez authored
      Before this commit Sentienl used to redirect master ip/addr if the
      current instance reported to be a slave only if this was the first INFO
      output received, and the role was found to be slave.
      
      Now instead also if we find that the runid is different, and the
      reported role is slave, we also redirect to the reported master ip/addr.
      
      This unifies the behavior of Sentinel in the case of a reboot (where it
      will see the first INFO output with the wrong role and will perform the
      redirection), with the behavior of Sentinel in the case of a change in
      what it sees in the INFO output of the master.
      8bdde086
  20. 30 Aug, 2012 1 commit
  21. 29 Aug, 2012 1 commit
  22. 28 Aug, 2012 2 commits
    • antirez's avatar
      Sentinel: Sentinel-side support for slave priority. · 3ec701e0
      antirez authored
      The slave priority that is now published by Redis in INFO output is
      now used by Sentinel in order to select the slave with minimum priority
      for promotion, and in order to consider slaves with priority set to 0 as
      not able to play the role of master (they will never be promoted by
      Sentinel).
      
      The "slave-priority" field is now one of the fileds that Sentinel
      publishes when describing an instance via the SENTINEL commands such as
      "SENTINEL slaves mastername".
      3ec701e0
    • antirez's avatar
      Sentinel: suppress harmless warning by initializing 'table' to NULL. · c14e0eca
      antirez authored
      Note that the assertion guarantees that one of the if branches setting
      table is always entered.
      c14e0eca
  23. 24 Aug, 2012 2 commits
    • antirez's avatar
      Sentinel: send SCRIPT KILL on -BUSY reply and SDOWN instance. · 850789ce
      antirez authored
      From the point of view of Redis an instance replying -BUSY is down,
      since it is effectively not able to reply to user requests. However
      a looping script is a recoverable condition in Redis if the script still
      did not performed any write to the dataset. In that case performing a
      fail over is not optimal, so Sentinel now tries to restore the normal server
      condition killing the script with a SCRIPT KILL command.
      
      If the script already performed some write before entering an infinite
      (or long enough to timeout) loop, SCRIPT KILL will not work and the
      fail over will be triggered anyway.
      850789ce
    • antirez's avatar
      Sentinel: fixed a crash on script execution. · 01477753
      antirez authored
      The call to sentinelScheduleScriptExecution() lacked the final NULL
      argument to signal the end of arguments. This resulted into a crash.
      01477753