"CONTRIBUTING.md" did not exist on "c147cd848760c44791d73b03dbe2a4b8aa5b8c8e"
  1. 29 May, 2015 6 commits
  2. 28 May, 2015 1 commit
  3. 25 May, 2015 3 commits
  4. 22 May, 2015 1 commit
  5. 20 May, 2015 1 commit
  6. 19 May, 2015 2 commits
  7. 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
  8. 15 May, 2015 4 commits
  9. 14 May, 2015 7 commits
  10. 13 May, 2015 1 commit
  11. 12 May, 2015 4 commits
  12. 11 May, 2015 3 commits
  13. 08 May, 2015 4 commits
  14. 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
  15. 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