1. 02 Jun, 2015 1 commit
  2. 29 May, 2015 3 commits
  3. 28 May, 2015 1 commit
  4. 25 May, 2015 2 commits
  5. 22 May, 2015 1 commit
  6. 21 May, 2015 2 commits
  7. 20 May, 2015 1 commit
  8. 18 May, 2015 1 commit
    • antirez's avatar
      Sentinel: SENTINEL CKQUORUM command · abc65e89
      antirez authored
      A way for monitoring systems to check that Sentinel is technically able
      to reach the quorum and failover, using the currently visible Sentinels.
      abc65e89
  9. 15 May, 2015 2 commits
  10. 14 May, 2015 7 commits
  11. 13 May, 2015 1 commit
  12. 12 May, 2015 4 commits
  13. 11 May, 2015 3 commits
  14. 08 May, 2015 4 commits
  15. 07 May, 2015 1 commit
    • antirez's avatar
      Sentinel: don't detect duplicated Sentinels, just address switch · a0cd75cd
      antirez authored
      Since with a previous commit Sentinels now persist their unique ID, we
      no longer need to detect duplicated Sentinels and re-add them. We remove
      and re-add back using different events only in the case of address
      switch of the same Sentinel, without generating a new +sentinel event.
      a0cd75cd
  16. 06 May, 2015 1 commit
    • antirez's avatar
      Sentinel: persist its unique ID across restarts. · 794fc4c9
      antirez authored
      Previously Sentinels always changed unique ID across restarts, relying
      on the server.runid field. This is not a good idea, and forced Sentinel
      to rely on detection of duplicated Sentinels and a potentially dangerous
      clean-up and re-add operation of the Sentinel instance that was
      rebooted.
      
      Now the ID is generated at the first start and persisted in the
      configuration file, so that a given Sentinel will have its unique
      ID forever (unless the configuration is manually deleted or there is a
      filesystem corruption).
      794fc4c9
  17. 05 May, 2015 4 commits
  18. 04 May, 2015 1 commit
    • therealbill's avatar
      Making sentinel flush config on +slave · cc799d25
      therealbill authored
      Originally, only the +slave event which occurs when a slave is
      reconfigured during sentinelResetMasterAndChangeAddress triggers a flush
      of the config to disk.  However, newly discovered slaves don't
      apparently trigger this flush but do trigger the +slave event issuance.
      
      So if you start up a sentinel, add a master, then add a slave to the
      master (as a way to reproduce it) you'll see the +slave event issued,
      but the sentinel config won't be updated with the known-slave entry.
      
      This change makes sentinel do the flush of the config if a new slave is
      deteted in sentinelRefreshInstanceInfo.
      cc799d25