1. 20 May, 2015 1 commit
  2. 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
  3. 15 May, 2015 2 commits
  4. 14 May, 2015 7 commits
  5. 13 May, 2015 1 commit
  6. 12 May, 2015 4 commits
  7. 11 May, 2015 2 commits
  8. 08 May, 2015 4 commits
  9. 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
  10. 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
  11. 05 May, 2015 4 commits
  12. 04 May, 2015 2 commits
    • 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
    • antirez's avatar
      Sentinel: remove useless sentinelFlushConfig() call · 99c93f34
      antirez authored
      To rewrite the config in the loop that adds slaves back after a master
      reset, in order to handle switching to another master, is useless: it
      just adds latency since there is an fsync call in the inner loop,
      without providing any additional guarantee, but the contrary, since if
      after the first loop iteration the server crashes we end with just a
      single slave entry losing all the other informations.
      
      It is wiser to rewrite the config at the end when the full new
      state is configured.
      99c93f34
  13. 29 Apr, 2015 1 commit
  14. 28 Apr, 2015 1 commit
  15. 27 Apr, 2015 1 commit
  16. 26 Apr, 2015 1 commit
  17. 20 Apr, 2015 2 commits
  18. 19 Apr, 2015 1 commit
  19. 17 Apr, 2015 1 commit
  20. 01 Apr, 2015 1 commit
    • antirez's avatar
      Net: improve prepareClientToWrite() error handling and comments. · 6c60526d
      antirez authored
      When we fail to setup the write handler it does not make sense to take
      the client around, it is missing writes: whatever is a client or a slave
      anyway the connection should terminated ASAP.
      
      Moreover what the function does exactly with its return value, and in
      which case the write handler is installed on the socket, was not clear,
      so the functions comment are improved to make the goals of the function
      more obvious.
      
      Also related to #2485.
      6c60526d
  21. 31 Mar, 2015 1 commit
    • Oran Agra's avatar
      fixes to diskless replication. · 159875b5
      Oran Agra authored
      master was closing the connection if the RDB transfer took long time.
      and also sent PINGs to the slave before it got the initial ACK, in which case the slave wouldn't be able to find the EOF marker.
      159875b5