1. 26 Jun, 2018 1 commit
  2. 22 Jul, 2016 2 commits
    • antirez's avatar
      8b76d55f
    • antirez's avatar
      Sentinel: check Slave INFO state more often when disconnected. · 3e9ce38b
      antirez authored
      During the initial handshake with the master a slave will report to have
      a very high disconnection time from its master (since technically it was
      disconnected since forever, so the current UNIX time in seconds is
      reported).
      
      However when the slave is connected again the Sentinel may re-scan the
      INFO output again only after 10 seconds, which is a long time. During
      this time Sentinels will consider this instance unable to failover, so
      a useless delay is introduced.
      
      Actaully this hardly happened in the practice because when a slave's
      master is down, the INFO period for slaves changes to 1 second. However
      when a manual failover is attempted immediately after adding slaves
      (like in the case of the Sentinel unit test), this problem may happen.
      
      This commit changes the INFO period to 1 second even in the case the
      slave's master is not down, but the slave reported to be disconnected
      from the master (by publishing, last time we checked, a master
      disconnection time field in INFO).
      
      This change is required as a result of an unrelated change in the
      replication code that adds a small delay in the master-slave first
      synchronization.
      3e9ce38b
  3. 19 May, 2015 1 commit
  4. 30 Mar, 2015 1 commit
  5. 29 Sep, 2014 1 commit
  6. 23 Jun, 2014 1 commit
    • antirez's avatar
      Sentinel test: more correct sentinels config reset. · e21e0ba3
      antirez authored
      In the initialization test for each instance we used to unregister the
      old master and register it again to clear the config.
      However there is a race condition doing this: as soon as we unregister
      and re-register "mymaster", another Sentinel can update the new
      configuration with the old state because of gossip "hello" messages.
      
      So the correct procedure is instead, unregister "mymaster" from all the
      sentinel instances, and re-register it everywhere again.
      e21e0ba3
  7. 19 Jun, 2014 3 commits
  8. 18 Jun, 2014 1 commit
  9. 29 Apr, 2014 1 commit
  10. 24 Apr, 2014 1 commit
    • antirez's avatar
      Sentinel test files / directories layout improved. · 897adc1c
      antirez authored
      The test now runs in a self-contained directory.
      The general abstractions to run the tests in an environment where
      mutliple instances are executed at the same time was extrapolated into
      instances.tcl, that will be reused to test Redis Cluster.
      897adc1c