1. 27 May, 2013 3 commits
    • antirez's avatar
      0000d533
    • antirez's avatar
      Replication: send REPLCONF ACK to master. · 146f1d7d
      antirez authored
      146f1d7d
    • antirez's avatar
      REPLCONF ACK command. · 1e77b77d
      antirez authored
      This special command is used by the slave to inform the master the
      amount of replication stream it currently consumed.
      
      it does not return anything so that we not need to consume additional
      bandwidth needed by the master to reply something.
      
      The master can do a number of things knowing the amount of stream
      processed, such as understanding the "lag" in bytes of the slave, verify
      if a given command was already processed by the slave, and so forth.
      1e77b77d
  2. 24 May, 2013 3 commits
  3. 18 May, 2013 1 commit
  4. 15 May, 2013 20 commits
  5. 14 May, 2013 1 commit
  6. 09 May, 2013 1 commit
  7. 08 May, 2013 5 commits
  8. 02 May, 2013 3 commits
  9. 30 Apr, 2013 3 commits
    • antirez's avatar
      Sentinel: changes to tilt mode. · e7bcec82
      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.
      e7bcec82
    • antirez's avatar
      4028a777
    • antirez's avatar
      Sentinel: only demote old master into slave under certain conditions. · 70845320
      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.
      70845320